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 11:26
Message: Logged In: YES user_id=2683 My fault. I thought these objects could be sent _to_ the graphics package. Thanks for taking your time! ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-08-02 11:19 Message: Logged In: YES user_id=1608 The xform has precisely the same dimensions that the TeX box has. For graphics, the macro package normally *does* know what is in the box (from the image's dimensions); and it also knows which portion of the included graphic/box it needs to display (from the user input). Then it essentially shrinks (instead of expands, as in your case) the box from it's 'natural' dimensions to the desired clip size. And that is why adding something either automatically or semi-automatically would break existing documents: not *enough* of the graphic would be clipped then. I hope this answers your question. ---------------------------------------------------------------------- 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