Hello Gert and Michael,
On 12.03.08, Gert Ingold wrote:
> to me it does not look like a wrong character but to a wrong kerning.
You're right, thanks for the hint!
> utmr8a only contains the fi and fl ligatures but not the ff ligature.
> Does PyX somewhere try to produce a fake ligature?
Yes, indeed. The following is the relevant part of the output of PyX's
debug mode - when I manually enable the debugging output for the VF's
dvi chunks, as well:
110: fntnum14 current font is ptmr7t
111: setchar11 h:=0+420080=420080, hh:=???
0: fntnum0 current font is ptmr8r
0: setchar102 h:=0+218232=218232, hh:=???
[f]
1: w2 -26214 h:=218232-26214=192018, hh:=???
4: setchar102 h:=192018+218232=410250, hh:=???
[f]
Note the line "1: w2..." which does the kerning. While it seems
to be impossible to get this detailed output via dvitype, one can
replace the VF code via dvicopy and then use dvitype. This yields:
134: fntnum0 current font is ptmr8r
135: setchar102 h:=0+218232=218232, hh:=14
136: w2 -16384 h:=218232-16384=201848, hh:=13
139: setchar102 h:=201848+218232=420080, hh:=27
[ff]
Note how the kerning is different by a factor of 1.6, which is exactly
the rescale factor between the new (in the VF's dvi chunk) and originial
DVI units.
In fact, that's all not too surprising, because the handling of the
various scaling factors in PyX's dvi-file code is a mess. I think I
didn't make it worse by the changes I just checked in, which more or
less heuristically solve this issue. We really have to cleanup this code
at some point...
Michael: Maybe you could add a test case for this ligature to
test_font.py.
Best,
Joerg
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
PyX-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-devel
