From: Michael S. <m-s...@us...> - 2011-04-13 22:22:23
Attachments:
fourier.pdf
mathptmx.pdf
|
Hell André and Jörg, and here comes one of my favorite problems: ;-) I played around with different math fonts (useful for presentations and posters, etc) and tried out these two packages (one after the other, of course) (A) \usepackage{mathptmx} (B) \usepackage{fourier} In _both_ cases, I find that in mathematical mode, the letter "j" is far too wide, which does not occur if I run the "debug.tex" file created. Here is the minimal example: ---------------------- from pyx import * text.set(mode="latex") text.set(texdebug="debug.tex") text.preamble(r"\usepackage{mathptmx}") #ext.preamble(r"\usepackage{fourier}") c = canvas.canvas() c.text(0, 0, r"$x E_{ij}\quad ijnimjXQju$") c.writePDFfile("minimal") ---------------------- For archiving, I attach also PDFs of the PyX output. In an analysis of the problem, I checked which file PyX actually uses, and I identified the following files: (A) zptmcm7m.vf zptmcm7m.tfm (this might actually be different from system to sytem, depending on the updmap configuration) (B) futmii.tfm futmii.vf (Inside the virtual font, futri8t is used to produce the italic letters.) The funny thing is that when I run the debug.tex in both cases, they look OK, but in both cases they use the very same files (tfm + vf). I recognized the problem with the letter "j", but I have the impression, that also others are involved: Nearly all letters move a little bit when comparing the full alphabet. In the case (B), this is strongest for j,f,J,G,A,C,... In the case (A) for j,f,C,p,M,... One possible reason is the italic correction. I extracted the ratio of italic correction (CHARIC) and character width (CHARWD) in the virtual font. The largest ratios have (CHARACTER C f 0.395454545455 (CHARACTER C Y 0.33865248227 (CHARACTER C V 0.307291666667 (CHARACTER O 134 0.293296089385 (CHARACTER O 135 0.293296089385 (CHARACTER O 133 0.263819095477 (CHARACTER C j 0.249211356467 (CHARACTER C T 0.214532871972 (CHARACTER O 140 0.198863636364 (CHARACTER C r 0.195238095238 (CHARACTER C t 0.186813186813 (CHARACTER C W 0.18488372093 (CHARACTER C i 0.173501577287 (CHARACTER C I 0.166246851385 This is not precisely the visual list of problematic characters, but it was just my first idea ... Best, Michael |
From: André W. <wo...@us...> - 2011-05-14 16:58:19
Attachments:
smime.p7s
|
Hi, this was a rounding issue fixed in changeset 3080. André PS: Yeah, let's get an Augustiner Hell. Am 14.04.2011 um 00:22 schrieb Michael SCHINDLER: > Hell André and Jörg, > > and here comes one of my favorite problems: ;-) > I played around with different math fonts (useful for presentations > and posters, etc) and tried out these two packages (one after the > other, of course) > > (A) \usepackage{mathptmx} > (B) \usepackage{fourier} > > In _both_ cases, I find that in mathematical mode, the letter "j" is > far too wide, which does not occur if I run the "debug.tex" file > created. Here is the minimal example: > > ---------------------- > from pyx import * > > text.set(mode="latex") > text.set(texdebug="debug.tex") > text.preamble(r"\usepackage{mathptmx}") > #ext.preamble(r"\usepackage{fourier}") > > c = canvas.canvas() > c.text(0, 0, r"$x E_{ij}\quad ijnimjXQju$") > c.writePDFfile("minimal") > ---------------------- > > For archiving, I attach also PDFs of the PyX output. > > In an analysis of the problem, I checked which file PyX actually uses, > and I identified the following files: > > (A) zptmcm7m.vf zptmcm7m.tfm (this might actually be different from > system to sytem, depending on the updmap configuration) > (B) futmii.tfm futmii.vf > (Inside the virtual font, futri8t is used to produce the italic > letters.) > > The funny thing is that when I run the debug.tex in both cases, they > look OK, but in both cases they use the very same files (tfm + vf). I > recognized the problem with the letter "j", but I have the impression, > that also others are involved: Nearly all letters move a little bit > when comparing the full alphabet. In the case (B), this is strongest > for j,f,J,G,A,C,... In the case (A) for j,f,C,p,M,... > > One possible reason is the italic correction. I extracted the ratio > of italic correction (CHARIC) and character width (CHARWD) in the > virtual font. The largest ratios have > > (CHARACTER C f 0.395454545455 > (CHARACTER C Y 0.33865248227 > (CHARACTER C V 0.307291666667 > (CHARACTER O 134 0.293296089385 > (CHARACTER O 135 0.293296089385 > (CHARACTER O 133 0.263819095477 > (CHARACTER C j 0.249211356467 > (CHARACTER C T 0.214532871972 > (CHARACTER O 140 0.198863636364 > (CHARACTER C r 0.195238095238 > (CHARACTER C t 0.186813186813 > (CHARACTER C W 0.18488372093 > (CHARACTER C i 0.173501577287 > (CHARACTER C I 0.166246851385 > > This is not precisely the visual list of problematic characters, but > it was just my first idea ... > > Best, > Michael > > <fourier.pdf><mathptmx.pdf>------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev_______________________________________________ > PyX-devel mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Michael S. <m-s...@us...> - 2011-05-14 20:24:30
|
Salut André and Jörg, The checkin-rate looks like a developer-weekend..? On 14/05/11, André Wobst wrote: > this was a rounding issue fixed in changeset 3080. Are you sure? I tried rev.3080 on the minimal example in my e-mail, and for me it does not work yet. Enjoy your beer, Michael |
From: André W. <wo...@us...> - 2011-05-14 20:37:33
Attachments:
smime.p7s
|
Hi Michael, You are right. (Yes, it's a dev weekend, but you are right on the other issue as well.) We found and fixed a bug introduced due to rounding issues with an integer division. This was an example quite similar to yours which Jörg had available on his machine prepared for being looked at and fixed for the weekend. Now, this issue is resolved, but your problem looks different. At least it is indeed not yet fixed, although the problem looks rather similar, same and correct positioning in the dvitype, but wrong output. Thanks for pointing out, we'll try to find out what it's wrong here. André Am 14.05.2011 um 22:24 schrieb Michael SCHINDLER: > Salut André and Jörg, > > The checkin-rate looks like a developer-weekend..? > > On 14/05/11, André Wobst wrote: >> this was a rounding issue fixed in changeset 3080. > > Are you sure? I tried rev.3080 on the minimal example in my e-mail, > and for me it does not work yet. > > Enjoy your beer, > Michael > -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Joerg L. <jo...@us...> - 2011-05-14 21:40:42
|
Hi Michael, On 14.05.11, Michael SCHINDLER wrote: > On 14/05/11, André Wobst wrote: > > this was a rounding issue fixed in changeset 3080. > > Are you sure? I tried rev.3080 on the minimal example in my e-mail, > and for me it does not work yet. Another bug, and enough beer to have it fixed (in changeset 3081) :-) Enjoy, Jörg |