- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-736 ] font expansion leads to wrong log output of \kerns.
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #736, was opened at 2007-02-22 03:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=736&group_id=106 Category: hz Group: v1.40.1 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: font expansion leads to wrong log output of \kerns. Initial Comment: When applying font expansion, implicit kerns will be output *with* a space in the log file, which makes them appear like explicit kerns. The following \tracingoutput1 \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand bye\bye will yield ...\tenrm b ...\kern -0.27779 ...\tenrm y ...\kern -0.27779 ...etc. instead of ...\tenrm b ...\kern-0.27779 ...\tenrm y ...\kern-0.27779 ...etc. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-24 23:44 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-28 15:16 Message: Logged In: YES user_id=710 Here is an attempt to fix the bug. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-22 11:46 Message: Logged In: YES user_id=710 I confirm the bug. Will try to fix it soon. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=736&group_id=106

1 0

[ pdftex-Bugs-721 ] Missing /Font object of PK file not found
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #721, was opened at 2007-01-23 21:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=721&group_id=106 Category: Fonts Group: v1.40.1 Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Missing /Font object of PK file not found Initial Comment: There are several cases, the buggy one is no. 3. See test files test1...4.tex in the attached file. 1. No TFM file found in the 1st place. ---> No TeX font will be started. Ok. See test1.tex. 2. TFM file found, map entry existing, but no PFB font file in map line ---> "pdfTeX warning: pdftex: font `CMR' is not a standard font; I suppose it is available to your PDF viewer then". Ok. See test2.tex. 3. TFM file found, no map entry, and no PK font available. ---> "pdfTeX warning: pdftex (file mf-nonexist): Font mf-nonexist at 600 not found". Not ok. See test3.tex. Here a /Font object is referenced, which is not existing, rendering the resulting PDF file buggy. There should be either pdftex_fail() or or at least a /Font object with a dummy /FontDescriptor object should be created (the latter filled with defaults from the TFM file), and the same warning should be given as in case 4 below, since these cases are similar: fontfile expected, but not available. 4. TFM file found, map entry with PFB font file existing, but no PFB font file found. ---> "pdfTeX warning: pdftex (file t1-nonexist.pfb): cannot open Type 1 font file for reading". /FontDescriptor without /FontFile, correct. Ok. See test4.tex. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-24 22:40 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 12:48 Message: Logged In: YES user_id=710 patch updated, a typo was in the previous one. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 09:58 Message: Logged In: YES user_id=710 Here is a patch to turn some warnings that can lead to invalid pdf output to fatal errors. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=721&group_id=106

1 0

[ pdftex-Bugs-722 ] PDF generation does not support VF fonts correctly
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #722, was opened at 2007-01-24 09:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=722&group_id=106 Category: Fonts Group: v1.40.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Achim Blumensath (blume) Assigned to: The Thanh Han (hanthethanh) Summary: PDF generation does not support VF fonts correctly Initial Comment: I've a problem with using VF fonts in PDF mode (using pdftex 1.40.1, pdftex 1.20b does work correctly). When using glyphs that are composed of several other glyphs the various parts appear not at their correct position. The following example requires the MnSymbol and the MinionPro packages. \documentclass{minimal} \usepackage[T1]{fontenc} \usepackage[minionint]{MinionPro} \begin{document} $$\iint \quad \oint$$ \end{document} If you create a DVI and use dvips + ps2pdf the output is as expected (one double integral and one closed integral). If you use pdflatex to create a PDF file directly then the output is wrong. The double integral consists of just one integral sign and the closed integral consists of a circle followed by an integral sign. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-24 23:05 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-27 23:29 Message: Logged In: YES user_id=710 Bugfix resubmitted, this time without the new primitive \pdfreplacefont ---------------------------------------------------------------------- Comment By: Achim Blumensath (blume) Date: 2007-01-31 09:41 Message: Logged In: YES user_id=4173 The patch seems to work fine. Thanks. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-29 20:46 Message: Logged In: YES user_id=710 I made some changes in pdftex. Your test file looks almost ok now :). Can you please try the patch to see whether it works for you. Since I don't have exactly the same fonts you used, it might be helpful if you try the patch with your tex setup. Thanks. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-26 11:55 Message: Logged In: YES user_id=710 indeed this is a bug of pdftex. I found the bug, should be fixed soon. ---------------------------------------------------------------------- Comment By: Achim Blumensath (blume) Date: 2007-01-26 09:47 Message: Logged In: YES user_id=4173 Sorry, I forgot to mention that I couldn't include the pfb for copyright reasons. You need the opticals version of MinionPro to get MinionPro-ItDisp.pfb. If you don't have the optical fonts the easiest workaround is to create a PFB with just one glyph named /integral of width 310 units. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-26 08:47 Message: Logged In: YES user_id=710 I still got: pdfTeX warning: pdftex (file MinionPro-ItDisp.pfb): cannot open Type 1 font file for reading I checked out the cvs version of MinionPro and run the makeall script as described in README-src, but still I didn't see MinionPro-ItDisp.pfb. ---------------------------------------------------------------------- Comment By: Achim Blumensath (blume) Date: 2007-01-26 07:21 Message: Logged In: YES user_id=4173 I've simplified the test case to plain TeX. The requested files are attached. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-01-25 15:01 Message: Logged In: YES user_id=421 Note that the -recorder cmdline switch also works quite well with kpathsea. :-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-25 09:43 Message: Logged In: YES user_id=710 I tested the file again with the fonts you uploaded, but still I cannot reproduce the problem. I attached a small script that creates a list of all files opened by tex. Usage: unpack, put list-tex-files.vim under ~/vim and run: sh list-tex-files pdflatex testfile it will report the filename of the list, which can be used then to pack everything needed to rerun the job. You may want to review the list to remove a few files that are not relevant, for example the format. ---------------------------------------------------------------------- Comment By: Achim Blumensath (blume) Date: 2007-01-25 07:54 Message: Logged In: YES user_id=4173 In order to preproduce the bug you need the CVS version on MinionPro and perhaps also a recent version of the lcdf-typetools. The problem seems to be that the font MnSymbolFI10.vf refers again to a virtual font MinionPro-It-integral.vf. I've attached the corresponding VPL files. (I didn't have the time to create the requested PDF files. Will do so shortly.) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-24 19:52 Message: Logged In: YES user_id=710 I compiled the test file and got normal output (see attached screenshot). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-01-24 15:56 Message: Logged In: YES user_id=421 Please attach the PDFs generated by ps2pdf and pdflatex, best generated with \pdfcompresslevel=0. And the log from pdflatex. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=722&group_id=106

1 0

[ pdftex-Bugs-721 ] Missing /Font object of PK file not found
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #721, was opened at 2007-01-23 21:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=721&group_id=106 Category: Fonts Group: v1.40.1 >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Missing /Font object of PK file not found Initial Comment: There are several cases, the buggy one is no. 3. See test files test1...4.tex in the attached file. 1. No TFM file found in the 1st place. ---> No TeX font will be started. Ok. See test1.tex. 2. TFM file found, map entry existing, but no PFB font file in map line ---> "pdfTeX warning: pdftex: font `CMR' is not a standard font; I suppose it is available to your PDF viewer then". Ok. See test2.tex. 3. TFM file found, no map entry, and no PK font available. ---> "pdfTeX warning: pdftex (file mf-nonexist): Font mf-nonexist at 600 not found". Not ok. See test3.tex. Here a /Font object is referenced, which is not existing, rendering the resulting PDF file buggy. There should be either pdftex_fail() or or at least a /Font object with a dummy /FontDescriptor object should be created (the latter filled with defaults from the TFM file), and the same warning should be given as in case 4 below, since these cases are similar: fontfile expected, but not available. 4. TFM file found, map entry with PFB font file existing, but no PFB font file found. ---> "pdfTeX warning: pdftex (file t1-nonexist.pfb): cannot open Type 1 font file for reading". /FontDescriptor without /FontFile, correct. Ok. See test4.tex. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-24 22:40 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 12:48 Message: Logged In: YES user_id=710 patch updated, a typo was in the previous one. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 09:58 Message: Logged In: YES user_id=710 Here is a patch to turn some warnings that can lead to invalid pdf output to fatal errors. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=721&group_id=106

1 0

[ pdftex-Bugs-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #747, was opened at 2007-03-09 03:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 00:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 09:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 11:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 20:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 17:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Patches item #812, was opened at 2007-06-23 17:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: Primitives Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 08:41 Message: Logged In: YES user_id=710 sounds good to me. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-24 08:28 Message: Logged In: YES user_id=1608 I see an advantage in having a configurable parameter over the arbitrary constant that \prevdepth currently uses. But if that is the case, it makes sense to apply it to \prevdepth as well. So how about \pdfignoreddimen instead, that defaults to -1000pt, and is also used by \prevdepth ? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 08:26 Message: Logged In: YES user_id=710 another patch uploaded, so the pdftex team can choose between them. Hope to make Nobody (None) happy. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 17:29 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Patches item #812, was opened at 2007-06-23 19:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: Primitives Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-06-24 10:28 Message: Logged In: YES user_id=1608 I see an advantage in having a configurable parameter over the arbitrary constant that \prevdepth currently uses. But if that is the case, it makes sense to apply it to \prevdepth as well. So how about \pdfignoreddimen instead, that defaults to -1000pt, and is also used by \prevdepth ? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:26 Message: Logged In: YES user_id=710 another patch uploaded, so the pdftex team can choose between them. Hope to make Nobody (None) happy. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 19:29 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Patches item #812, was opened at 2007-06-23 17:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: Primitives Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 08:26 Message: Logged In: YES user_id=710 another patch uploaded, so the pdftex team can choose between them. Hope to make Nobody (None) happy. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 17:29 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ pdftex-Patches-811 ] Patch to change warning mesage for conflicting font attributes (given by \pdffontattr)
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Patches item #811, was opened at 2007-06-23 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106 >Category: Fonts Group: v1.50.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: Patch to change warning mesage for conflicting font attributes (given by \pdffontattr) Initial Comment: This is a tiny patch to change the warning message for conflicting font attributes (as given by \pdffontattr), to make it clearer what is going on. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106

1 0

[ pdftex-Patches-813 ] new primitive \pdfinclusioncopyfonts
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Patches item #813, was opened at 2007-06-23 19:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106 >Category: Fonts >Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) >Assigned to: Hartmut Henkel (hhenkel) Summary: new primitive \pdfinclusioncopyfonts Initial Comment: this is a replacement for \pdfreplacefont, with the opposite semantics. When this is set, fonts from included pdfs are always copied. This is useful to prevent pdftex from replacing fonts in included pdfs, without messing around with map files. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106

1 0