- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-396 ] The bbox of Form XObjects is too small
by noreply＠sarovar.org 02 Aug '05

02 Aug '05

Bugs item #396, was opened at 2005-08-01 17:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106 Category: Fonts Group: v1.10b Status: Closed Resolution: Wont Fix Priority: 3 Submitted By: Henrik Tidefelt (tidde) Assigned to: Taco Hoekwater (taco) Summary: The bbox of Form XObjects is too small Initial Comment: Run the following source trough pdflatex, and look carefully at the top and bottom of the output characters. They are chopped off by just a little, and that is due to the bbox of the Form XObject being too small. The problem is not growing with the height of the box (putting "\parbox {1cm}{S\S\S\y}" in the box instead of "Sy"), so it shouldn't be a pt/bp confusion thing. <<<---------------------------- \documentclass{article} \newcommand{\smallbox}[1]{% \setbox0 = \hbox{#1}% \pdfxform attr { } resources{ } 0 \shipout\hbox{\pdfrefxform\pdflastxform} } \begin{document} \smallbox{Sy} \end{document} --------------------------->>> ---------------------------------------------------------------------- >Comment By: Henrik Tidefelt (tidde) Date: 2005-08-02 09:00 Message: Logged In: YES user_id=2683 I understand that there may be reasons why this basic mechanism can't be changed, especially as I hear that this box is used for by other parts of the system. I didn't expect that, and couldn't see the reason why the box would have to be so tight. Still, if this box is used for clipping in graphics (as it is in pdf itself), howcome is this not a problem for the graphics package and and ConTeXt? If neither they know what's in the boxes, do they too have to grow it by an ad hoc amount? Aren't we all in the same boat? (Perhaps with the exception of pdfTeX itself because the Form XObject feature is considered low-level, and anyone-who-uses-it-needs-to-know-what-they're-doing?) (Note that I have given up hope for a fix in pdfTeX. I am just curious about this matter anyway.) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-08-01 20:17 Message: Logged In: YES user_id=1608 This behaviour of pdftex's xform is actively used by the clipping mechanisms in LaTeX's graphics package as well as in ConTeXt, so changing the default behaviour it is really not an option, sorry. Besides, pdftex does not truly know what is in the box, it relies on the font metric information, and that is a little too tight in this case, just like it could easily be too wide in other cases. Adding a new (set of?) standalone configuration parameter(s) for user-driven control of each separate pdfxform is little better than the existing trick of adjusting the box size, so I am closing the bug report with "wont fix". Thank you for the report, though ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2005-08-01 19:53 Message: Logged In: YES user_id=927 There is nothing wrong with xforms and changing xform behavior is quite dangerous after all these years. A non-tight boundingbox of chars is rather normal. A tex font has a limited number of heights and depths for a character so sometimes it's due to that limitation. Also, font designers may wish to lie about te boundingbox (for proper alignment purposes and such); its' rather normal to let curver lines stick out the bbox). Also side bearings play a role. So .. i'm not that sure if we're dealing with a bug here. More a side effect. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-08-01 18:56 Message: Logged In: YES user_id=421 This is not a pdfTeX problem, but a font problem. Look at the output of this code: -------------------------- \pdfcompresslevel=0 \pagestyle{empty} \documentclass[a5paper]{article} \setlength{\fboxsep}{0pt} \setlength{\fboxrule}{0.01pt} \newcommand{\smallbox}[1]{% \fbox{#1}% \setbox0 = \hbox{#1}% \pdfxform 0 \pdfrefxform\pdflastxform } \begin{document} \Huge \smallbox{Sy} \end{document} -------------------------- You'll notice that the fbox has the same size as the bbox and cuts through the chars the same way. ---------------------------------------------------------------------- Comment By: Henrik Tidefelt (tidde) Date: 2005-08-01 17:52 Message: Logged In: YES user_id=2683 After thinking two more minutes, I recall that the size of the bbox agrees with the size of the TeX object in the box. Perhaps the font lies about the glyph sizes, so that they will be typeset nice and thight? In that case, that must be taken into account when generating Form XObjects. My solution to the problem at the moment is to add a bigpoint in every direction of the bbox. I don't see any harm in adding even more, so I could possibly make sure that the box is always big enough. However, I am afraid that I could run into new problems as this problem gets fixed in pdftex; just adding something mysterious to the bbox size to make it big enough would actually make things worse for my application, as I use the TeX depth information to locate the baseline. Therefore, I'd appreciate if either a documented, fixed, space was used, or that the same amount of space was added below and above (left and right). That way, the TeX origin could still be located. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106

1 0

[ pdftex-Bugs-396 ] The bbox of Form XObjects is too small
by noreply＠sarovar.org 01 Aug '05

01 Aug '05

Bugs item #396, was opened at 2005-08-01 19:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106 Category: Fonts Group: v1.10b >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Henrik Tidefelt (tidde) Assigned to: Taco Hoekwater (taco) Summary: The bbox of Form XObjects is too small Initial Comment: Run the following source trough pdflatex, and look carefully at the top and bottom of the output characters. They are chopped off by just a little, and that is due to the bbox of the Form XObject being too small. The problem is not growing with the height of the box (putting "\parbox {1cm}{S\S\S\y}" in the box instead of "Sy"), so it shouldn't be a pt/bp confusion thing. <<<---------------------------- \documentclass{article} \newcommand{\smallbox}[1]{% \setbox0 = \hbox{#1}% \pdfxform attr { } resources{ } 0 \shipout\hbox{\pdfrefxform\pdflastxform} } \begin{document} \smallbox{Sy} \end{document} --------------------------->>> ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2005-08-01 22:17 Message: Logged In: YES user_id=1608 This behaviour of pdftex's xform is actively used by the clipping mechanisms in LaTeX's graphics package as well as in ConTeXt, so changing the default behaviour it is really not an option, sorry. Besides, pdftex does not truly know what is in the box, it relies on the font metric information, and that is a little too tight in this case, just like it could easily be too wide in other cases. Adding a new (set of?) standalone configuration parameter(s) for user-driven control of each separate pdfxform is little better than the existing trick of adjusting the box size, so I am closing the bug report with "wont fix". Thank you for the report, though ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2005-08-01 21:53 Message: Logged In: YES user_id=927 There is nothing wrong with xforms and changing xform behavior is quite dangerous after all these years. A non-tight boundingbox of chars is rather normal. A tex font has a limited number of heights and depths for a character so sometimes it's due to that limitation. Also, font designers may wish to lie about te boundingbox (for proper alignment purposes and such); its' rather normal to let curver lines stick out the bbox). Also side bearings play a role. So .. i'm not that sure if we're dealing with a bug here. More a side effect. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-08-01 20:56 Message: Logged In: YES user_id=421 This is not a pdfTeX problem, but a font problem. Look at the output of this code: -------------------------- \pdfcompresslevel=0 \pagestyle{empty} \documentclass[a5paper]{article} \setlength{\fboxsep}{0pt} \setlength{\fboxrule}{0.01pt} \newcommand{\smallbox}[1]{% \fbox{#1}% \setbox0 = \hbox{#1}% \pdfxform 0 \pdfrefxform\pdflastxform } \begin{document} \Huge \smallbox{Sy} \end{document} -------------------------- You'll notice that the fbox has the same size as the bbox and cuts through the chars the same way. ---------------------------------------------------------------------- Comment By: Henrik Tidefelt (tidde) Date: 2005-08-01 19:52 Message: Logged In: YES user_id=2683 After thinking two more minutes, I recall that the size of the bbox agrees with the size of the TeX object in the box. Perhaps the font lies about the glyph sizes, so that they will be typeset nice and thight? In that case, that must be taken into account when generating Form XObjects. My solution to the problem at the moment is to add a bigpoint in every direction of the bbox. I don't see any harm in adding even more, so I could possibly make sure that the box is always big enough. However, I am afraid that I could run into new problems as this problem gets fixed in pdftex; just adding something mysterious to the bbox size to make it big enough would actually make things worse for my application, as I use the TeX depth information to locate the baseline. Therefore, I'd appreciate if either a documented, fixed, space was used, or that the same amount of space was added below and above (left and right). That way, the TeX origin could still be located. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106

1 0

[ pdftex-Bugs-396 ] The bbox of Form XObjects is too small
by noreply＠sarovar.org 01 Aug '05

01 Aug '05

Bugs item #396, was opened at 2005-08-01 17:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106 Category: Fonts Group: v1.10b Status: Open Resolution: None Priority: 3 Submitted By: Henrik Tidefelt (tidde) Assigned to: Taco Hoekwater (taco) Summary: The bbox of Form XObjects is too small Initial Comment: Run the following source trough pdflatex, and look carefully at the top and bottom of the output characters. They are chopped off by just a little, and that is due to the bbox of the Form XObject being too small. The problem is not growing with the height of the box (putting "\parbox {1cm}{S\S\S\y}" in the box instead of "Sy"), so it shouldn't be a pt/bp confusion thing. <<<---------------------------- \documentclass{article} \newcommand{\smallbox}[1]{% \setbox0 = \hbox{#1}% \pdfxform attr { } resources{ } 0 \shipout\hbox{\pdfrefxform\pdflastxform} } \begin{document} \smallbox{Sy} \end{document} --------------------------->>> ---------------------------------------------------------------------- >Comment By: Hans Hagen (hagen) Date: 2005-08-01 19:53 Message: Logged In: YES user_id=927 There is nothing wrong with xforms and changing xform behavior is quite dangerous after all these years. A non-tight boundingbox of chars is rather normal. A tex font has a limited number of heights and depths for a character so sometimes it's due to that limitation. Also, font designers may wish to lie about te boundingbox (for proper alignment purposes and such); its' rather normal to let curver lines stick out the bbox). Also side bearings play a role. So .. i'm not that sure if we're dealing with a bug here. More a side effect. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-08-01 18:56 Message: Logged In: YES user_id=421 This is not a pdfTeX problem, but a font problem. Look at the output of this code: -------------------------- \pdfcompresslevel=0 \pagestyle{empty} \documentclass[a5paper]{article} \setlength{\fboxsep}{0pt} \setlength{\fboxrule}{0.01pt} \newcommand{\smallbox}[1]{% \fbox{#1}% \setbox0 = \hbox{#1}% \pdfxform 0 \pdfrefxform\pdflastxform } \begin{document} \Huge \smallbox{Sy} \end{document} -------------------------- You'll notice that the fbox has the same size as the bbox and cuts through the chars the same way. ---------------------------------------------------------------------- Comment By: Henrik Tidefelt (tidde) Date: 2005-08-01 17:52 Message: Logged In: YES user_id=2683 After thinking two more minutes, I recall that the size of the bbox agrees with the size of the TeX object in the box. Perhaps the font lies about the glyph sizes, so that they will be typeset nice and thight? In that case, that must be taken into account when generating Form XObjects. My solution to the problem at the moment is to add a bigpoint in every direction of the bbox. I don't see any harm in adding even more, so I could possibly make sure that the box is always big enough. However, I am afraid that I could run into new problems as this problem gets fixed in pdftex; just adding something mysterious to the bbox size to make it big enough would actually make things worse for my application, as I use the TeX depth information to locate the baseline. Therefore, I'd appreciate if either a documented, fixed, space was used, or that the same amount of space was added below and above (left and right). That way, the TeX origin could still be located. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106

1 0

[ pdftex-Bugs-396 ] The bbox of Form XObjects is too small
by noreply＠sarovar.org 01 Aug '05

01 Aug '05

Bugs item #396, was opened at 2005-08-01 19:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106 >Category: Fonts Group: v1.10b Status: Open Resolution: None >Priority: 3 Submitted By: Henrik Tidefelt (tidde) >Assigned to: Taco Hoekwater (taco) Summary: The bbox of Form XObjects is too small Initial Comment: Run the following source trough pdflatex, and look carefully at the top and bottom of the output characters. They are chopped off by just a little, and that is due to the bbox of the Form XObject being too small. The problem is not growing with the height of the box (putting "\parbox {1cm}{S\S\S\y}" in the box instead of "Sy"), so it shouldn't be a pt/bp confusion thing. <<<---------------------------- \documentclass{article} \newcommand{\smallbox}[1]{% \setbox0 = \hbox{#1}% \pdfxform attr { } resources{ } 0 \shipout\hbox{\pdfrefxform\pdflastxform} } \begin{document} \smallbox{Sy} \end{document} --------------------------->>> ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2005-08-01 20:56 Message: Logged In: YES user_id=421 This is not a pdfTeX problem, but a font problem. Look at the output of this code: -------------------------- \pdfcompresslevel=0 \pagestyle{empty} \documentclass[a5paper]{article} \setlength{\fboxsep}{0pt} \setlength{\fboxrule}{0.01pt} \newcommand{\smallbox}[1]{% \fbox{#1}% \setbox0 = \hbox{#1}% \pdfxform 0 \pdfrefxform\pdflastxform } \begin{document} \Huge \smallbox{Sy} \end{document} -------------------------- You'll notice that the fbox has the same size as the bbox and cuts through the chars the same way. ---------------------------------------------------------------------- Comment By: Henrik Tidefelt (tidde) Date: 2005-08-01 19:52 Message: Logged In: YES user_id=2683 After thinking two more minutes, I recall that the size of the bbox agrees with the size of the TeX object in the box. Perhaps the font lies about the glyph sizes, so that they will be typeset nice and thight? In that case, that must be taken into account when generating Form XObjects. My solution to the problem at the moment is to add a bigpoint in every direction of the bbox. I don't see any harm in adding even more, so I could possibly make sure that the box is always big enough. However, I am afraid that I could run into new problems as this problem gets fixed in pdftex; just adding something mysterious to the bbox size to make it big enough would actually make things worse for my application, as I use the TeX depth information to locate the baseline. Therefore, I'd appreciate if either a documented, fixed, space was used, or that the same amount of space was added below and above (left and right). That way, the TeX origin could still be located. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106

1 0

[ pdftex-Bugs-396 ] The bbox of Form XObjects is too small
by noreply＠sarovar.org 01 Aug '05

01 Aug '05

Bugs item #396, was opened at 2005-08-01 17:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106 Category: None Group: v1.10b Status: Open Resolution: None Priority: 5 Submitted By: Henrik Tidefelt (tidde) Assigned to: Nobody (None) Summary: The bbox of Form XObjects is too small Initial Comment: Run the following source trough pdflatex, and look carefully at the top and bottom of the output characters. They are chopped off by just a little, and that is due to the bbox of the Form XObject being too small. The problem is not growing with the height of the box (putting "\parbox {1cm}{S\S\S\y}" in the box instead of "Sy"), so it shouldn't be a pt/bp confusion thing. <<<---------------------------- \documentclass{article} \newcommand{\smallbox}[1]{% \setbox0 = \hbox{#1}% \pdfxform attr { } resources{ } 0 \shipout\hbox{\pdfrefxform\pdflastxform} } \begin{document} \smallbox{Sy} \end{document} --------------------------->>> ---------------------------------------------------------------------- >Comment By: Henrik Tidefelt (tidde) Date: 2005-08-01 17:52 Message: Logged In: YES user_id=2683 After thinking two more minutes, I recall that the size of the bbox agrees with the size of the TeX object in the box. Perhaps the font lies about the glyph sizes, so that they will be typeset nice and thight? In that case, that must be taken into account when generating Form XObjects. My solution to the problem at the moment is to add a bigpoint in every direction of the bbox. I don't see any harm in adding even more, so I could possibly make sure that the box is always big enough. However, I am afraid that I could run into new problems as this problem gets fixed in pdftex; just adding something mysterious to the bbox size to make it big enough would actually make things worse for my application, as I use the TeX depth information to locate the baseline. Therefore, I'd appreciate if either a documented, fixed, space was used, or that the same amount of space was added below and above (left and right). That way, the TeX origin could still be located. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106

1 0

[ pdftex-Bugs-396 ] The bbox of Form XObjects is too small
by noreply＠sarovar.org 01 Aug '05

01 Aug '05

Bugs item #396, was opened at 2005-08-01 17:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106 Category: None Group: v1.10b Status: Open Resolution: None Priority: 5 Submitted By: Henrik Tidefelt (tidde) Assigned to: Nobody (None) Summary: The bbox of Form XObjects is too small Initial Comment: Run the following source trough pdflatex, and look carefully at the top and bottom of the output characters. They are chopped off by just a little, and that is due to the bbox of the Form XObject being too small. The problem is not growing with the height of the box (putting "\parbox {1cm}{S\S\S\y}" in the box instead of "Sy"), so it shouldn't be a pt/bp confusion thing. <<<---------------------------- \documentclass{article} \newcommand{\smallbox}[1]{% \setbox0 = \hbox{#1}% \pdfxform attr { } resources{ } 0 \shipout\hbox{\pdfrefxform\pdflastxform} } \begin{document} \smallbox{Sy} \end{document} --------------------------->>> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=396&group_id=106

1 0

\tagcode primitive in pdfetex
by Taco Hoekwater 28 Jul '05

28 Jul '05

Hi, I discovered this morning that 'pdfetex' does not understand the \tagcode primitive, but 'pdftex' does (rc5). It turns out the primitive is in pdftexdir/pdftex2.ch, but that file is not included while building pdfetex. Can this be fixed still? Cheers, Taco

2 1

1.30.0-beta-20050615
by Martin Schröder 27 Jul '05

27 Jul '05

src/pdftex-1.30.0-beta-20050615.zip should be on sarovar. Here's the proposed NEWS: ---------------------------------------------------------------- ------------------------------------------------- pdfTeX 3.141592-1.30.0 was released on 2005-06-?? ------------------------------------------------- - Some primites have been renamed; the old names will still work, but are deprecated and give a warning that they are obsolete: \pdfoptionpdfminorversion -> \pdfminorversion \pdfoptionalwaysusepdfpagebox -> \pdfforcepagebox \pdfoptionpdfinclusionerrorlevel -> \pdfinclusionerrorlevel - pdfxtex (introduced with 1.20a) is gone; all extensions are now in pdftex. - pdftex nows two new units: - new Didot (1nd=0.375mm) - new Cicero (1nc=12nd) - New primitive \pdfpkmode, which is a token register that sets the MF mode for pixel font generation. The contents of this register is dumped into the format, so one can (optionally) preset it e.g. in part of pdftexconfig.tex. - New primitives: pdfTeX now has an interface to the precise system time (if available) as an aid in benchmarking TeX macro code. Two new primitives are provided: - \elapsedtime is a read-only integer that (initially) returns the amount of time passed since the start of this run. This amount is given in `scaled seconds': the value 65536 counts as one second. If more time has passed than 32767 seconds, (2^31)-1 will be returned. - \resettime updates the internal timer, such that subsequent calls to \elapsedtime will restart from 0. - New primitive \pdfxformname <object number>, which expands to the number in the corresponding form XObject name. - New primitives \leftmarginkern <box number> and \rightmarginkern <box number> for specifying the margin kern at the left and right side of the horizontal list stored in box <box number>. - Inclusion of pngs has been greatly improved: It now does - alpha channel and transparency (only if %!PDF >=1.4) - 16-bit colour (only if %!PDF >=1.5); this must be enabled by setting \pdfimagehicolor to 1. - gamma correction; this must be enabled by setting \pdfimageapplygamma to 1. The device gamma is taken from \pdfgamma. If no embedded value can be found in the png image, then the value of \pdfimagegamma is used instead. - The effects of font expansion can now be logged: There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log (with fontexpansion) like this ...\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: ...\xivtt (cmtt10(a)14.0pt) t ...\xivtt (cmtt10+20(a)14.0pt) e See also bug 304. - The primitive \pdfmovechar has been removed (bug 294) - Bugfix: empty strings are not supressed anymore (bug 335) - Bugfix: \unhboxing and character protusion didn't work well together (bug 292) - Bugfix: --jobname didn't work if there was no filename at all (bug 302) - Bugfix: Some problem with fonts on solaris (bug 315) - Bugfix: \pdfxform didn't work with box>255 (bug 310) - Bugfix: protruding can lead to "This can't happen(paragraph)." (bug 292) ---------------------------------------------------------------- Thanh: I changed only NEWS, README, pdftex.ch and pdftex.mk (you forgot pdftex2.ch). I didn't include texk/dvipsk as it's not needed for pdftex; we'll have to figure out a way to pass that upstream. Best Martin -- http://www.tm.oneiros.de

8 21

1.30.0-rc5
by Akira Kakuto 26 Jul '05

26 Jul '05

>http://sarovar.org/download.php/667/pdftex-1.30.0-rc5.zip > >A last rc, which should be very final. I think access violation occurs if one uses an primitive which calls makecfilename() in utils.c. If I use the following, it became ok. char *makecfilename(strnumber s) { char *name = makecstring(s); #ifdef WIN32 /* unquote file name */ if (*name == '"') { char *p = name; char *q = name; while (p && *p) { *q = (*p == '"' ? *(++p) : *p); p++, q++; } *q = '\0'; } fprintf(stderr, " %s\n", name); #endif return name; } -- Akira Kakuto

2 1

[ pdftex-Bugs-393 ] Ensure newline before endstream
by noreply＠sarovar.org 25 Jul '05

25 Jul '05

Bugs item #393, was opened at 2005-07-25 16:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=393&group_id=106 Category: None Group: v1.30.0 Status: Open Resolution: None Priority: 2 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: Ensure newline before endstream Initial Comment: As reported by Hans, there is not always a newline before endstream, although the PDF reference recommends it. Any change needs careful testing. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=393&group_id=106

1 0