- ntg-pdftex - NTG Mailing Lists

reserveobjnum
by Hans Hagen 15 Aug '05

15 Aug '05

! pdfTeX error (ext1): invalid object number. <argument> \immediate \pdfobj useobjnum 1 stream {... can this become a warning and not an error? in a multipass job (with obj cross refs) such a number may temporarily be wrong/clash, but will be resolved in next passes Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

4 5

redundant resources
by Hans Hagen 15 Aug '05

15 Aug '05

Hi, There are situations where unused resources can end up in a pdf file; think for instance of a font system that sets up tounicode vector inclusion. For practical purposes, one needs to have a font loaded before the document preamble is scanned. If not, it is impossible to deal with certain dimensions. So, it that case, we have something \pdffontattr\font{/ToUnicode ... 0 R} But imagine that we never use that font. If the rest of the document fonts use the same vector, this is no problem, but when we switch to another font encoding, we end up with a non used to unicode vector. Or think of docs with only graphics (or other pdf pages) where no such vector is needed. Because the object reference ... 0 R is not seen, pdftex cannot decide either or not to include the object, so we need to use \immediate\obj which result sin the non wanted entry. A solution is \pdffontvector <obj num> but a more generic solution is \pdffontattr\font{/ToUnicode ... \refobjnum <objnum>} which will tag the object (number) as being used but only when the font desciption object is really flushed (so \refobjnum fullfils a signal function) this means that a (later) \pdfobj{...} will not be flushed when it is not really refered Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

1 0

url links in included pdf documents,
by Janko Hauser 10 Aug '05

10 Aug '05

Hello, I have the need to include pdf pages as backgrounds into a latex document. I would like to keep the url-links in these background pdf's. Searching the mailinglists it turns out, that pdftex does strip all links from included pdf's. Has this changed in recent versions? How should one proceed to look for this in the code of pdftex? With regards, __Janko Hauser

1 0

compilation under mingw
by Pawel Jackowski 04 Aug '05

04 Aug '05

Hi there, pdfTeX sources (at least current 1.30.0 and rcandidates) don't compile under mingw environment, although #ifdefs suggest that mingw is supported. src/texk/kpathsea/config.h:85:22 win32lib.h: No such file or directory src/texk/kpathsea/c-ctype.h:26:22 oldnames.h: No such file or directory Has anybody tried? Thanks for any clues. -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

3 3

Re: [pdftex] pdftex 1.30.0
by Taco Hoekwater 03 Aug '05

03 Aug '05

Congrats to Martin! For Hans and other interested people, I've put up compiled binaries for i32 and amd64: http://tex.aanhet.net/temp/pdftex-1.30.0-linux-i32.tar.gz http://tex.aanhet.net/temp/pdftex-1.30.0-linux-amd64.tar.gz as well as a tar.bz2 version of the zip http://tex.aanhet.net/temp/pdftex-1.30.0-tar.bz2 Greetings, Taco Martin Schröder wrote: > [http://sarovar.org/download.php/673/pdftex-1.30.0.zip] > > The pdfTeX team is happy to announce the release of a new stable version: > > =========================================================================== > pdfTeX 1.30.0 > ===========================================================================

3 4

[ pdftex-Bugs-378 ] xputenv.c:79: failed assertion `old_item' / pdfeTeX, Version 3.141592-1.30.0-rc2-2.2 (Web2C 7.5.5)
by noreply＠sarovar.org 03 Aug '05

03 Aug '05

Bugs item #378, was opened at 2005-07-05 17:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=378&group_id=106 Category: web2c Group: v1.21a >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peter Dyballa (ballapete) Assigned to: Olaf Weber (infovore) Summary: xputenv.c:79: failed assertion `old_item' / pdfeTeX, Version 3.141592-1.30.0-rc2-2.2 (Web2C 7.5.5) Initial Comment: That's the document: \documentclass[12pt]{article} \usepackage{cmbright} %\usepackage{eurofont} \usepackage[T1]{fontenc} %\usepackage{lmodern} \usepackage[?]{amsmath} \begin{document} This is a test document for testing purposes in cmbright. It's worth maybe 0,02\,\texteuro. \section{Introcution} Let us do some math! % \[ \forall x \in \mathbf{R}, x^2 \geq 0 \] % NOT ok \[ x , 0 \]%\in \mathbf{R} x^2 \geq % OK % \begin{equation} % \forall x \in \mathbf{R}, x^2 \geq 0 % NOT ok % \end{equation} % \begin{equation} % x = r^2 + \sum_{0}^{100} y^2 % NOT ok % \end{equation} \begin{equation} % {\partial\over\partial x} f(x,y) = {\partial\over\partial y} f(x,y) = 0 % OK! \frac{\partial}{\partial x} f(x,y) = \frac{\partial}{\partial y} f(x,y) = 0 % OK! \end{equation} \end{document} Failure message: .... (./cmbright.aux) (/usr/local/teTeX/share/texmf.tetex/tex/latex/ base/ts1cmr.fd) (/usr/local/teTeX/share/texmf.tetex/tex/latex/cmbright/ts1cmbr.fd) (/usr/local/teTeX/share/texmf.tetex/tex/latex/cmbright/ omlcmbrm.fd) (/usr/local/teTeX/share/texmf.tetex/tex/latex/cmbright/ omscmbrs.fd) [1{/usr/local/teTeX/share/texmf.local/fonts/map/pdftex/updmap/ pdftex.map}] (./cmbright.aux) ) </var/tmp/texfonts/pk/ljfour/public/cmbright/ cmbr10.720pk>xputenv.c:79: failed assertion `old_item' Abort No PS Type 1 fonts, only MF based. ---------------------------------------------------------------------- >Comment By: Olaf Weber (infovore) Date: 2005-08-03 00:13 Message: Logged In: YES user_id=1847 The new xputenv.c has been verified to fix the problem. It has been checked into the main web2c sources and will merge into TeX-live and teTeX from there. ---------------------------------------------------------------------- Comment By: Olaf Weber (infovore) Date: 2005-07-10 11:41 Message: Logged In: YES user_id=1847 Reopening and assigning to myself, updating title and group to clarify problem. Likely this is a problem with the xputenv implementation in the web2c sources. Attached is a new xputenv.c which should not suffer from the same problem. It also doesn't require the SMART_PUTENV autoconf check (was originally written specifically to be able to get rid of this check). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-07 23:53 Message: Logged In: YES user_id=421 This seems to be an implementation problem on certain versions of OSX. ---------------------------------------------------------------------- Comment By: Peter Dyballa (ballapete) Date: 2005-07-06 09:46 Message: Logged In: YES user_id=2303 Sorry, that's my fault with commented out %\usepackage{eurofont}! The error becomes obvious with this file and the first two lines of math. The version below runs fine, but if you add any of the commented out math entities it breaks: \documentclass[12pt]{article} \usepackage{cmbright} \usepackage[T1]{fontenc} %\usepackage{lmodern} \usepackage[?]{amsmath} \begin{document} \section{Introcution} Let us do some math! % \[ x , 0 \mathbf{R} \]%\in x^2 \geq % NOT ok \[ x , 0 \]% \forall \in \mathbf{R} x^2 \geq % OK \begin{equation} \frac{\partial}{\partial x} f(x,y) = \frac{\partial}{\partial y} f(x,y) = 0 % OK! \end{equation} \end{document} I have too a case with archaic PK fonts and I've seen an answer to my ConTeXt question so that a third case might be coming ... ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-07-06 08:21 Message: Logged In: YES user_id=929 I also can't reproduce the bug; have sent Pete an xputenv.c with a few diagnostic printf's, which he has forwarded to Gerben (who will soon be in holidays...). Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-06 03:08 Message: Logged In: YES user_id=421 Argl. The comment got lost. :-( Your example is without eurofont, yet your log shows that you use eurofont. Without eurofont the example works perfectly for me with 1.21a and 1.30.0-rc2 ... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=378&group_id=106

1 0

Re: [NTG-pdftex] compilation under mingw
by Thanh Han The 02 Aug '05

02 Aug '05

I spent a lot of time to compile pdftex with mingw in the past, but in the end I think that it's not worthwhile for the trouble so I gave it up. Using the djgpp cross-compiler is much easier ad allows me to use the same sources for compiling binaries for linux and dos/windows. Thanh On Tue, Aug 02, 2005 at 01:54:37PM +0200, Pawel Jackowski wrote: > Hi there, > > pdfTeX sources (at least current 1.30.0 and rcandidates) don't compile > under mingw environment, although #ifdefs suggest that mingw is supported. > > src/texk/kpathsea/config.h:85:22 win32lib.h: No such file or directory > src/texk/kpathsea/c-ctype.h:26:22 oldnames.h: No such file or directory > > Has anybody tried? Thanks for any clues. > -- > Pawe/l Jackowski > P.Jackowski(a)gust.org.pl > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex

2 1

[ 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 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

1 0

[ 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 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-02 13: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 11: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 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

Re: pdftex 1.30.0
by Thanh Han The 02 Aug '05

02 Aug '05

Many thanks to Martin! Thanh > Martin Schr�der wrote: > >[http://sarovar.org/download.php/673/pdftex-1.30.0.zip] > > > >The pdfTeX team is happy to announce the release of a new stable version: > > > >=========================================================================== > > pdfTeX 1.30.0 > >=========================================================================== > > [...]

1 0