- ntg-pdftex - NTG Mailing Lists

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

28 Jun '07

Bugs item #747, was opened at 2007-03-09 03:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 06:45 Message: Logged In: YES user_id=710 I agree this is an ugly solution, which has its origin in a design mistake. However the problem here is not only how to deal with the error message, but the point is how to use font expansion with a letterspaced font. Please give it a thought so we can come up with an acceptable workaround. If we want everything to be clean, there are more things that have to be thrown away. what about this: have a primitive \copyfont which creates a copy of a font. Example: \letterspacefont\lsfont\font 100 \copyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-27 11:43 Message: Logged In: YES user_id=1608 If there is no clean way of solving the problem, I'd rather just document the error message as a feature. I find \pdfnewexpandfont very ugly (sorry Thanh). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 00:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 09:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 11:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 20:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 17:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0

Re: [NTG-pdftex] Image dimension in DVI mode (was: images in formats)
by Thanh Han The 27 Jun '07

27 Jun '07

On Wed, Jun 27, 2007 at 10:20:37PM +0200, Heiko Oberdiek wrote: > On Wed, Jun 27, 2007 at 08:15:09PM +0200, Thanh Han The wrote: > > > fwiw, pdftex has support for reading image dimension that > > can be used in dvi mode (added as requested by ChoF, who > > uses pdftex mainly in dvi mode and use dvipdfmx to create > > pdf). > > What do you mean with "reading image dimension in dvi mode"? > > pdfTeX 1.40.3: > ! pdfTeX error (\pdfximage): not allowed in DVI mode (\pdfoutput <= 0). > > Or are you referring to the package `bmpsize'? you got me: I said something I didn't test. actually I added \pdfximagebbox as Cho requested, but it seems that nobody has ever tested/used it, including me and Cho. Thanh

1 0

Re: [NTG-pdftex] images in formats
by Thanh Han The 27 Jun '07

27 Jun '07

On Wed, Jun 27, 2007 at 07:13:36PM +0200, Hans Hagen wrote: > Thanh Han The wrote: > >dumping an image in pdf mode is rather difficult to get > >right. If in dvi mode an image is "stored" by a reference to > >an external file, then I am afraid the speed gain is not > >that much. There is for sure some comfort by having a dumped > >file reference in the format, but again that can be also > >achieved for pdf mode using some macros IMHO. > > to me it looks like a rather useless option to include an image in a > format, just as we don't embed type 1 fonts in the format either so > let's not waste energy on it > > >My vote is also to disable \pdfrefximage and the likes in > >init mode. > > depends a bit what 'the likes' is, i can imagine that one wants to > measure the dimensions of a graphic or so and store them, but indeed > the ref to an imag ecan be disabled I had that in mind too, that's way I voted to disable \pdfrefximage instead of \pdfximage. The likes here are \pdfrefobj, \pdfrefxform and perhaps those that can cause pdftex to write anything to the output. fwiw, pdftex has support for reading image dimension that can be used in dvi mode (added as requested by ChoF, who uses pdftex mainly in dvi mode and use dvipdfmx to create pdf). > also, those who generate a format should know what they're doing/dealing > with indeed Thanh

3 2

[ pdftex-Bugs-824 ] Bus error caused by loading an image into a format file
by noreply＠sarovar.org 27 Jun '07

27 Jun '07

Bugs item #824, was opened at 2007-06-26 00:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106 Category: Image inclusion Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robin Houston (robinhouston) Assigned to: Martin Schröder (oneiros) Summary: Bus error caused by loading an image into a format file Initial Comment: I have written a tool that speeds up repeated compilation of a source file, by generating a format from the preamble of the document, and then using it to compile the body. One user reported a crash when using this tool with a custom letterhead class; the class in question may be found at http://www.soe.ucsc.edu/~elm/LaTeX/ucletter.cls (though note that a simpler demonstration is attached to this report). The bug is triggered by the fact that this class loads an image during the processing of the preamble (i.e. during the processing of the .ini file) and saves it in a box. When this box is used, during the compilation of the body, pdftex crashes. This does work with ordinary (non-PDF) TeX, so the problem is specific to PDFTeX. The attachment contains a simple demonstration of the problem. Unpack it and run 'make'. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-06-26 23:01 Message: Logged In: YES user_id=421 Sorry, pdf things work different then dvi, so we can not make \pdfximage etc. in ini mode without a lot of work; we will probably disable a bunch of primitives. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-26 15:49 Message: Logged In: YES user_id=4579 Simplifying the example by eliminating the graphics package: ==> foo.ini <== \documentclass{minimal} \newbox\picbox \pdfximage{pic.pdf} \setbox\picbox\hbox{\pdfrefximage\pdflastximage} \dump ==> foo.tex <== \begin{document} \box\picbox \end{document} Also, I see now that my comparison with dvi-mode is indeed a false one, because the mechanisms are quite different, and the DVI graphics driver only has to include a \special, rather than the graphic itself. A simple solution, I suppose, would be to make \pdfrefximage (and, presumably, the other \pdfrefx commands) invalid in IniTeX mode. Perhaps this is too brutal, since it forbids certain harmless activities such as finding the dimensions of an image from an .ini file; and of course I would be delighted if it were made to work instead. ---------------------------------------------------------------------- Comment By: Reinhard Kotucha (reinhard) Date: 2007-06-26 01:26 Message: Logged In: YES user_id=4195 Martin, you probably can't do everything in a format file. However, it would be nice to be able to put graphics to a format file at least. Suppose that a web server has to generate PDF files on-the-fly, each contains a company logo. The best place place for the logo is the format file if speed matters. It would be nice if there are no restrictions. Regards, Reinhard ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-26 00:42 Message: Logged In: YES user_id=4579 I'm impressed by the speed of your response! Thanks. If you replace the PDF image by an EPS file, and use -output-format dvi, then it does work. That suggests to me that the problem is not fundamentally caused by a limitation of IniTeX. But I don't know enough about the inner workings of the \includegraphics command to be sure about that. (Perhaps PDF graphics are handled in a sufficiently different way for this to be a false comparison?) In any case, as you say, it shouldn't crash! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-26 00:30 Message: Logged In: YES user_id=421 I can reproduce it, and it obviously shouldn't crash, but I'm really not shure if it's supposed to work, as the format of course will not save the picture. You can't do everything in IniTeX... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

4 10

[ pdftex-Feature Requests-572 ] non-compression of pdfxform
by noreply＠sarovar.org 27 Jun '07

27 Jun '07

Feature Requests item #572, was opened at 2006-06-10 23:11 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=572&group_id=106 Category: None >Group: v1.50 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: ivo welch (iaw4) Assigned to: Nobody (None) Summary: non-compression of pdfxform Initial Comment: would it be possible to add a feature to avoid compression of the user defined pdfxform stream? [goal: I want to define a string that I can then change via a shell/perl script in the .pdf file itself. I know I have to keep the same number of characters.] \newcount\XOBJA \setbox1=\hbox{12345678909876543210123456789} % this is a special string that one can later replace in the pdf file by hand \pdfxform 1 \XOBJA=\pdflastxform \begin{document} Here is my string on page \arabic{page}: \pdfrefxform \XOBJA \end{document} $ sed 's/12345678909876543210123456789/for user pdftex.../' < myfile.pdf I experimented with setting pdfcompresslevel and resetting it, but it is not reliable in when compression starts. in any case, I do not want the rest at low compression, just my own XOBJ xform. regards, /iaw ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-06-27 14:55 Message: Logged In: YES user_id=421 It seems nobody needs this anymore; anyway one can achieve the same with pdftk. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 00:02 Message: Logged In: YES user_id=421 Ivo, sorry for not reacting earlier. Adding this feature seems possible. Is it still needed? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=572&group_id=106

1 0

[ pdftex-Feature Requests-825 ] Switch to disable pk-fonts
by noreply＠sarovar.org 27 Jun '07

27 Jun '07

Feature Requests item #825, was opened at 2007-06-27 14:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=825&group_id=106 Category: Fonts Group: v1.50 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: Switch to disable pk-fonts Initial Comment: This has just been raised on the MikTeX users lists: It would be nice if one could disable all pk-Fonts at once either with a cmdline switch or a command. Shouldn't be too hard to implement. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=825&group_id=106

1 0

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

27 Jun '07

Bugs item #747, was opened at 2007-03-09 04:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-06-27 13:43 Message: Logged In: YES user_id=1608 If there is no clean way of solving the problem, I'd rather just document the error message as a feature. I find \pdfnewexpandfont very ugly (sorry Thanh). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 12:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 02:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 11:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 12:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 21:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 20:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 20:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 18:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0

[ pdftex-Bugs-480 ] pdftex offset incorrect with \magnification. Patch included.
by noreply＠sarovar.org 27 Jun '07

27 Jun '07

Bugs item #480, was opened at 2006-02-12 18:12 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106 Category: None Group: v1.30.0 >Status: Closed Resolution: Wont Fix Priority: 3 Submitted By: Ian Hutchinson (ihutch) Assigned to: Nobody (None) Summary: pdftex offset incorrect with \magnification. Patch included. Initial Comment: Any plain tex file that uses \magnification gives incorrect text placement in pdf. This bug is present in the latest pdftex version 1.21a. It apparently was caused by the introduction of the new variables \pdfvoffset and \pdfhoffset. This bug was not present in older pdftex, e.g. version 3.14159-1.10b, which was part of tetex-2... A simple illustration of the problem is with the trivial file: \magnification \magstep3 %The following parindent and offset changes are not the cause of errors. %They are merely to illustrate them clearly by writing at top left. %Anything other than \magstep0 gives a placement error with pdftex 1.21a. \parindent 0pt \hoffset -1 truein \voffset -1 truein The top. \end With tex and xdvi, the words "The top." are placed at the immediate top left. With pdftex 1.21a and xpdf (or acroread) they are not. With earlier pdftex 1.10b (e.g.) they are. I had an extensive discussion on comp.text.tex with Heiko Oberdiek, most of which is at http://www.codecomments.com/Tex/message784423.html The gist of it is that backward compatibility with plain tex files is very important. As far as possible, it should be preserved transparently. Authors should not be required to hack their files in order for them to render the same in pdf as in dvi. Moreover there is a simple way to provide this compatibility. A reasonable way to fix the bug is to change pdftex.ini and hence pdftex.fmt. (The corresponding pdfetex files ought also to be fixed.) A proposed patched pdftex.ini file is attached. It consists simply of % Thomas Esser, 1998, 2004. public domain. \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \input pdftexconfig \pdfoutput=1 \fi \fi \input plain \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \catcode`@=11 \def\m@g{% \mag\count@ \hsize6.5truein\vsize8.9truein\dimen\footins8truein %These commands fix the pdf sizes to be in true units. \mag@fix\pdfhorigin \mag@fix\pdfvorigin \mag@fix\pdfpagewidth \mag@fix\pdfpageheight } \def\mag@fix#1{% #1=\expandafter\convert@truept\the#1\relax } \begingroup \catcode`P=12 \catcode`T=12 \lowercase{% \endgroup \def\convert@truept#1PT{% #1truept% }% }% \catcode`@=12 \fi \fi \dump \endinput I don't know who takes responsibility for pdftex.ini. But clearly this ought to be fixed for all distributions. I care most about tetex, because it is what I use. Thanks, Ian Hutchinson ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-06-27 13:01 Message: Logged In: YES user_id=1608 Considering this behaviour of pdftex has been there since 1.21a, this is how it should stay when it comes to the executable itself. And pdftex.ini is controlled by the tex-live team (tex-live(a)tug.org) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 20:49 Message: Logged In: YES user_id=710 oh yes, thanks Phil for the correction. In response to Ian Hutchinson: I am the maintainer of neither pdftex.ini nor pdftex, so I feel that someone else must make the decision. ---------------------------------------------------------------------- Comment By: Philip TAYLOR (chaa006) Date: 2006-10-23 20:21 Message: Logged In: YES user_id=3040 Thanh wrote : I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in Surely they should write \pdfhorigin = 1 true in \pdfvorigin = 1 true in should they not ? I always do, and it certainly has the intended effect. ** Phil. ---------------------------------------------------------------------- Comment By: Ian Hutchinson (ihutch) Date: 2006-10-23 19:49 Message: Logged In: YES user_id=3410 In response to hanthethanh, let me explain once again that the point is that TeX ought always to work the same with both dvi output and pdf output. The latest pdftex breaks that for all documents, old or new, that use \magnification. Of course there are many ways the authors can fix those documents by adding new commands. BUT THEY SHOULD NOT HAVE TO. TeX's archival integrity is far too valuable for us to accept it being broken by this incompatibility. I've shown how it can be transparently fixed. The correction just needs to be incorporated into the distributions ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 12:37 Message: Logged In: YES user_id=710 I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in or something similar. An undocumented trick is that if \pdfhorigin or \pdfvorigin is not set (or set to 0) when the first page is shipped out, then they will get 1in as the default value. To get zero origin(s), use 1sp instead of 0. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106

1 0

[ pdftex-Bugs-824 ] Bus error caused by loading an image into a format file
by noreply＠sarovar.org 26 Jun '07

26 Jun '07

Bugs item #824, was opened at 2007-06-25 23:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106 Category: Image inclusion Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robin Houston (robinhouston) Assigned to: Martin Schröder (oneiros) Summary: Bus error caused by loading an image into a format file Initial Comment: I have written a tool that speeds up repeated compilation of a source file, by generating a format from the preamble of the document, and then using it to compile the body. One user reported a crash when using this tool with a custom letterhead class; the class in question may be found at http://www.soe.ucsc.edu/~elm/LaTeX/ucletter.cls (though note that a simpler demonstration is attached to this report). The bug is triggered by the fact that this class loads an image during the processing of the preamble (i.e. during the processing of the .ini file) and saves it in a box. When this box is used, during the compilation of the body, pdftex crashes. This does work with ordinary (non-PDF) TeX, so the problem is specific to PDFTeX. The attachment contains a simple demonstration of the problem. Unpack it and run 'make'. ---------------------------------------------------------------------- >Comment By: Robin Houston (robinhouston) Date: 2007-06-26 14:49 Message: Logged In: YES user_id=4579 Simplifying the example by eliminating the graphics package: ==> foo.ini <== \documentclass{minimal} \newbox\picbox \pdfximage{pic.pdf} \setbox\picbox\hbox{\pdfrefximage\pdflastximage} \dump ==> foo.tex <== \begin{document} \box\picbox \end{document} Also, I see now that my comparison with dvi-mode is indeed a false one, because the mechanisms are quite different, and the DVI graphics driver only has to include a \special, rather than the graphic itself. A simple solution, I suppose, would be to make \pdfrefximage (and, presumably, the other \pdfrefx commands) invalid in IniTeX mode. Perhaps this is too brutal, since it forbids certain harmless activities such as finding the dimensions of an image from an .ini file; and of course I would be delighted if it were made to work instead. ---------------------------------------------------------------------- Comment By: Reinhard Kotucha (reinhard) Date: 2007-06-26 00:26 Message: Logged In: YES user_id=4195 Martin, you probably can't do everything in a format file. However, it would be nice to be able to put graphics to a format file at least. Suppose that a web server has to generate PDF files on-the-fly, each contains a company logo. The best place place for the logo is the format file if speed matters. It would be nice if there are no restrictions. Regards, Reinhard ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-25 23:42 Message: Logged In: YES user_id=4579 I'm impressed by the speed of your response! Thanks. If you replace the PDF image by an EPS file, and use -output-format dvi, then it does work. That suggests to me that the problem is not fundamentally caused by a limitation of IniTeX. But I don't know enough about the inner workings of the \includegraphics command to be sure about that. (Perhaps PDF graphics are handled in a sufficiently different way for this to be a false comparison?) In any case, as you say, it shouldn't crash! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 23:30 Message: Logged In: YES user_id=421 I can reproduce it, and it obviously shouldn't crash, but I'm really not shure if it's supposed to work, as the format of course will not save the picture. You can't do everything in IniTeX... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

1 0

[ pdftex-Bugs-824 ] Bus error caused by loading an image into a format file
by noreply＠sarovar.org 25 Jun '07

25 Jun '07

Bugs item #824, was opened at 2007-06-26 00:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106 Category: Image inclusion Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robin Houston (robinhouston) Assigned to: Martin Schröder (oneiros) Summary: Bus error caused by loading an image into a format file Initial Comment: I have written a tool that speeds up repeated compilation of a source file, by generating a format from the preamble of the document, and then using it to compile the body. One user reported a crash when using this tool with a custom letterhead class; the class in question may be found at http://www.soe.ucsc.edu/~elm/LaTeX/ucletter.cls (though note that a simpler demonstration is attached to this report). The bug is triggered by the fact that this class loads an image during the processing of the preamble (i.e. during the processing of the .ini file) and saves it in a box. When this box is used, during the compilation of the body, pdftex crashes. This does work with ordinary (non-PDF) TeX, so the problem is specific to PDFTeX. The attachment contains a simple demonstration of the problem. Unpack it and run 'make'. ---------------------------------------------------------------------- Comment By: Reinhard Kotucha (reinhard) Date: 2007-06-26 01:26 Message: Logged In: YES user_id=4195 Martin, you probably can't do everything in a format file. However, it would be nice to be able to put graphics to a format file at least. Suppose that a web server has to generate PDF files on-the-fly, each contains a company logo. The best place place for the logo is the format file if speed matters. It would be nice if there are no restrictions. Regards, Reinhard ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-26 00:42 Message: Logged In: YES user_id=4579 I'm impressed by the speed of your response! Thanks. If you replace the PDF image by an EPS file, and use -output-format dvi, then it does work. That suggests to me that the problem is not fundamentally caused by a limitation of IniTeX. But I don't know enough about the inner workings of the \includegraphics command to be sure about that. (Perhaps PDF graphics are handled in a sufficiently different way for this to be a false comparison?) In any case, as you say, it shouldn't crash! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-26 00:30 Message: Logged In: YES user_id=421 I can reproduce it, and it obviously shouldn't crash, but I'm really not shure if it's supposed to work, as the format of course will not save the picture. You can't do everything in IniTeX... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

1 0

[ pdftex-Bugs-824 ] Bus error caused by loading an image into a format file
by noreply＠sarovar.org 25 Jun '07

25 Jun '07

Bugs item #824, was opened at 2007-06-25 23:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106 Category: Image inclusion Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robin Houston (robinhouston) Assigned to: Martin Schröder (oneiros) Summary: Bus error caused by loading an image into a format file Initial Comment: I have written a tool that speeds up repeated compilation of a source file, by generating a format from the preamble of the document, and then using it to compile the body. One user reported a crash when using this tool with a custom letterhead class; the class in question may be found at http://www.soe.ucsc.edu/~elm/LaTeX/ucletter.cls (though note that a simpler demonstration is attached to this report). The bug is triggered by the fact that this class loads an image during the processing of the preamble (i.e. during the processing of the .ini file) and saves it in a box. When this box is used, during the compilation of the body, pdftex crashes. This does work with ordinary (non-PDF) TeX, so the problem is specific to PDFTeX. The attachment contains a simple demonstration of the problem. Unpack it and run 'make'. ---------------------------------------------------------------------- >Comment By: Robin Houston (robinhouston) Date: 2007-06-25 23:42 Message: Logged In: YES user_id=4579 I'm impressed by the speed of your response! Thanks. If you replace the PDF image by an EPS file, and use -output-format dvi, then it does work. That suggests to me that the problem is not fundamentally caused by a limitation of IniTeX. But I don't know enough about the inner workings of the \includegraphics command to be sure about that. (Perhaps PDF graphics are handled in a sufficiently different way for this to be a false comparison?) In any case, as you say, it shouldn't crash! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 23:30 Message: Logged In: YES user_id=421 I can reproduce it, and it obviously shouldn't crash, but I'm really not shure if it's supposed to work, as the format of course will not save the picture. You can't do everything in IniTeX... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

1 0

[ pdftex-Bugs-824 ] Bus error caused by loading an image into a format file
by noreply＠sarovar.org 25 Jun '07

25 Jun '07

Bugs item #824, was opened at 2007-06-26 00:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106 Category: Image inclusion Group: v1.40.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robin Houston (robinhouston) Assigned to: Martin Schröder (oneiros) Summary: Bus error caused by loading an image into a format file Initial Comment: I have written a tool that speeds up repeated compilation of a source file, by generating a format from the preamble of the document, and then using it to compile the body. One user reported a crash when using this tool with a custom letterhead class; the class in question may be found at http://www.soe.ucsc.edu/~elm/LaTeX/ucletter.cls (though note that a simpler demonstration is attached to this report). The bug is triggered by the fact that this class loads an image during the processing of the preamble (i.e. during the processing of the .ini file) and saves it in a box. When this box is used, during the compilation of the body, pdftex crashes. This does work with ordinary (non-PDF) TeX, so the problem is specific to PDFTeX. The attachment contains a simple demonstration of the problem. Unpack it and run 'make'. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-06-26 00:30 Message: Logged In: YES user_id=421 I can reproduce it, and it obviously shouldn't crash, but I'm really not shure if it's supposed to work, as the format of course will not save the picture. You can't do everything in IniTeX... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

1 0

[ pdftex-Bugs-824 ] Bus error caused by loading an image into a format file
by noreply＠sarovar.org 25 Jun '07

25 Jun '07

Bugs item #824, was opened at 2007-06-25 23:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106 Category: Image inclusion Group: v1.40.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Houston (robinhouston) Assigned to: Martin Schröder (oneiros) Summary: Bus error caused by loading an image into a format file Initial Comment: I have written a tool that speeds up repeated compilation of a source file, by generating a format from the preamble of the document, and then using it to compile the body. One user reported a crash when using this tool with a custom letterhead class; the class in question may be found at http://www.soe.ucsc.edu/~elm/LaTeX/ucletter.cls (though note that a simpler demonstration is attached to this report). The bug is triggered by the fact that this class loads an image during the processing of the preamble (i.e. during the processing of the .ini file) and saves it in a box. When this box is used, during the compilation of the body, pdftex crashes. This does work with ordinary (non-PDF) TeX, so the problem is specific to PDFTeX. The attachment contains a simple demonstration of the problem. Unpack it and run 'make'. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

1 0

[ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by noreply＠sarovar.org 25 Jun '07

25 Jun '07

Bugs item #772, was opened at 2007-04-13 04:54 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106 Category: web2c Group: v1.40.0 Status: Open Resolution: Accepted Priority: 4 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Option -recorder does not work for Type1 or PK files Initial Comment: Hello, pdfTeX 1.40.3 supports the Web2C feature, enabled by option -recorder. However, it does not record all files, .pfb (Type1) or .pk files are missing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: texmf.cnf isn't recorded either. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-06-25 12:41 Message: Logged In: YES user_id=421 A much simpler patch is attached; it also catches the new pipe feature. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 01:33 Message: Logged In: YES user_id=421 Attached is a patch that should fix this. Please test. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2007-04-17 13:19 Message: Logged In: YES user_id=1276 Hello, to prevent that it gets lost, a followup of mine in ntg-pdftex mailing list: After further testing (sorry) I found other gaps in file name recording: \pdfximage{<file>} \pdffilesize{<file>} \pdffilemoddate{<file>} \pdffiledump{<file>} \pdfmdfivesum file{<file>} Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0

[ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #772, was opened at 2007-04-13 04:54 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106 Category: web2c Group: v1.40.0 Status: Open Resolution: Accepted Priority: 4 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Option -recorder does not work for Type1 or PK files Initial Comment: Hello, pdfTeX 1.40.3 supports the Web2C feature, enabled by option -recorder. However, it does not record all files, .pfb (Type1) or .pk files are missing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: texmf.cnf isn't recorded either. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-06-25 01:33 Message: Logged In: YES user_id=421 Attached is a patch that should fix this. Please test. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2007-04-17 13:19 Message: Logged In: YES user_id=1276 Hello, to prevent that it gets lost, a followup of mine in ntg-pdftex mailing list: After further testing (sorry) I found other gaps in file name recording: \pdfximage{<file>} \pdffilesize{<file>} \pdffilemoddate{<file>} \pdffiledump{<file>} \pdfmdfivesum file{<file>} Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0

[ pdftex-Bugs-736 ] font expansion leads to wrong log output of \kerns.
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #736, was opened at 2007-02-22 03:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=736&group_id=106 Category: hz Group: v1.40.1 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: font expansion leads to wrong log output of \kerns. Initial Comment: When applying font expansion, implicit kerns will be output *with* a space in the log file, which makes them appear like explicit kerns. The following \tracingoutput1 \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand bye\bye will yield ...\tenrm b ...\kern -0.27779 ...\tenrm y ...\kern -0.27779 ...etc. instead of ...\tenrm b ...\kern-0.27779 ...\tenrm y ...\kern-0.27779 ...etc. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-24 23:44 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-28 15:16 Message: Logged In: YES user_id=710 Here is an attempt to fix the bug. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-22 11:46 Message: Logged In: YES user_id=710 I confirm the bug. Will try to fix it soon. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=736&group_id=106

1 0

[ pdftex-Bugs-721 ] Missing /Font object of PK file not found
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #721, was opened at 2007-01-23 21:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=721&group_id=106 Category: Fonts Group: v1.40.1 Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Missing /Font object of PK file not found Initial Comment: There are several cases, the buggy one is no. 3. See test files test1...4.tex in the attached file. 1. No TFM file found in the 1st place. ---> No TeX font will be started. Ok. See test1.tex. 2. TFM file found, map entry existing, but no PFB font file in map line ---> "pdfTeX warning: pdftex: font `CMR' is not a standard font; I suppose it is available to your PDF viewer then". Ok. See test2.tex. 3. TFM file found, no map entry, and no PK font available. ---> "pdfTeX warning: pdftex (file mf-nonexist): Font mf-nonexist at 600 not found". Not ok. See test3.tex. Here a /Font object is referenced, which is not existing, rendering the resulting PDF file buggy. There should be either pdftex_fail() or or at least a /Font object with a dummy /FontDescriptor object should be created (the latter filled with defaults from the TFM file), and the same warning should be given as in case 4 below, since these cases are similar: fontfile expected, but not available. 4. TFM file found, map entry with PFB font file existing, but no PFB font file found. ---> "pdfTeX warning: pdftex (file t1-nonexist.pfb): cannot open Type 1 font file for reading". /FontDescriptor without /FontFile, correct. Ok. See test4.tex. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-24 22:40 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 12:48 Message: Logged In: YES user_id=710 patch updated, a typo was in the previous one. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 09:58 Message: Logged In: YES user_id=710 Here is a patch to turn some warnings that can lead to invalid pdf output to fatal errors. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=721&group_id=106

1 0

[ pdftex-Bugs-722 ] PDF generation does not support VF fonts correctly
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #722, was opened at 2007-01-24 09:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=722&group_id=106 Category: Fonts Group: v1.40.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Achim Blumensath (blume) Assigned to: The Thanh Han (hanthethanh) Summary: PDF generation does not support VF fonts correctly Initial Comment: I've a problem with using VF fonts in PDF mode (using pdftex 1.40.1, pdftex 1.20b does work correctly). When using glyphs that are composed of several other glyphs the various parts appear not at their correct position. The following example requires the MnSymbol and the MinionPro packages. \documentclass{minimal} \usepackage[T1]{fontenc} \usepackage[minionint]{MinionPro} \begin{document} $$\iint \quad \oint$$ \end{document} If you create a DVI and use dvips + ps2pdf the output is as expected (one double integral and one closed integral). If you use pdflatex to create a PDF file directly then the output is wrong. The double integral consists of just one integral sign and the closed integral consists of a circle followed by an integral sign. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-24 23:05 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-27 23:29 Message: Logged In: YES user_id=710 Bugfix resubmitted, this time without the new primitive \pdfreplacefont ---------------------------------------------------------------------- Comment By: Achim Blumensath (blume) Date: 2007-01-31 09:41 Message: Logged In: YES user_id=4173 The patch seems to work fine. Thanks. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-29 20:46 Message: Logged In: YES user_id=710 I made some changes in pdftex. Your test file looks almost ok now :). Can you please try the patch to see whether it works for you. Since I don't have exactly the same fonts you used, it might be helpful if you try the patch with your tex setup. Thanks. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-26 11:55 Message: Logged In: YES user_id=710 indeed this is a bug of pdftex. I found the bug, should be fixed soon. ---------------------------------------------------------------------- Comment By: Achim Blumensath (blume) Date: 2007-01-26 09:47 Message: Logged In: YES user_id=4173 Sorry, I forgot to mention that I couldn't include the pfb for copyright reasons. You need the opticals version of MinionPro to get MinionPro-ItDisp.pfb. If you don't have the optical fonts the easiest workaround is to create a PFB with just one glyph named /integral of width 310 units. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-26 08:47 Message: Logged In: YES user_id=710 I still got: pdfTeX warning: pdftex (file MinionPro-ItDisp.pfb): cannot open Type 1 font file for reading I checked out the cvs version of MinionPro and run the makeall script as described in README-src, but still I didn't see MinionPro-ItDisp.pfb. ---------------------------------------------------------------------- Comment By: Achim Blumensath (blume) Date: 2007-01-26 07:21 Message: Logged In: YES user_id=4173 I've simplified the test case to plain TeX. The requested files are attached. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-01-25 15:01 Message: Logged In: YES user_id=421 Note that the -recorder cmdline switch also works quite well with kpathsea. :-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-25 09:43 Message: Logged In: YES user_id=710 I tested the file again with the fonts you uploaded, but still I cannot reproduce the problem. I attached a small script that creates a list of all files opened by tex. Usage: unpack, put list-tex-files.vim under ~/vim and run: sh list-tex-files pdflatex testfile it will report the filename of the list, which can be used then to pack everything needed to rerun the job. You may want to review the list to remove a few files that are not relevant, for example the format. ---------------------------------------------------------------------- Comment By: Achim Blumensath (blume) Date: 2007-01-25 07:54 Message: Logged In: YES user_id=4173 In order to preproduce the bug you need the CVS version on MinionPro and perhaps also a recent version of the lcdf-typetools. The problem seems to be that the font MnSymbolFI10.vf refers again to a virtual font MinionPro-It-integral.vf. I've attached the corresponding VPL files. (I didn't have the time to create the requested PDF files. Will do so shortly.) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-24 19:52 Message: Logged In: YES user_id=710 I compiled the test file and got normal output (see attached screenshot). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-01-24 15:56 Message: Logged In: YES user_id=421 Please attach the PDFs generated by ps2pdf and pdflatex, best generated with \pdfcompresslevel=0. And the log from pdflatex. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=722&group_id=106

1 0

[ pdftex-Bugs-721 ] Missing /Font object of PK file not found
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Bugs item #721, was opened at 2007-01-23 21:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=721&group_id=106 Category: Fonts Group: v1.40.1 >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Missing /Font object of PK file not found Initial Comment: There are several cases, the buggy one is no. 3. See test files test1...4.tex in the attached file. 1. No TFM file found in the 1st place. ---> No TeX font will be started. Ok. See test1.tex. 2. TFM file found, map entry existing, but no PFB font file in map line ---> "pdfTeX warning: pdftex: font `CMR' is not a standard font; I suppose it is available to your PDF viewer then". Ok. See test2.tex. 3. TFM file found, no map entry, and no PK font available. ---> "pdfTeX warning: pdftex (file mf-nonexist): Font mf-nonexist at 600 not found". Not ok. See test3.tex. Here a /Font object is referenced, which is not existing, rendering the resulting PDF file buggy. There should be either pdftex_fail() or or at least a /Font object with a dummy /FontDescriptor object should be created (the latter filled with defaults from the TFM file), and the same warning should be given as in case 4 below, since these cases are similar: fontfile expected, but not available. 4. TFM file found, map entry with PFB font file existing, but no PFB font file found. ---> "pdfTeX warning: pdftex (file t1-nonexist.pfb): cannot open Type 1 font file for reading". /FontDescriptor without /FontFile, correct. Ok. See test4.tex. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-24 22:40 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 12:48 Message: Logged In: YES user_id=710 patch updated, a typo was in the previous one. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 09:58 Message: Logged In: YES user_id=710 Here is a patch to turn some warnings that can lead to invalid pdf output to fatal errors. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=721&group_id=106

1 0

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

24 Jun '07

Bugs item #747, was opened at 2007-03-09 03:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 00:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 09:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 11:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 20:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 17:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Patches item #812, was opened at 2007-06-23 17:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: Primitives Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 08:41 Message: Logged In: YES user_id=710 sounds good to me. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-24 08:28 Message: Logged In: YES user_id=1608 I see an advantage in having a configurable parameter over the arbitrary constant that \prevdepth currently uses. But if that is the case, it makes sense to apply it to \prevdepth as well. So how about \pdfignoreddimen instead, that defaults to -1000pt, and is also used by \prevdepth ? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 08:26 Message: Logged In: YES user_id=710 another patch uploaded, so the pdftex team can choose between them. Hope to make Nobody (None) happy. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 17:29 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Patches item #812, was opened at 2007-06-23 19:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: Primitives Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-06-24 10:28 Message: Logged In: YES user_id=1608 I see an advantage in having a configurable parameter over the arbitrary constant that \prevdepth currently uses. But if that is the case, it makes sense to apply it to \prevdepth as well. So how about \pdfignoreddimen instead, that defaults to -1000pt, and is also used by \prevdepth ? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:26 Message: Logged In: YES user_id=710 another patch uploaded, so the pdftex team can choose between them. Hope to make Nobody (None) happy. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 19:29 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 24 Jun '07

24 Jun '07

Patches item #812, was opened at 2007-06-23 17:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: Primitives Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 08:26 Message: Logged In: YES user_id=710 another patch uploaded, so the pdftex team can choose between them. Hope to make Nobody (None) happy. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 17:29 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ pdftex-Patches-811 ] Patch to change warning mesage for conflicting font attributes (given by \pdffontattr)
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Patches item #811, was opened at 2007-06-23 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106 >Category: Fonts Group: v1.50.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: Patch to change warning mesage for conflicting font attributes (given by \pdffontattr) Initial Comment: This is a tiny patch to change the warning message for conflicting font attributes (as given by \pdffontattr), to make it clearer what is going on. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106

1 0

[ pdftex-Patches-813 ] new primitive \pdfinclusioncopyfonts
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Patches item #813, was opened at 2007-06-23 19:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106 >Category: Fonts >Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) >Assigned to: Hartmut Henkel (hhenkel) Summary: new primitive \pdfinclusioncopyfonts Initial Comment: this is a replacement for \pdfreplacefont, with the opposite semantics. When this is set, fonts from included pdfs are always copied. This is useful to prevent pdftex from replacing fonts in included pdfs, without messing around with map files. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106

1 0