- 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 02 Aug '05

02 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

[ 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

[ pdftex-Patches-259 ] Expanded png inclusion support
by noreply＠sarovar.org 25 Jul '05

25 Jul '05

Patches item #259, was opened at 2005-01-11 16:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106 Category: Image inclusion Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Taco Hoekwater (taco) Summary: Expanded png inclusion support Initial Comment: The attached zip file contains a change file for all pdftex's (to be applied *after* hz.cg) and a completely new writepng.c ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-07-25 10:56 Message: Logged In: YES user_id=1608 The attached writepng.c fixes a bug discovered by Hans: In the new version, Colorspaces were always written direct (img_colorspace_ref() was ignored). That broke the image color processing that ConTeXt does. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-13 16:57 Message: Logged In: YES user_id=421 This has been included in version 1.30.0 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-14 12:03 Message: Logged In: YES user_id=1608 changes as agreed at Pont-a-Mousson: -\pdfoptionimageforcegray removed -\pdfoptionimageapplygamma is now 0 or 1 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-03 17:00 Message: Logged In: YES user_id=1608 Bugfixes in 16-bit color depth mode (needs an 8-bit alpha channel) and corrected PNG transformation discovery for gray conversion. This is a final version for now, it should be added to a pdftex beta to allow 'in the wild' testing. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-01 13:38 Message: Logged In: YES user_id=1608 This update fixes the \pdfoptionimageforcegray bugs discovered by Hartmut. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 17:27 Message: Logged In: YES user_id=1608 Sorry, I forgot the 16-bit color code in the previous version ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 16:38 Message: Logged In: YES user_id=1608 This new version incorporates the code from Hartmut's speed patch. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106

1 0

[ pdftex-Patches-259 ] Expanded png inclusion support
by noreply＠sarovar.org 25 Jul '05

25 Jul '05

Patches item #259, was opened at 2005-01-11 16:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106 Category: Image inclusion >Group: v1.30.0 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) >Assigned to: Taco Hoekwater (taco) Summary: Expanded png inclusion support Initial Comment: The attached zip file contains a change file for all pdftex's (to be applied *after* hz.cg) and a completely new writepng.c ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-07-25 10:56 Message: Logged In: YES user_id=1608 The attached writepng.c fixes a bug discovered by Hans: In the new version, Colorspaces were always written direct (img_colorspace_ref() was ignored). That broke the image color processing that ConTeXt does. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-13 16:57 Message: Logged In: YES user_id=421 This has been included in version 1.30.0 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-14 12:03 Message: Logged In: YES user_id=1608 changes as agreed at Pont-a-Mousson: -\pdfoptionimageforcegray removed -\pdfoptionimageapplygamma is now 0 or 1 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-03 17:00 Message: Logged In: YES user_id=1608 Bugfixes in 16-bit color depth mode (needs an 8-bit alpha channel) and corrected PNG transformation discovery for gray conversion. This is a final version for now, it should be added to a pdftex beta to allow 'in the wild' testing. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-01 13:38 Message: Logged In: YES user_id=1608 This update fixes the \pdfoptionimageforcegray bugs discovered by Hartmut. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 17:27 Message: Logged In: YES user_id=1608 Sorry, I forgot the 16-bit color code in the previous version ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 16:38 Message: Logged In: YES user_id=1608 This new version incorporates the code from Hartmut's speed patch. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106

1 0

[ pdftex-Patches-259 ] Expanded png inclusion support
by noreply＠sarovar.org 25 Jul '05

25 Jul '05

Patches item #259, was opened at 2005-01-11 16:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106 Category: Image inclusion Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Hartmut Henkel (hhenkel) Summary: Expanded png inclusion support Initial Comment: The attached zip file contains a change file for all pdftex's (to be applied *after* hz.cg) and a completely new writepng.c ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2005-07-25 10:56 Message: Logged In: YES user_id=1608 The attached writepng.c fixes a bug discovered by Hans: In the new version, Colorspaces were always written direct (img_colorspace_ref() was ignored). That broke the image color processing that ConTeXt does. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-13 16:57 Message: Logged In: YES user_id=421 This has been included in version 1.30.0 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-14 12:03 Message: Logged In: YES user_id=1608 changes as agreed at Pont-a-Mousson: -\pdfoptionimageforcegray removed -\pdfoptionimageapplygamma is now 0 or 1 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-03 17:00 Message: Logged In: YES user_id=1608 Bugfixes in 16-bit color depth mode (needs an 8-bit alpha channel) and corrected PNG transformation discovery for gray conversion. This is a final version for now, it should be added to a pdftex beta to allow 'in the wild' testing. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-01 13:38 Message: Logged In: YES user_id=1608 This update fixes the \pdfoptionimageforcegray bugs discovered by Hartmut. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 17:27 Message: Logged In: YES user_id=1608 Sorry, I forgot the 16-bit color code in the previous version ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 16:38 Message: Logged In: YES user_id=1608 This new version incorporates the code from Hartmut's speed patch. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106

2 1

[ pdftex-Patches-259 ] Expanded png inclusion support
by noreply＠sarovar.org 25 Jul '05

25 Jul '05

Patches item #259, was opened at 2005-01-11 16:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106 Category: Image inclusion Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Hartmut Henkel (hhenkel) Summary: Expanded png inclusion support Initial Comment: The attached zip file contains a change file for all pdftex's (to be applied *after* hz.cg) and a completely new writepng.c ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-13 16:57 Message: Logged In: YES user_id=421 This has been included in version 1.30.0 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-14 12:03 Message: Logged In: YES user_id=1608 changes as agreed at Pont-a-Mousson: -\pdfoptionimageforcegray removed -\pdfoptionimageapplygamma is now 0 or 1 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-03 17:00 Message: Logged In: YES user_id=1608 Bugfixes in 16-bit color depth mode (needs an 8-bit alpha channel) and corrected PNG transformation discovery for gray conversion. This is a final version for now, it should be added to a pdftex beta to allow 'in the wild' testing. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-01 13:38 Message: Logged In: YES user_id=1608 This update fixes the \pdfoptionimageforcegray bugs discovered by Hartmut. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 17:27 Message: Logged In: YES user_id=1608 Sorry, I forgot the 16-bit color code in the previous version ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 16:38 Message: Logged In: YES user_id=1608 This new version incorporates the code from Hartmut's speed patch. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106

1 0

endstream
by Hans Hagen 25 Jul '05

25 Jul '05

Hi, In former pdftex verions 'endstream' was on a line of its own, which is more handy when looking into a pdf file that the current 'end of line' method. Is there a reason for this change? 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 -----------------------------------------------------------------

3 4