- ntg-pdftex - NTG Mailing Lists

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

09 Mar '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: None 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-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-Bugs-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 09 Mar '07

09 Mar '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: None 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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0

[ pdftex-Patches-746 ] Patch PromptFileName
by noreply＠sarovar.org 07 Mar '07

07 Mar '07

Patches item #746, was opened at 2007-03-07 17:41 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=746&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Patch PromptFileName Initial Comment: Subject: Patch PromptFileName Date: 2007/03/07 Author: Heiko Oberdiek The patches are based on pdfTeX 1.40.3 There is some discussion in the tex-live list: List: tex-live(a)tug.org Date: March 2007 Subject: Bug in TexLive 2005 and 2007? Non-writable aux-file If TeX asks for a file name, what action should be taken, if the user doesn't provide a file name? The current behaviour has changed from Web2C 7.5.2 to 7.5.6 and is quite impredictible: * Append some default extension if file extension is not given. * Use previous file name part, if this part is empty. Sometimes this behaves as "retry action" by chance, sometimes a source file gets overwritten. Two patches are provided that implement alternative actions: * Retry.diff If the user doesn't specify a file name, then the whole previous file name is used including the area and extension parts. * Abort.diff If the user doesn't specify a file name, then the job is aborted. Unhappily Ctrl-C (or Ctrl-D) have only a retarded effect after the file name is used again (and eventually causing harm). This is a clean way to end the job even if there isn't a valid file name to provide. Both files patches web2c/texk/tex.ch. Of course they cannot be used at the same time. And both patches also show the default name extension, when the user is prompted for a file name. Have fun, Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=746&group_id=106

1 0

[ pdftex-Feature Requests-743 ] Fake beginning/end of line for protrusion
by noreply＠sarovar.org 07 Mar '07

07 Mar '07

Feature Requests item #743, was opened at 2007-03-06 02:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106 Category: HZ Group: v1.50 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Fake beginning/end of line for protrusion Initial Comment: Although the situation with missing protrusion has certainly improved, there are still a lot of cases where characters will not be protruded (e.g. with indented paragraphs, at the beginning of list items, or of table cells). So I think it would be useful to have some commands that make pdftex believe that it is at the beginning or end of a line (e.g. \protchar{left,right}). So that you could for instance say: \item\protcharleft ``... Difficult? ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-03-07 09:52 Message: Logged In: YES user_id=710 yes inserting a whatsit node that would be changed to a kern seems the easiest way. I will give a try soon. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-03-06 17:21 Message: Logged In: YES user_id=2217 Maybe new (whatsit) nodes that can be caught in find_protchar_left/right? microtype is quite good in translating characters into slots (\MT@get@slot), but not really good enough to always allow natural input, e.g., ligatures and things like "` (German babel) won't be recognised. So my current workaround is: \def\protcharleft#1{% {\everypar{}% \setbox0\vbox{\noindent#1}% \vbadness=10000 \splittopskip=0pt \global\setbox0=\vsplit0 to \baselineskip \unvbox0 \global\setbox0=\lastbox}% \ifhbox0 \leavevmode \kern\leftmarginkern0 \fi #1} But this doesn't always work, e.g. in tabulars. Ligatures and other stuff still have to be enclosed in braces. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-03-06 08:00 Message: Logged In: YES user_id=1608 I will be experimenting with Aleph's \localleftbox somewhere next month, that may be a starting point. But it is unlikely that any command based on that will be able to influence line breaking. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-06 07:52 Message: Logged In: YES user_id=710 yes it makes sense. I am not sure whether \protcharleft could be implemented as macro: one can fetch the next char, get the lpcode and do a corresponding kern. However I don't know how to convert a character to its charcode to fetch the relevant lpcode. Another problem is that if the next char is part of a ligature (as in your example), it doesn't work. Looks like a primitive is needed. Does anyone have a suggestion how it could be implemented? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106

1 0

[ pdftex-Feature Requests-743 ] Fake beginning/end of line for protrusion
by noreply＠sarovar.org 06 Mar '07

06 Mar '07

Feature Requests item #743, was opened at 2007-03-06 02:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106 Category: HZ Group: v1.50 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Fake beginning/end of line for protrusion Initial Comment: Although the situation with missing protrusion has certainly improved, there are still a lot of cases where characters will not be protruded (e.g. with indented paragraphs, at the beginning of list items, or of table cells). So I think it would be useful to have some commands that make pdftex believe that it is at the beginning or end of a line (e.g. \protchar{left,right}). So that you could for instance say: \item\protcharleft ``... Difficult? ---------------------------------------------------------------------- >Comment By: Robert (schlcht) Date: 2007-03-06 17:21 Message: Logged In: YES user_id=2217 Maybe new (whatsit) nodes that can be caught in find_protchar_left/right? microtype is quite good in translating characters into slots (\MT@get@slot), but not really good enough to always allow natural input, e.g., ligatures and things like "` (German babel) won't be recognised. So my current workaround is: \def\protcharleft#1{% {\everypar{}% \setbox0\vbox{\noindent#1}% \vbadness=10000 \splittopskip=0pt \global\setbox0=\vsplit0 to \baselineskip \unvbox0 \global\setbox0=\lastbox}% \ifhbox0 \leavevmode \kern\leftmarginkern0 \fi #1} But this doesn't always work, e.g. in tabulars. Ligatures and other stuff still have to be enclosed in braces. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-03-06 08:00 Message: Logged In: YES user_id=1608 I will be experimenting with Aleph's \localleftbox somewhere next month, that may be a starting point. But it is unlikely that any command based on that will be able to influence line breaking. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-06 07:52 Message: Logged In: YES user_id=710 yes it makes sense. I am not sure whether \protcharleft could be implemented as macro: one can fetch the next char, get the lpcode and do a corresponding kern. However I don't know how to convert a character to its charcode to fetch the relevant lpcode. Another problem is that if the next char is part of a ligature (as in your example), it doesn't work. Looks like a primitive is needed. Does anyone have a suggestion how it could be implemented? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106

1 0

[ pdftex-Feature Requests-743 ] Fake beginning/end of line for protrusion
by noreply＠sarovar.org 06 Mar '07

06 Mar '07

Feature Requests item #743, was opened at 2007-03-06 03:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106 >Category: HZ >Group: v1.50 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) >Assigned to: The Thanh Han (hanthethanh) Summary: Fake beginning/end of line for protrusion Initial Comment: Although the situation with missing protrusion has certainly improved, there are still a lot of cases where characters will not be protruded (e.g. with indented paragraphs, at the beginning of list items, or of table cells). So I think it would be useful to have some commands that make pdftex believe that it is at the beginning or end of a line (e.g. \protchar{left,right}). So that you could for instance say: \item\protcharleft ``... Difficult? ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-03-06 09:00 Message: Logged In: YES user_id=1608 I will be experimenting with Aleph's \localleftbox somewhere next month, that may be a starting point. But it is unlikely that any command based on that will be able to influence line breaking. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-06 08:52 Message: Logged In: YES user_id=710 yes it makes sense. I am not sure whether \protcharleft could be implemented as macro: one can fetch the next char, get the lpcode and do a corresponding kern. However I don't know how to convert a character to its charcode to fetch the relevant lpcode. Another problem is that if the next char is part of a ligature (as in your example), it doesn't work. Looks like a primitive is needed. Does anyone have a suggestion how it could be implemented? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106

1 0

[ pdftex-Feature Requests-743 ] Fake beginning/end of line for protrusion
by noreply＠sarovar.org 06 Mar '07

06 Mar '07

Feature Requests item #743, was opened at 2007-03-06 03:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: Fake beginning/end of line for protrusion Initial Comment: Although the situation with missing protrusion has certainly improved, there are still a lot of cases where characters will not be protruded (e.g. with indented paragraphs, at the beginning of list items, or of table cells). So I think it would be useful to have some commands that make pdftex believe that it is at the beginning or end of a line (e.g. \protchar{left,right}). So that you could for instance say: \item\protcharleft ``... Difficult? ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-03-06 09:00 Message: Logged In: YES user_id=1608 I will be experimenting with Aleph's \localleftbox somewhere next month, that may be a starting point. But it is unlikely that any command based on that will be able to influence line breaking. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-06 08:52 Message: Logged In: YES user_id=710 yes it makes sense. I am not sure whether \protcharleft could be implemented as macro: one can fetch the next char, get the lpcode and do a corresponding kern. However I don't know how to convert a character to its charcode to fetch the relevant lpcode. Another problem is that if the next char is part of a ligature (as in your example), it doesn't work. Looks like a primitive is needed. Does anyone have a suggestion how it could be implemented? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106

1 0

[ pdftex-Feature Requests-743 ] Fake beginning/end of line for protrusion
by noreply＠sarovar.org 06 Mar '07

06 Mar '07

Feature Requests item #743, was opened at 2007-03-06 02:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: Fake beginning/end of line for protrusion Initial Comment: Although the situation with missing protrusion has certainly improved, there are still a lot of cases where characters will not be protruded (e.g. with indented paragraphs, at the beginning of list items, or of table cells). So I think it would be useful to have some commands that make pdftex believe that it is at the beginning or end of a line (e.g. \protchar{left,right}). So that you could for instance say: \item\protcharleft ``... Difficult? ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-03-06 07:52 Message: Logged In: YES user_id=710 yes it makes sense. I am not sure whether \protcharleft could be implemented as macro: one can fetch the next char, get the lpcode and do a corresponding kern. However I don't know how to convert a character to its charcode to fetch the relevant lpcode. Another problem is that if the next char is part of a ligature (as in your example), it doesn't work. Looks like a primitive is needed. Does anyone have a suggestion how it could be implemented? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106

1 0

[ pdftex-Feature Requests-743 ] Fake beginning/end of line for protrusion
by noreply＠sarovar.org 06 Mar '07

06 Mar '07

Feature Requests item #743, was opened at 2007-03-06 02:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: Fake beginning/end of line for protrusion Initial Comment: Although the situation with missing protrusion has certainly improved, there are still a lot of cases where characters will not be protruded (e.g. with indented paragraphs, at the beginning of list items, or of table cells). So I think it would be useful to have some commands that make pdftex believe that it is at the beginning or end of a line (e.g. \protchar{left,right}). So that you could for instance say: \item\protcharleft ``... Difficult? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106

1 0

[ pdftex-Patches-735 ] patch for simplified horizontal positional tracking
by noreply＠sarovar.org 04 Mar '07

04 Mar '07

Patches item #735, was opened at 2007-02-19 22:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=735&group_id=106 Category: Positioning Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: patch for simplified horizontal positional tracking Initial Comment: 1. simpler calculations for horizontal position update when inside []TJ arrays, now by pure additions within a fontsize/10000 raster; no rounding errors can accumulate. Gives about 7 % pdftex speed gain when typesetting fiction-type stuff. 2. writet3.c now also with standard /FontMatrix [0.001 0 0 0.001 0 0], tidied up a little (.pgc part untested). No need anymore (hope it's right) to handle PK fonts specially by adv_char_width() in pdftex.web. 3. wrong use of printf() at a few places corrected by Martin. Work in progess, not safe for production. Needs more testing, particularly with PK fonts. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2007-03-04 11:27 Message: Logged In: YES user_id=929 the extended patch 70226a needs more work; removed the patch file. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-02-25 23:51 Message: Logged In: YES user_id=929 The previous patch 735 is now extended to general text and graphics positioning on the PDF page. pdf_set_origin() (now pdf_move_to()), pdf_set_textmatrix(), and pdf_begin_string() are rewritten. In low placement resolution (e. g. \pdfdecimaldigits=0) now the glyph placement is corrected within the []TJ array by a leading number, like [7(a)...]TJ, if required, so that always full TeX precision is kept (very early pdftex versions might have used this also). Any accumulation of rounding errors should be avoided now by the used calculation principle. Needs lots of testing. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=735&group_id=106

1 0

[ pdftex-Bugs-742 ] writepng doesn't xfree rows
by noreply＠sarovar.org 03 Mar '07

03 Mar '07

Bugs item #742, was opened at 2007-03-03 22:41 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=742&group_id=106 Category: Image inclusion Group: v1.40.0 >Status: Deleted Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Martin Schröder (oneiros) Summary: writepng doesn't xfree rows Initial Comment: after PNG image inclusion the allocated image rows are still kept in memory, wasting space. The patch file contains the missing xfree() calls. ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2007-03-04 00:28 Message: Logged In: YES user_id=929 sorry this was an oversight. No bug. Everything ok, the xfree(rows[i]) is already in macro write_interlaced(outmac). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=742&group_id=106

1 0

[ pdftex-Bugs-742 ] writepng doesn't xfree rows
by noreply＠sarovar.org 03 Mar '07

03 Mar '07

Bugs item #742, was opened at 2007-03-03 22:41 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=742&group_id=106 Category: Image inclusion Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Martin Schröder (oneiros) Summary: writepng doesn't xfree rows Initial Comment: after PNG image inclusion the allocated image rows are still kept in memory, wasting space. The patch file contains the missing xfree() calls. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=742&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 03 Mar '07

03 Mar '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-03 19:41 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-03 15:48 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 03 Mar '07

03 Mar '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Postponed Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Uwe Stöhr (stoehr) Date: 2007-03-03 19:41 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-03 15:48 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 03 Mar '07

03 Mar '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Postponed Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-03-03 15:48 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 02 Mar '07

02 Mar '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open >Resolution: Postponed Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) >Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images
by noreply＠sarovar.org 02 Mar '07

02 Mar '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images
by noreply＠sarovar.org 02 Mar '07

02 Mar '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images
by noreply＠sarovar.org 02 Mar '07

02 Mar '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 >Category: PDF inclusion >Group: v1.30.0 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Uwe Stöhr (stoehr) >Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images
by noreply＠sarovar.org 01 Mar '07

01 Mar '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Nobody (None) >Summary: wrong colors for included PDF-images Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-image
by noreply＠sarovar.org 01 Mar '07

01 Mar '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Nobody (None) Summary: wrong colors for included PDF-image Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-712 ] problems with \letterspacefont
by noreply＠sarovar.org 01 Mar '07

01 Mar '07

Bugs item #712, was opened at 2006-12-12 02: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: The Thanh Han (hanthethanh) Date: 2007-03-01 21:07 Message: Logged In: YES user_id=710 here is a patch that makes disabling ligature optional -- a keyword "nolig" would do that: \letterspacefont\y=\x 100 nolig ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-22 09:31 Message: Logged In: YES user_id=710 yes it sounds reasonable. Or we can extend the syntax of \letterspacefont so that if an optional keyword like 'nolig' is found then ligatures will be disabled. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-02-22 02:54 Message: Logged In: YES user_id=2217 The current situation with regards to the lack of kerning of letterspaced fonts is not really satisfying. After some consideration, I therefore think it is actually better *not* to disable ligatures, and hence kerning, for letterspaced fonts. So I would propose to remove the line: set_no_ligatures(k); {disable ligatures for letter-spaced fonts} It is easy enough for the high-level interfaces (microtype, context) to (automatically) disable selected ligatures only, so that kerning for the rest of the characters is still available. What do you think? \letterspacefont\lsfont\font 100 \lsfont \tagcode\lsfont`f -1 VALID off -- \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-02 13:54 Message: Logged In: YES user_id=710 the warning message can be removed. I left it there since I don't know what happens if a virtual font is loaded, used and then expanded and used again with font expansion. It should be alright to do so, but I am not very sure. Anyway, I will change the warning to be issued for non-virtual fonts only. It turned to be a design mistake that the \pdffontexpand primitive takes a base font and turns it to an expanded font. It would be better it was more like \letterspacefont, ie it should create a new font and leave the original font intact. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-02-02 07:30 Message: Logged In: YES user_id=1608 > I hope luatex will abolish with this nonsensical connexion of ligatures and kerns? Yes. ligatures and kerns are totally separate in luatex. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-02-01 19:02 Message: Logged In: YES user_id=2217 If the warning is misleading, should it not be removed? On a different matter: Since \letterspacefont issues set_no_ligatures, there won't be any kerning, either. There's no way around that, I guess? (I hope luatex will abolish with this nonsensical connexion of ligatures and kerns?) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-04 15:59 Message: Logged In: YES user_id=710 The warning is misleading but harmless. The reason of the warning is that pdftex checks whether a font has not been used before expansion (its type has not been examined and is new/unknown yet). \letterspacefont sets the type of \y as a virtual font, thus pdftex thinks the font might have been used before. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-01-04 00:40 Message: Logged In: YES user_id=2217 I'm a bit confused about the status of (3): letterspacing and expansion: When expanding a letterspaced font, pdftex issues the warning: ``font should be expanded before its first use'', but apart from that, I cannot see any problems -- the font is both letterspaced and expanded. Or is there a reason for the warning? \pdfadjustspacing2 \font\x=cmr10 \x \letterspacefont\y=\x 100 \y \pdffontexpand\y 20 20 5 autoexpand ... \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 16: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 17: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 15: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 13: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-721 ] Missing /Font object of PK file not found
by noreply＠sarovar.org 01 Mar '07

01 Mar '07

Bugs item #721, was opened at 2007-01-23 20: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: Open 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: The Thanh Han (hanthethanh) Date: 2007-03-01 11: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 08: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-721 ] Missing /Font object of PK file not found
by noreply＠sarovar.org 01 Mar '07

01 Mar '07

Bugs item #721, was opened at 2007-01-23 20: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: Open 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: The Thanh Han (hanthethanh) Date: 2007-03-01 08: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-736 ] font expansion leads to wrong log output of \kerns.
by noreply＠sarovar.org 28 Feb '07

28 Feb '07

Bugs item #736, was opened at 2007-02-22 02: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: Open Resolution: Accepted 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: The Thanh Han (hanthethanh) Date: 2007-02-28 14: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 10: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