- ntg-pdftex - NTG Mailing Lists

[ pdftex-Feature Requests-715 ] highlight ligatures
by noreply＠sarovar.org 22 Dec '06

22 Dec '06

Feature Requests item #715, was opened at 2006-12-22 10:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=715&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Uli Laube (ulilaube) Assigned to: Nobody (None) Summary: highlight ligatures Initial Comment: Hello! >From time to time people in de.comp.text.tex ask for a solution to remove ligatures from german words automatically. As this requires quite some knowledge of the morphology of the german language, packages like rmligs or ligatex use lists of words to remove unwanted ligatures. As this depends on the ligatures available in the font used, it is quite troublesome to the compile the lists. I'am proposing the following addtion to be incorporated into pdftex: highlighting of the ligatures. If enabled pdftex uses a bold version of the font when it inserts ligatures in normal text and vice versa. Like /em and /emph work for italic text. This would allow the user of pdftex to prepare a draft copy of the document were all ligatures are highlighted and can be easily spotted. The user can then insert "| manually to remove the unwanted ligatures. Kind Regards and Happy Holidays Uli Laube ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-12-22 13:55 Message: Logged In: YES user_id=929 For highlighting a boldface font is needed that has the same metrics as the non-highlighted one, to keep paragraph breaking unchanged. What you can do right now is to generate a virtual font that contains colored ligatures! It is in fact possible to add PDF color change command specials into the .vpl virtual property list files of the virtual font, These commands will then be inserted into the PDF page stream in front of the glyphs. But also some solution on engine level should be doable. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Uli Laube (ulilaube) Date: 2006-12-22 11:22 Message: Logged In: YES user_id=4116 If a document uses different fonts, they might have different ligatures available. The special font and the macro packages might not be aware of this. As far as I know, the insertion of ligatures happens late when the .dvi oder .pdf is created. My hope is that switching to the bold version of the font when a ligature is inserted might be a way to have this feature work for all fonts. ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2006-12-22 11:08 Message: Logged In: YES user_id=3360 Since ligatures are inserted according to information in the fonts, I think this should be implemented as a combination of a special font (which uses noticeably different glyphs for ligatures), and a macro package that switches fonts. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=715&group_id=106

1 0

[ pdftex-Feature Requests-715 ] highlight ligatures
by noreply＠sarovar.org 22 Dec '06

22 Dec '06

Feature Requests item #715, was opened at 2006-12-22 10:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=715&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Uli Laube (ulilaube) Assigned to: Nobody (None) Summary: highlight ligatures Initial Comment: Hello! >From time to time people in de.comp.text.tex ask for a solution to remove ligatures from german words automatically. As this requires quite some knowledge of the morphology of the german language, packages like rmligs or ligatex use lists of words to remove unwanted ligatures. As this depends on the ligatures available in the font used, it is quite troublesome to the compile the lists. I'am proposing the following addtion to be incorporated into pdftex: highlighting of the ligatures. If enabled pdftex uses a bold version of the font when it inserts ligatures in normal text and vice versa. Like /em and /emph work for italic text. This would allow the user of pdftex to prepare a draft copy of the document were all ligatures are highlighted and can be easily spotted. The user can then insert "| manually to remove the unwanted ligatures. Kind Regards and Happy Holidays Uli Laube ---------------------------------------------------------------------- >Comment By: Uli Laube (ulilaube) Date: 2006-12-22 11:22 Message: Logged In: YES user_id=4116 If a document uses different fonts, they might have different ligatures available. The special font and the macro packages might not be aware of this. As far as I know, the insertion of ligatures happens late when the .dvi oder .pdf is created. My hope is that switching to the bold version of the font when a ligature is inserted might be a way to have this feature work for all fonts. ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2006-12-22 11:08 Message: Logged In: YES user_id=3360 Since ligatures are inserted according to information in the fonts, I think this should be implemented as a combination of a special font (which uses noticeably different glyphs for ligatures), and a macro package that switches fonts. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=715&group_id=106

1 0

[ pdftex-Feature Requests-715 ] highlight ligatures
by noreply＠sarovar.org 22 Dec '06

22 Dec '06

Feature Requests item #715, was opened at 2006-12-22 10:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=715&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Uli Laube (ulilaube) Assigned to: Nobody (None) Summary: highlight ligatures Initial Comment: Hello! >From time to time people in de.comp.text.tex ask for a solution to remove ligatures from german words automatically. As this requires quite some knowledge of the morphology of the german language, packages like rmligs or ligatex use lists of words to remove unwanted ligatures. As this depends on the ligatures available in the font used, it is quite troublesome to the compile the lists. I'am proposing the following addtion to be incorporated into pdftex: highlighting of the ligatures. If enabled pdftex uses a bold version of the font when it inserts ligatures in normal text and vice versa. Like /em and /emph work for italic text. This would allow the user of pdftex to prepare a draft copy of the document were all ligatures are highlighted and can be easily spotted. The user can then insert "| manually to remove the unwanted ligatures. Kind Regards and Happy Holidays Uli Laube ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2006-12-22 11:08 Message: Logged In: YES user_id=3360 Since ligatures are inserted according to information in the fonts, I think this should be implemented as a combination of a special font (which uses noticeably different glyphs for ligatures), and a macro package that switches fonts. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=715&group_id=106

1 0

[ pdftex-Feature Requests-715 ] highlight ligatures
by noreply＠sarovar.org 22 Dec '06

22 Dec '06

Feature Requests item #715, was opened at 2006-12-22 10:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=715&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Uli Laube (ulilaube) Assigned to: Nobody (None) Summary: highlight ligatures Initial Comment: Hello! >From time to time people in de.comp.text.tex ask for a solution to remove ligatures from german words automatically. As this requires quite some knowledge of the morphology of the german language, packages like rmligs or ligatex use lists of words to remove unwanted ligatures. As this depends on the ligatures available in the font used, it is quite troublesome to the compile the lists. I'am proposing the following addtion to be incorporated into pdftex: highlighting of the ligatures. If enabled pdftex uses a bold version of the font when it inserts ligatures in normal text and vice versa. Like /em and /emph work for italic text. This would allow the user of pdftex to prepare a draft copy of the document were all ligatures are highlighted and can be easily spotted. The user can then insert "| manually to remove the unwanted ligatures. Kind Regards and Happy Holidays Uli Laube ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=715&group_id=106

1 0

1.40-rc4
by Martin Schröder 21 Dec '06

21 Dec '06

http://sarovar.org/download.php/1131/pdftex-1.40.0-rc4.tar.bz2 http://sarovar.org/download.php/1132/pdftex-1.40.0-rc3-rc4.diff.gz We are almost there... ----------------------------------------------------- pdfTeX 3.141592-1.40.0-rc4 was released on 2006-12-22 ----------------------------------------------------- - changes from rc3: various small fixes In India (where sarovar stands) it' still the 21st. :-) I'll have a stab at integrating this into TL over christmas, and we'll work on the manual. If no serious bugs are detected, I'll do a realease next week. Best Martin

1 0

1.40-rc3
by Martin Schröder 21 Dec '06

21 Dec '06

http://sarovar.org/download.php/1129/pdftex-1.40.0-rc3.tar.bz2 http://sarovar.org/download.php/1130/pdftex-1.40.0-rc2-rc3.diff.gz We are getting nearer... ----------------------------------------------------- pdfTeX 3.141592-1.40.0-rc3 was released on 2006-12-20 ----------------------------------------------------- - changes from rc2: - map file handling: - in usual cases the behaviour is the same like in previous version. So if a font file is given with '<' or '<<', things should work without problems. - changes in odd cases: - no font file --> no font descriptor - font file given but not included --> will be treated like font file missing + a warning - minimize the distinction between standard fonts and other type1 fonts: the *only* place this makes a difference is that if a font file is missing (and the font is used), a warning will be generated for normal fonts but not for standard fonts

6 5

[ pdftex-Bugs-480 ] pdftex offset incorrect with \magnification. Patch included.
by noreply＠sarovar.org 21 Dec '06

21 Dec '06

Bugs item #480, was opened at 2006-02-12 18:12 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106 Category: None >Group: v1.30.0 Status: Open >Resolution: Wont Fix >Priority: 3 Submitted By: Ian Hutchinson (ihutch) Assigned to: Nobody (None) Summary: pdftex offset incorrect with \magnification. Patch included. Initial Comment: Any plain tex file that uses \magnification gives incorrect text placement in pdf. This bug is present in the latest pdftex version 1.21a. It apparently was caused by the introduction of the new variables \pdfvoffset and \pdfhoffset. This bug was not present in older pdftex, e.g. version 3.14159-1.10b, which was part of tetex-2... A simple illustration of the problem is with the trivial file: \magnification \magstep3 %The following parindent and offset changes are not the cause of errors. %They are merely to illustrate them clearly by writing at top left. %Anything other than \magstep0 gives a placement error with pdftex 1.21a. \parindent 0pt \hoffset -1 truein \voffset -1 truein The top. \end With tex and xdvi, the words "The top." are placed at the immediate top left. With pdftex 1.21a and xpdf (or acroread) they are not. With earlier pdftex 1.10b (e.g.) they are. I had an extensive discussion on comp.text.tex with Heiko Oberdiek, most of which is at http://www.codecomments.com/Tex/message784423.html The gist of it is that backward compatibility with plain tex files is very important. As far as possible, it should be preserved transparently. Authors should not be required to hack their files in order for them to render the same in pdf as in dvi. Moreover there is a simple way to provide this compatibility. A reasonable way to fix the bug is to change pdftex.ini and hence pdftex.fmt. (The corresponding pdfetex files ought also to be fixed.) A proposed patched pdftex.ini file is attached. It consists simply of % Thomas Esser, 1998, 2004. public domain. \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \input pdftexconfig \pdfoutput=1 \fi \fi \input plain \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \catcode`@=11 \def\m@g{% \mag\count@ \hsize6.5truein\vsize8.9truein\dimen\footins8truein %These commands fix the pdf sizes to be in true units. \mag@fix\pdfhorigin \mag@fix\pdfvorigin \mag@fix\pdfpagewidth \mag@fix\pdfpageheight } \def\mag@fix#1{% #1=\expandafter\convert@truept\the#1\relax } \begingroup \catcode`P=12 \catcode`T=12 \lowercase{% \endgroup \def\convert@truept#1PT{% #1truept% }% }% \catcode`@=12 \fi \fi \dump \endinput I don't know who takes responsibility for pdftex.ini. But clearly this ought to be fixed for all distributions. I care most about tetex, because it is what I use. Thanks, Ian Hutchinson ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 20:49 Message: Logged In: YES user_id=710 oh yes, thanks Phil for the correction. In response to Ian Hutchinson: I am the maintainer of neither pdftex.ini nor pdftex, so I feel that someone else must make the decision. ---------------------------------------------------------------------- Comment By: Philip TAYLOR (chaa006) Date: 2006-10-23 20:21 Message: Logged In: YES user_id=3040 Thanh wrote : I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in Surely they should write \pdfhorigin = 1 true in \pdfvorigin = 1 true in should they not ? I always do, and it certainly has the intended effect. ** Phil. ---------------------------------------------------------------------- Comment By: Ian Hutchinson (ihutch) Date: 2006-10-23 19:49 Message: Logged In: YES user_id=3410 In response to hanthethanh, let me explain once again that the point is that TeX ought always to work the same with both dvi output and pdf output. The latest pdftex breaks that for all documents, old or new, that use \magnification. Of course there are many ways the authors can fix those documents by adding new commands. BUT THEY SHOULD NOT HAVE TO. TeX's archival integrity is far too valuable for us to accept it being broken by this incompatibility. I've shown how it can be transparently fixed. The correction just needs to be incorporated into the distributions ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 12:37 Message: Logged In: YES user_id=710 I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in or something similar. An undocumented trick is that if \pdfhorigin or \pdfvorigin is not set (or set to 0) when the first page is shipped out, then they will get 1in as the default value. To get zero origin(s), use 1sp instead of 0. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106

1 0

[ pdftex-Bugs-712 ] problems with \letterspacefont
by noreply＠sarovar.org 21 Dec '06

21 Dec '06

Bugs item #712, was opened at 2006-12-12 03:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=712&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: problems with \letterspacefont Initial Comment: % Testing the new \letterspacefont, I found: % % (1) it's certainly not correct to have the spacing % relative to character widths (look at `minimal'!) % (2) everything's shifted to the right % (3) when trying to expand the letter-spaced font, I % get the warning `font should be expanded before % its first use' (even before its first use), and % then pdftex segfaults. \pdfadjustspacing2 \hsize13cm This is normal text This is normal text This is normal text This is normal text This is normal text This is normal text {\letterspacefont\lspfont=\font 1000 %\pdffontexpand\lspfont 20 20 5 autoexpand % segfault \lspfont This isn't normal text This isn't normal text This isn't normal text This is minimal text} This is normal text This is normal text This is normal text \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:09 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-12 18:47 Message: Logged In: YES user_id=710 oops, I disabled ligature for letter-spaced font, but this should not affect the base font. Will have to rethink. Most likely the syntax will change like follows: \letterspacefont\f=cmr10 at 11pt 100 \f text ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-12-12 16:50 Message: Logged In: YES user_id=2217 % and here's % (4) ligatures will be broken up, not only in the % letter-spaced font (which is probably acceptable), % but in all subsequent uses of the base font, too fi\par {\letterspacefont\lspfont=\font 100 \lspfont fi}\par fi \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-12 14:31 Message: Logged In: YES user_id=710 I fixed (1) and (2); (3) is disabled now, ie you cannot expand a letter-spaced font. Please wait for another release from Martin. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=712&group_id=106

1 0

[ pdftex-Bugs-695 ] Confusion when changing kerning settings within a paragraph
by noreply＠sarovar.org 21 Dec '06

21 Dec '06

Bugs item #695, was opened at 2006-11-15 02:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=695&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Confusion when changing kerning settings within a paragraph Initial Comment: Extra kerning now has this nasty, unreliable kind of paragraph scope, so that whether or not extra kerning will be applied depends on whether tex needs to hyphenate the paragraph, and whether a word contains a discretionary. (Same as for \pdfnoligatures [see discussion in feature req 385], for which this may be an acceptable limitation, since it has global scope, anyway. However, I don't consider it acceptable for the kerning feature. Think of language-dependant settings, for example.) \hsize 7cm \pdfadjustspacing0 \knaccode\font`s=500 \knbccode\font`s=500 \pdfappendkern1 \pdfprependkern1 nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing \pdfappendkern0 \pdfprependkern0 nasty testing nasty testing nasty testing nasty testing nasty testing \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:08 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=695&group_id=106

1 0

[ pdftex-Bugs-694 ] Extra kerning doesn't work in lines composed with expanded fonts
by noreply＠sarovar.org 21 Dec '06

21 Dec '06

Bugs item #694, was opened at 2006-11-15 02:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=694&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Extra kerning doesn't work in lines composed with expanded fonts Initial Comment: \pdftracingfonts2 \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \hsize 4cm \pdfprependkern1 \knbccode\font`:=500 \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand yyy: yyy: yyy: yyy: yyy: yyy: \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:08 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=694&group_id=106

1 0

[ pdftex-Bugs-693 ] No extra kerning before a character if it starts a word
by noreply＠sarovar.org 21 Dec '06

21 Dec '06

Bugs item #693, was opened at 2006-11-15 02:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=693&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: No extra kerning before a character if it starts a word Initial Comment: \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \pdfprependkern1 \knbccode\font`x=1000 xyx xyx \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:08 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=693&group_id=106

1 0

[ pdftex-Bugs-692 ] Amount of extra kerning is wrong/has changed
by noreply＠sarovar.org 21 Dec '06

21 Dec '06

Bugs item #692, was opened at 2006-11-15 02:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=692&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Amount of extra kerning is wrong/has changed Initial Comment: With \kn[ab]ccode=1000 a kern of 1em should be inserted. (Here, it's 2.32pt:) \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \pdfappendkern1 \pdfprependkern1 \knaccode\font`y=1000 \knbccode\font`y=1000 xyx \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:06 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-11-19 11:10 Message: Logged In: YES user_id=710 This bug is caused by missing of declaration of k inside the function get_auto_kern, hence the global variable k is taken with wrong type (eight_bits). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-11-17 16:12 Message: Logged In: YES user_id=2217 In fact, the kerning amount wraps at a kerning code of 256: \tracingoutput1 \showboxbreadth\maxdimen \pdfappendkern1 \knaccode\font`y=255 y % 2.55pt \knaccode\font`y=257 y % 0.01pt \knaccode\font`y=513 y % 0.01pt \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=692&group_id=106

1 0

[ pdftex-Bugs-696 ] pdftex always autoexpands -- even if it shouldn't
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Bugs item #696, was opened at 2006-11-15 02:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106 Category: hz Group: v1.40.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: pdftex always autoexpands -- even if it shouldn't Initial Comment: pdftex is now a bit too keen on autoexpanding -- it does so, even if `autoexpand' is not specified. Although the pre-created metrics are read, the physical font (pfb resp. pk) is ignored. As has been discussed re: bugs/304, *not* using autoexpansion gives better results for MM (and MF) fonts, since the fonts are not stretched blindly but stroke widths are adjusted etc. I've moved the test file from bugs/304 here. Another example is (with an existing file cmr10+100.mf): \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr =cmr10 \cmr \pdffontexpand\cmr 100 0 100 %autoexpand Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-20 16:26 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106

1 0

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Bugs item #304, was opened at 2005-03-02 18:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a >Status: Closed Resolution: Fixed Priority: 3 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-20 16:26 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-11-15 02:23 Message: Logged In: YES user_id=2217 problem with autoexpanding now at bugs/696 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 12:23 Message: Logged In: YES user_id=710 Here is an attempt to fix this problem (reversed patch attached). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-03 19:30 Message: Logged In: YES user_id=2217 I've attached an example using Kepler MM (tfm+pfb included, please delete after testing). MM fonts are probably the only case where one would not want to use the autoexpand feature. At first sight, saying "autoexpand" or not doesn't seem to make a difference, since pdftex will always prefer existing expanded fonts (pfb) over autoexpanding them, anyway. However, there are some slight differences in the pdf. This is probably because the provided tfm file is different from the metrics that pdf calculates itself in the case of autoexpand. That is, autoexpand may result in a mismatch between the provided pfb and the calculated tfm, is that correct? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-01 21:02 Message: Logged In: YES user_id=929 currently i even can't get a test file do expansion at all without "autoexpand". E. g. Robert's example above, without "autoexpand", doesn't use expanded fonts. Maybe that's the reason for the missing expand parameter in the log? Can anybody provide a test file for this case? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:47 Message: Logged In: YES user_id=421 Is this really a problem, i.e. is there a reason _not_ to use the autoexpand feature in new documents? Hartmut, did you look into this bug? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-16 00:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 17:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 22:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\tenrm t ...\tenrm (+20) e Without font expansion, this default should be compatible with TeX's original log output. If \pdftracingfonts is set to 1 (or greater), we get a more verbose log (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

[ pdftex-Patches-709 ] merging patch 597 by Hartmut
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Patches item #709, was opened at 2006-12-04 09:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106 Category: Fonts Group: v1.40.0 Status: Closed >Resolution: Accepted Priority: 6 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: merging patch 597 by Hartmut Initial Comment: This is a patch against pdftex-1.40.0-beta-20061018 that merges patch 597 by Hartmut and does some clean up in the font mechanism. Testing welcome very much. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-06 18:05 Message: Logged In: YES user_id=710 patch updated to fix a bug with pdf inclusion. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-05 23:52 Message: Logged In: YES user_id=710 patch updated; tested with pdftex manual, microtype manual and base latex doc. A fix for bug #693 is included. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 14:38 Message: Logged In: YES user_id=710 ah, sorry, my mistake. It's against pdftex-1.40.0-beta-20061108 (the latest beta), not pdftex-1.40.0-beta-20061018 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 14:25 Message: Logged In: YES user_id=710 are you saying that you have troubles applying the patch against pdftex-1.40.0-beta-20061017? Can you please try to apply against pdftex-1.40.0-beta-20061018? I have checked everything again from the beginning as follows: - download and unpack http://sarovar.org/download.php/1100/pdftex-1.40.0-beta-20061017.tar.bz2 - download, ungzip and apply http://sarovar.org/download.php/1108/pdftex-1.40.0-beta-20061017-20061108.d… - download http://sarovar.org/tracker/download.php/106/495/709/237/pdftex-20061204-2.p… - cd /path/to/pdftex-1.40.0-beta-20061017/src - patch -p1 --dry-run /path/to/pdftex-20061204-2.patch The patch applied ok, apart from change-files.txt (I removed it from pdftexdir, as it's no longer relevant to pdftex). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-04 13:33 Message: Logged In: YES user_id=421 I'm having troubles applying pdftex-20061204-2.patch against pdftex-1.40.0-beta-20061017, especially pdftex.web. Can you attach a diff against 1.40.0-beta-20061108 or your patched pdftex.web? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 12:02 Message: Logged In: YES user_id=710 I updated the patch to revert auto kerns to be explicit. This will disable hyphenation if auto kern is used. On the other hand this is much more robust. The pending problems are: bug #693: still trying bug #484: will not be fixed, better treat it as a limitation bug #465: unlikely to be fixed ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106

1 0

[ pdftex-Patches-709 ] merging patch 597 by Hartmut
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Patches item #709, was opened at 2006-12-04 09:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106 Category: Fonts Group: v1.40.0 >Status: Closed Resolution: None Priority: 6 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: merging patch 597 by Hartmut Initial Comment: This is a patch against pdftex-1.40.0-beta-20061018 that merges patch 597 by Hartmut and does some clean up in the font mechanism. Testing welcome very much. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-06 18:05 Message: Logged In: YES user_id=710 patch updated to fix a bug with pdf inclusion. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-05 23:52 Message: Logged In: YES user_id=710 patch updated; tested with pdftex manual, microtype manual and base latex doc. A fix for bug #693 is included. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 14:38 Message: Logged In: YES user_id=710 ah, sorry, my mistake. It's against pdftex-1.40.0-beta-20061108 (the latest beta), not pdftex-1.40.0-beta-20061018 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 14:25 Message: Logged In: YES user_id=710 are you saying that you have troubles applying the patch against pdftex-1.40.0-beta-20061017? Can you please try to apply against pdftex-1.40.0-beta-20061018? I have checked everything again from the beginning as follows: - download and unpack http://sarovar.org/download.php/1100/pdftex-1.40.0-beta-20061017.tar.bz2 - download, ungzip and apply http://sarovar.org/download.php/1108/pdftex-1.40.0-beta-20061017-20061108.d… - download http://sarovar.org/tracker/download.php/106/495/709/237/pdftex-20061204-2.p… - cd /path/to/pdftex-1.40.0-beta-20061017/src - patch -p1 --dry-run /path/to/pdftex-20061204-2.patch The patch applied ok, apart from change-files.txt (I removed it from pdftexdir, as it's no longer relevant to pdftex). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-04 13:33 Message: Logged In: YES user_id=421 I'm having troubles applying pdftex-20061204-2.patch against pdftex-1.40.0-beta-20061017, especially pdftex.web. Can you attach a diff against 1.40.0-beta-20061108 or your patched pdftex.web? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 12:02 Message: Logged In: YES user_id=710 I updated the patch to revert auto kerns to be explicit. This will disable hyphenation if auto kern is used. On the other hand this is much more robust. The pending problems are: bug #693: still trying bug #484: will not be fixed, better treat it as a limitation bug #465: unlikely to be fixed ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106

1 0

[ pdftex-Patches-705 ] Patch to allow vf_nf grow dynamically
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Patches item #705, was opened at 2006-11-22 20:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106 Category: Fonts Group: v1.40.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: Patch to allow vf_nf grow dynamically Initial Comment: This patch allows the array vf_e_fnts and vf_i_fnts grow dynamically, instead of having fixed size font_max as currently. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-11-26 21:01 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-25 10:58 Message: Logged In: NO Hi! It's been applied on Debian/unstable, and it works! Top notch! Thanks Danai SAE-HAN ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-11-23 08:18 Message: Logged In: YES user_id=710 yes. this patch also contains a fix by Akira the segfault bug (one line added) and a fix for bug #692 (another line). It's not hard to fix bug #694 and #696 too. However I didn't mention them, as I am considering to remove the relevant code. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-23 02:26 Message: Logged In: NO Hi! Does this mean that the bug "SGML output fails with pdflatex" will also be solved? Cheers Danai SAE-HAN ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106

1 0

[ pdftex-Patches-580 ] Patch to make ToUnicode for Type1 fonts
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Patches item #580, was opened at 2006-07-14 22:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=580&group_id=106 Category: None Group: v1.40.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to make ToUnicode for Type1 fonts Initial Comment: This is a patch to pdftex so that it can create ToUnicode entries for Type1 fonts. The main purpose is to make ligatures and some other glyphs like smallcap letters or oldstyle digits from OpenType fonts searchable. This patch also contains a minor fix that allows use of fonts without embedding, for example MinionPro or MyriadPro (which are distributed with Acrobat Reader >= 7.0 but from their use is restricted with Acrobat Reader only). How to apply: ~~~~~~~~~~~~~ - this patch applies to the pristine pdftex-1.40.0-beta-20060213 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - how to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20060213/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdfetex `-------- If you want to be careful, try the patch with the option '--dry-run' first to see whether the patch can be applied without problems. Usage: ~~~~~~ add the following lines into your document, somewhere at the beginning: ,-------- | \input glyphtounicode.tex | \pdfgentounicode=1 `-------- Customization: ~~~~~~~~~~~~~ If pdftex cannot generate the right ToUnicode value for some glyphs (probably because the glyph name is not ``known'' to pdftex), it's possible to add further entries so pdftex can learn how to generate unicode for such ``unknown'' glyphs. The syntax is simple: \pdfglyphtounicode{<glyph-name>}{<unicode-value>} Example: \pdfglyphtounicode{A}{0041} says that glyph 'A' has its unicode U+0041 The entries in glyphtounicode.tex cover Adobe Glyph List (glyphlist.txt version 2.0) and some addtional glyphs (texglyphlist.txt version 2.33, coming from from lcdf-typetools), plus some additional entries for ligatures. If some glyph name cannot be found, pdftex does some simple name translations: - remove any ".xxx" suffix from glyph name, where "xxx" is a string consisting of alphabetic characters. For example "A.sc" => "A" - remove suffix like "small", "oldstyle", "inferior" and "superior" from glyph name. For example "Asmall" => "A" The result name then is looked up again to find a unicode. Ligatures require a special form of ToUnicode. Example: \pdfglyphtounicode{ff}{00660066} here '0066' is the unicode string for 'f'. Some ligatures have their name like 'f_f_i', in such case the command should be \pdfglyphtounicode{f_f_i}{006600660069} ie '_' is removed from the glyph name, and then all letters are translated to their unicode string. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-17 15:39 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-07 11:44 Message: Logged In: YES user_id=710 Patch updated to fix a bug reported by Akira. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-06 13:34 Message: Logged In: YES user_id=710 This is a patch to pdftex that includes: - a fix for bug #611 - some changes to ToUnicode support (patch #580) to make the implementation follow guidelines at http://partners.adobe.com/public/developer/opentype/index_glyph.html How to apply: ~~~~~~~~~~~~~ - this patch applies to the pristine pdftex-1.40.0-beta-20060928 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - how to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20060928/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- If you want to be careful, try the patch with the option '--dry-run' first to see whether the patch can be applied without problems. Usage: ~~~~~~ add the following lines into your document, somewhere at the beginning: ,-------- | \input glyphtounicode.tex | \pdfgentounicode=1 `-------- Customization: ~~~~~~~~~~~~~ If pdftex cannot generate the right ToUnicode value for some glyphs (probably because the glyph name is not ``known'' to pdftex), it's possible to add further entries so pdftex can learn how to generate unicode for such ``unknown'' glyphs. The syntax is simple: ,-------- | \pdfglyphtounicode{<glyph-name>}{<unicode-value>} `-------- Example: ,-------- | \pdfglyphtounicode{A}{0041} `-------- says that glyph 'A' has its unicode U+0041. \pdfglyphtounicode requires that the second parameter consists of uppercase hexadecimal digits (0..9, A..F) and spaces. If this is not the case the entry is simply discarded (with a warning). Later entries overwrite previous entries with the same name (1st arg). The entries in glyphtounicode.tex cover: - glyphlist.txt (Adobe Glyph List v2.0) - zapfdingbats.txt (ITC Zapf Dingbats Glyph List v2.0) - texglyphlist.txt (lcdf-typetools texglyphlist.txt v2.33) - additional.tex (additional entries) Ligatures require a special form of ToUnicode. Example: ,-------- | \pdfglyphtounicode{ff}{00660066} `-------- here '0066' is the unicode string for 'f'. Spaces are ignored in the second parameter of \pdfglyphtounicode, hence it is possible to write the above command as ,-------- | \pdfglyphtounicode{ff}{0066 0066} `-------- which is easier to read and understand IMO. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-07-19 08:08 Message: Logged In: YES user_id=710 patch updated to fix a bug reported by Dohyun Kim ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-07-16 13:19 Message: Logged In: YES user_id=710 patch updated by a bug fix from Akira ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=580&group_id=106

1 0

[ pdftex-Patches-462 ] HZ font expansion by text matrix manipulation
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Patches item #462, was opened at 2005-12-23 23:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106 Category: Positioning Group: v1.40.0 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: HZ font expansion by text matrix manipulation Initial Comment: Use textmatrix Tm instead of /FontMatrix for font expansion. Then a font file will be embedded only once for all expansion factors. Gives smaller PDF files. Works then also for non-embedded fonts. TrueType not tried yet. Rough patch only, incomplete, work in progress, no warranty, not for production. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-01 11:26 Message: Logged In: YES user_id=421 We've removed it from beta again; it introduces additional problems and needs more time to stabilize. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-30 16:22 Message: Logged In: YES user_id=2217 It's great to have this included! However, pdftex is now a bit too keen on autoexpanding -- it does so, even if `autoexpand' is not specified. Although the pre-created metrics are read, the physical font (pfb resp. pk) is ignored. As has been discussed re: bug 304, *not* using autoexpansion gives better results for MM (and MF) fonts, since the fonts are not stretched blindly but stroke widths are adjusted etc. Compare the output of the test file from bugs/304 compiled with an old pdftex and with 20060928. With the latter, the strokes are slightly heavier. Same here (with an existing file cmr10+100.mf): \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr =cmr10 \cmr \pdffontexpand\cmr 100 0 100 %autoexpand Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 19:41 Message: Logged In: YES user_id=421 The last word from Hartmut was that it's not ready yet and he'd be working on an improved version. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-02-13 19:05 Message: Logged In: YES user_id=2217 Will this make it into 1.40? I would love to see it included. I've tested it a bit and did not find any problems (I'm also using it for the pre-built microtype documentation on CTAN). Regards, Robert ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106

1 0

[ pdftex-Bugs-696 ] pdftex always autoexpands -- even if it shouldn't
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Bugs item #696, was opened at 2006-11-15 02:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106 Category: hz Group: v1.40.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: pdftex always autoexpands -- even if it shouldn't Initial Comment: pdftex is now a bit too keen on autoexpanding -- it does so, even if `autoexpand' is not specified. Although the pre-created metrics are read, the physical font (pfb resp. pk) is ignored. As has been discussed re: bugs/304, *not* using autoexpansion gives better results for MM (and MF) fonts, since the fonts are not stretched blindly but stroke widths are adjusted etc. I've moved the test file from bugs/304 here. Another example is (with an existing file cmr10+100.mf): \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr =cmr10 \cmr \pdffontexpand\cmr 100 0 100 %autoexpand Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-20 16:26 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106

1 0

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Bugs item #304, was opened at 2005-03-02 18:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Open >Resolution: Fixed Priority: 3 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-20 16:26 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-11-15 02:23 Message: Logged In: YES user_id=2217 problem with autoexpanding now at bugs/696 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 12:23 Message: Logged In: YES user_id=710 Here is an attempt to fix this problem (reversed patch attached). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-03 19:30 Message: Logged In: YES user_id=2217 I've attached an example using Kepler MM (tfm+pfb included, please delete after testing). MM fonts are probably the only case where one would not want to use the autoexpand feature. At first sight, saying "autoexpand" or not doesn't seem to make a difference, since pdftex will always prefer existing expanded fonts (pfb) over autoexpanding them, anyway. However, there are some slight differences in the pdf. This is probably because the provided tfm file is different from the metrics that pdf calculates itself in the case of autoexpand. That is, autoexpand may result in a mismatch between the provided pfb and the calculated tfm, is that correct? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-01 21:02 Message: Logged In: YES user_id=929 currently i even can't get a test file do expansion at all without "autoexpand". E. g. Robert's example above, without "autoexpand", doesn't use expanded fonts. Maybe that's the reason for the missing expand parameter in the log? Can anybody provide a test file for this case? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:47 Message: Logged In: YES user_id=421 Is this really a problem, i.e. is there a reason _not_ to use the autoexpand feature in new documents? Hartmut, did you look into this bug? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-16 00:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 17:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 22:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\tenrm t ...\tenrm (+20) e Without font expansion, this default should be compatible with TeX's original log output. If \pdftracingfonts is set to 1 (or greater), we get a more verbose log (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

Re: [NTG-pdftex] suspicious line in vfpacket.c
by Thanh Han The 18 Dec '06

18 Dec '06

yes indeed. Thanks for pointing it out. Thanh On Mon, Dec 18, 2006 at 05:27:25PM +0100, Taco Hoekwater wrote: > Hi guys, > > This function looks odd to me. My guess is that the > second fontec should be fontbc. > > Best, Taco > > > void vf_free(void) > { > vf_entry *v; > int n; > char **p; > if (vf_array != NULL) { > for (v = vf_array; v < vf_ptr; v++) { > xfree(v->len); > n = fontec[v->font] - fontec[v->font] + 1; > for (p = v->data; p - v->data < n; p++) > xfree(*p); > xfree(v->data); > } > xfree(vf_array); > } > xfree(packet_array); > } > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex

1 0

suspicious line in vfpacket.c
by Taco Hoekwater 18 Dec '06

18 Dec '06

Hi guys, This function looks odd to me. My guess is that the second fontec should be fontbc. Best, Taco void vf_free(void) { vf_entry *v; int n; char **p; if (vf_array != NULL) { for (v = vf_array; v < vf_ptr; v++) { xfree(v->len); n = fontec[v->font] - fontec[v->font] + 1; for (p = v->data; p - v->data < n; p++) xfree(*p); xfree(v->data); } xfree(vf_array); } xfree(packet_array); }

1 0

[ pdftex-Bugs-714 ] Inclusion of PDF1.7 reference fails with lookup_fd_entry: Assertion `s != ((void *)0)'
by noreply＠sarovar.org 14 Dec '06

14 Dec '06

Bugs item #714, was opened at 2006-12-14 00:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=714&group_id=106 Category: Fonts Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: Inclusion of PDF1.7 reference fails with lookup_fd_entry: Assertion `s != ((void *)0)' Initial Comment: The attached test (including the PDF 1.7 reference) fails with [...] <use pdf17.pdf, page 22> <use pdf17.pdf, page 23> <use pdf17.pdf, page 24> [1 <./pdf17.pdf{/home/ms/.texmf-var/fonts/map/pdftex/updmap/pdftex.map}> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17. pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdfpdflatex: ../../../../src/texk/web2c/pdftexdir/writefont.c:192: lookup_fd_entry: Assertion `s != ((void *)0)' failed. Abgebrochen (core dumped) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 02:21 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-12-14 02:14 Message: Logged In: YES user_id=929 it happened with the map line "rpsyr Symbol" containing one of the 14 standard font names, but no font file name. These map lines are useful for typesetting, but not for font replacement. Still this was tried, as a check for missing font file was missing. The patch should repair this. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 01:33 Message: Logged In: YES user_id=421 Since this doesn't happen with \pdfmapline{}, I've attached the pdftex.map used. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 00:51 Message: Logged In: YES user_id=421 bt from core: #0 0x00002af9ad264aa5 in raise () from /lib64/libc.so.6 #1 0x00002af9ad265e60 in abort () from /lib64/libc.so.6 #2 0x00002af9ad25e246 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000489f58 in lookup_fd_entry (s=0x0, slant=0, extend=0) at ../../../../src/texk/web2c/pdftexdir/writefont.c:192 #4 0x00000000004a1fa3 in epdf_create_fontdescriptor (fm=0xdbd410) at ../../../../src/texk/web2c/pdftexdir/epdf.c:40 #5 0x000000000049bce2 in copyFont (tag=0xa3e6b0 "T1_3", fontRef=0x7ffffdae4ef0) at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:396 #6 0x000000000049c1a2 in copyFontResources (obj=0x7ffffdae5120) at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:426 #7 0x000000000049cfb2 in write_epdf () at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:928 #8 0x000000000049a767 in writeimage (img=14) at ../../../../src/texk/web2c/pdftexdir/writeimg.c:348 #9 0x000000000044a3b8 in zpdfwriteimage (n=15) at pdftex2.c:384 #10 0x0000000000451a57 in zpdfshipout (p=5967, shippingpage=1) at pdftex2.c:2856 #11 0x00000000004532c6 in zshipout (p=5967) at pdftex2.c:3398 #12 0x000000000046a82f in zboxend (boxcontext=1073807360) at pdftex2.c:11127 #13 0x000000000046adfe in zbeginbox (boxcontext=1073807360) at pdftex2.c:11307 #14 0x000000000046ae3b in zscanbox (boxcontext=1073807360) at pdftex2.c:11322 #15 0x00000000004789d9 in maincontrol () at pdftex3.c:5478 #16 0x0000000000416787 in mainbody () at pdftexini.c:5664 #17 0x000000000047ee9b in main (ac=2, av=0x7ffffdae54b8) at pdftexextra.c:341 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 00:49 Message: Logged In: YES user_id=421 attached the log file ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=714&group_id=106

1 0

[ pdftex-Bugs-714 ] Inclusion of PDF1.7 reference fails with lookup_fd_entry: Assertion `s != ((void *)0)'
by noreply＠sarovar.org 14 Dec '06

14 Dec '06

Bugs item #714, was opened at 2006-12-14 00:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=714&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: Inclusion of PDF1.7 reference fails with lookup_fd_entry: Assertion `s != ((void *)0)' Initial Comment: The attached test (including the PDF 1.7 reference) fails with [...] <use pdf17.pdf, page 22> <use pdf17.pdf, page 23> <use pdf17.pdf, page 24> [1 <./pdf17.pdf{/home/ms/.texmf-var/fonts/map/pdftex/updmap/pdftex.map}> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17. pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdfpdflatex: ../../../../src/texk/web2c/pdftexdir/writefont.c:192: lookup_fd_entry: Assertion `s != ((void *)0)' failed. Abgebrochen (core dumped) ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-12-14 02:14 Message: Logged In: YES user_id=929 it happened with the map line "rpsyr Symbol" containing one of the 14 standard font names, but no font file name. These map lines are useful for typesetting, but not for font replacement. Still this was tried, as a check for missing font file was missing. The patch should repair this. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 01:33 Message: Logged In: YES user_id=421 Since this doesn't happen with \pdfmapline{}, I've attached the pdftex.map used. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 00:51 Message: Logged In: YES user_id=421 bt from core: #0 0x00002af9ad264aa5 in raise () from /lib64/libc.so.6 #1 0x00002af9ad265e60 in abort () from /lib64/libc.so.6 #2 0x00002af9ad25e246 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000489f58 in lookup_fd_entry (s=0x0, slant=0, extend=0) at ../../../../src/texk/web2c/pdftexdir/writefont.c:192 #4 0x00000000004a1fa3 in epdf_create_fontdescriptor (fm=0xdbd410) at ../../../../src/texk/web2c/pdftexdir/epdf.c:40 #5 0x000000000049bce2 in copyFont (tag=0xa3e6b0 "T1_3", fontRef=0x7ffffdae4ef0) at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:396 #6 0x000000000049c1a2 in copyFontResources (obj=0x7ffffdae5120) at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:426 #7 0x000000000049cfb2 in write_epdf () at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:928 #8 0x000000000049a767 in writeimage (img=14) at ../../../../src/texk/web2c/pdftexdir/writeimg.c:348 #9 0x000000000044a3b8 in zpdfwriteimage (n=15) at pdftex2.c:384 #10 0x0000000000451a57 in zpdfshipout (p=5967, shippingpage=1) at pdftex2.c:2856 #11 0x00000000004532c6 in zshipout (p=5967) at pdftex2.c:3398 #12 0x000000000046a82f in zboxend (boxcontext=1073807360) at pdftex2.c:11127 #13 0x000000000046adfe in zbeginbox (boxcontext=1073807360) at pdftex2.c:11307 #14 0x000000000046ae3b in zscanbox (boxcontext=1073807360) at pdftex2.c:11322 #15 0x00000000004789d9 in maincontrol () at pdftex3.c:5478 #16 0x0000000000416787 in mainbody () at pdftexini.c:5664 #17 0x000000000047ee9b in main (ac=2, av=0x7ffffdae54b8) at pdftexextra.c:341 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 00:49 Message: Logged In: YES user_id=421 attached the log file ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=714&group_id=106

1 0