- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-605 ] \pdfescapestring + \pdfescapename are broken in beta-20060906
by noreply＠sarovar.org 13 Sep '06

13 Sep '06

Bugs item #605, was opened at 2006-09-13 15:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=605&group_id=106 Category: None Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: \pdfescapestring + \pdfescapename are broken in beta-20060906 Initial Comment: The last char of escaped characters will always be ^^0: \def\text{P^^D (F)} \message{\pdfescapestring{\text}} \message{\pdfescapename {\text}} \bye % log output is: % P\00^^@\04^^@\(F\) % P#0^^@#2^^@#2^^@F#2^^@ ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=605&group_id=106

1 0

[ pdftex-Patches-603 ] Patch ColorStackTransformMatrix
by noreply＠sarovar.org 12 Sep '06

12 Sep '06

Patches item #603, was opened at 2006-09-07 10:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=603&group_id=106 Category: Primitives Group: v1.40.0 Status: Open Resolution: None Priority: 8 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Patch ColorStackTransformMatrix Initial Comment: Subject: Patch ColorStackTransformMatrix Date: 2006/09/07 Author: Heiko Oberdiek The patch is based on pdftex-1.40.0-beta-20060906 It tries to solve two FAQ problems: * missing color stack * wrong annotation rectangles (links, anchors) if the material was scaled or rotated. Files: ColorStackTransformMatrix.patch The patch, apply it in src/texk/web2c/pdftexdir: patch <ColorStackTransformMatrix.patch pdftex.def A modified version that uses the patch if the new primitives are found. A short test file: \documentclass{article} \usepackage{color} \usepackage{pdflscape} \usepackage{hyperref} \begin{document} \tableofcontents \section{Hello World} \label{sec:hello} \textcolor{blue}{Blue\newpage Blue} \begin{landscape} See \autoref{sec:hello}. \end{landscape} \end{document} Without the patch: * Text on first page before "Blue" is blue instead of black. * Text on second page is black instead of blue. * The link frame on page three is misplaced. With the patch and modified pdftex.def these things are fixed. New commands % color stack * \pdfcolorstackinit * \pdfcolorstack % matrix transformations * \pdfsetmatrix * \pdfsave * \pdfrestore Syntax: %% expandable commands: \pdfcolorstackinit [page] [direct] <general text> %% general commands: \pdfcolorstack <stack number> <stack action> <general text> \pdfsetmatrix \pdfsave \pdfrestore <stack action> ::= set | push | pop | current Description for color stack: This color stack implementation allows several independent stacks (upto 32686): * Stacks can be used for other properties than color, especially other graphics state parameters. * Several "text flows across pages" can be supported by color stacks. Example: footnotes. \pdfcolorstackinit [page] [direct] {<initial value>} A stack is initialized by \pdfcolorstackinit. It expands to the number of the new stack. The common case, the traditinal color stack is already initialized as first stack: \pdfcolorstackinit page direct {0 g 0 G} The keyword "page" means, that this stack is page based. At the start of the new page, the current stack value is automatically set: \textcolor{blue}{A\newpage B} The second page with "B" will start with blue setting. The keyword "direct" has the same meaning as "direct" for \pdfliteral. If the stack value is set, it is done by an equivalent of \pdfliteral direct {...}. The mandatory argument is the initial value on the stack. It should be the default at page start for the property, see PDF documentation. \pdfcolorstack <stack number> push {<new color>} pushes the current value on the stack and sets the <new color>. \pdfcolorstack <stack number> pop pops and sets the current stack value. \pdfcolorstack <stack number> current sets the current stack value without changing the stack. This is useful for stacks that are initialized without keyword "page". Thus the page start setting can be set manually. \pdfcolorstack <stack number> set {<new color>} The current value is set to <new color>. Example (changed pdftex.def): \chardef\GPT@colorstack=0 % \def\set@color{% \pdfcolorstack\GPT@colorstack push{\current@color}% \aftergroup\reset@color }% \def\reset@color{% \pdfcolorstack\GPT@colorstack pop\relax }% If someone wants to add color stack support for footnotes, the principle would be: \edef\stackfootnote{\pdfcolorstackinit direct{0 g 0 G}}% % Then at begin of the footnote area on the page: \pdfcolorstack\stackfoonote current\relax % During footnote processing the footnote stack is used: \let\GPT@colorstack\stackfoonote Description for matrix transformations: Currently matrix changes are done and hidden inside \pdfliteral nodes; pdfTeX doesn't parse its contents and does not know the new settings of the transform matrix. Thus the patch adds new primitives to save pdfTeX from parsing \pdfliteral contents and to notify pdfTeX about matrix changes to use them in calculating link and anchor positions. \pdfsetmatrix{<a> <c> <d>} is the equivalent to \pdfliteral{<a> <c> <d> 0 0 cm} \pdfsave is the equivalent to \pdfliteral{q} \pdfrestore is the equivalent to \pdfliteral{Q} Some remarks: * TeX already supports translations, thus the matrix is limited to four values for scaling and rotating. * There are some restrictions about \pdfsave and \pdfrestore: * They must be properly nested. * A pair must start and end in the same group at the same level. * A pair must start and end at the same position. Happily these restrictions are satisfied by the graphics package. Example (changed pdftex.def): \def\Grot@start{% \pdfsave \pdfsetmatrix{% \Grot@cos\space\Grot@sin\space \if-\Grot@sin\else-\Grot@sin\fi\space\Grot@cos }% \wd\z@\z@ }% \def\Grot@end{\pdfrestore} \def\Gscale@start{% \pdfsave \pdfsetmatrix{% \Gscale@x\space0 0 \Gscale@y }% }% Have fun Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: Heiko Oberdiek (oberdiek) Date: 2006-09-12 16:38 Message: Logged In: YES user_id=1276 | Two questions come to mind: | - how does this patch interact with existing documents, The design principle is that the patch does not have an effect if the new primitives are not used (modulo bugs). | i.e. | what must be changed when using this patch? Obviously the | use of \pdfliteral must be checked. Anything else? LaTeX's color/graphics: pdftex.def that support the new primitives. | - does this collide with pdftex's use of the cm? The only | use of the transformation matrix by pdftex I could find | concerns magnifications, so that's most likely not a | problem. I had played a little with magnification, but not too intensively. | Btw: gcc with -Wall -std=c99 gives this warning: | ../../../../src/texk/web2c/pdftexdir/utils.c: In function | ‘newcolorstack’: | ../../../../src/texk/web2c/pdftexdir/utils.c:1366: | warning: | operation on ‘colstacks’ may be undefined Assignments to colstacks are controlled by colstack_size, thus the warnung can be gnored. To avoid the warning replace static colstack_type *colstacks; by static colstack_type *colstacks = NULL; Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-12 16:06 Message: Logged In: YES user_id=421 Heiko, thank you very much for your patch. Two questions come to mind: - how does this patch interact with existing documents, i.e. what must be changed when using this patch? Obviously the use of \pdfliteral must be checked. Anything else? - does this collide with pdftex's use of the cm? The only use of the transformation matrix by pdftex I could find concerns magnifications, so that's most likely not a problem. Btw: gcc with -Wall -std=c99 gives this warning: ../../../../src/texk/web2c/pdftexdir/utils.c: In function ‘newcolorstack’: ../../../../src/texk/web2c/pdftexdir/utils.c:1366: warning: operation on ‘colstacks’ may be undefined ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=603&group_id=106

1 0

[ pdftex-Patches-603 ] Patch ColorStackTransformMatrix
by noreply＠sarovar.org 12 Sep '06

12 Sep '06

Patches item #603, was opened at 2006-09-07 10:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=603&group_id=106 >Category: Primitives Group: v1.40.0 Status: Open Resolution: None >Priority: 8 Submitted By: Heiko Oberdiek (oberdiek) >Assigned to: Martin Schröder (oneiros) Summary: Patch ColorStackTransformMatrix Initial Comment: Subject: Patch ColorStackTransformMatrix Date: 2006/09/07 Author: Heiko Oberdiek The patch is based on pdftex-1.40.0-beta-20060906 It tries to solve two FAQ problems: * missing color stack * wrong annotation rectangles (links, anchors) if the material was scaled or rotated. Files: ColorStackTransformMatrix.patch The patch, apply it in src/texk/web2c/pdftexdir: patch <ColorStackTransformMatrix.patch pdftex.def A modified version that uses the patch if the new primitives are found. A short test file: \documentclass{article} \usepackage{color} \usepackage{pdflscape} \usepackage{hyperref} \begin{document} \tableofcontents \section{Hello World} \label{sec:hello} \textcolor{blue}{Blue\newpage Blue} \begin{landscape} See \autoref{sec:hello}. \end{landscape} \end{document} Without the patch: * Text on first page before "Blue" is blue instead of black. * Text on second page is black instead of blue. * The link frame on page three is misplaced. With the patch and modified pdftex.def these things are fixed. New commands % color stack * \pdfcolorstackinit * \pdfcolorstack % matrix transformations * \pdfsetmatrix * \pdfsave * \pdfrestore Syntax: %% expandable commands: \pdfcolorstackinit [page] [direct] <general text> %% general commands: \pdfcolorstack <stack number> <stack action> <general text> \pdfsetmatrix \pdfsave \pdfrestore <stack action> ::= set | push | pop | current Description for color stack: This color stack implementation allows several independent stacks (upto 32686): * Stacks can be used for other properties than color, especially other graphics state parameters. * Several "text flows across pages" can be supported by color stacks. Example: footnotes. \pdfcolorstackinit [page] [direct] {<initial value>} A stack is initialized by \pdfcolorstackinit. It expands to the number of the new stack. The common case, the traditinal color stack is already initialized as first stack: \pdfcolorstackinit page direct {0 g 0 G} The keyword "page" means, that this stack is page based. At the start of the new page, the current stack value is automatically set: \textcolor{blue}{A\newpage B} The second page with "B" will start with blue setting. The keyword "direct" has the same meaning as "direct" for \pdfliteral. If the stack value is set, it is done by an equivalent of \pdfliteral direct {...}. The mandatory argument is the initial value on the stack. It should be the default at page start for the property, see PDF documentation. \pdfcolorstack <stack number> push {<new color>} pushes the current value on the stack and sets the <new color>. \pdfcolorstack <stack number> pop pops and sets the current stack value. \pdfcolorstack <stack number> current sets the current stack value without changing the stack. This is useful for stacks that are initialized without keyword "page". Thus the page start setting can be set manually. \pdfcolorstack <stack number> set {<new color>} The current value is set to <new color>. Example (changed pdftex.def): \chardef\GPT@colorstack=0 % \def\set@color{% \pdfcolorstack\GPT@colorstack push{\current@color}% \aftergroup\reset@color }% \def\reset@color{% \pdfcolorstack\GPT@colorstack pop\relax }% If someone wants to add color stack support for footnotes, the principle would be: \edef\stackfootnote{\pdfcolorstackinit direct{0 g 0 G}}% % Then at begin of the footnote area on the page: \pdfcolorstack\stackfoonote current\relax % During footnote processing the footnote stack is used: \let\GPT@colorstack\stackfoonote Description for matrix transformations: Currently matrix changes are done and hidden inside \pdfliteral nodes; pdfTeX doesn't parse its contents and does not know the new settings of the transform matrix. Thus the patch adds new primitives to save pdfTeX from parsing \pdfliteral contents and to notify pdfTeX about matrix changes to use them in calculating link and anchor positions. \pdfsetmatrix{<a> <c> <d>} is the equivalent to \pdfliteral{<a> <c> <d> 0 0 cm} \pdfsave is the equivalent to \pdfliteral{q} \pdfrestore is the equivalent to \pdfliteral{Q} Some remarks: * TeX already supports translations, thus the matrix is limited to four values for scaling and rotating. * There are some restrictions about \pdfsave and \pdfrestore: * They must be properly nested. * A pair must start and end in the same group at the same level. * A pair must start and end at the same position. Happily these restrictions are satisfied by the graphics package. Example (changed pdftex.def): \def\Grot@start{% \pdfsave \pdfsetmatrix{% \Grot@cos\space\Grot@sin\space \if-\Grot@sin\else-\Grot@sin\fi\space\Grot@cos }% \wd\z@\z@ }% \def\Grot@end{\pdfrestore} \def\Gscale@start{% \pdfsave \pdfsetmatrix{% \Gscale@x\space0 0 \Gscale@y }% }% Have fun Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-09-12 16:06 Message: Logged In: YES user_id=421 Heiko, thank you very much for your patch. Two questions come to mind: - how does this patch interact with existing documents, i.e. what must be changed when using this patch? Obviously the use of \pdfliteral must be checked. Anything else? - does this collide with pdftex's use of the cm? The only use of the transformation matrix by pdftex I could find concerns magnifications, so that's most likely not a problem. Btw: gcc with -Wall -std=c99 gives this warning: ../../../../src/texk/web2c/pdftexdir/utils.c: In function ‘newcolorstack’: ../../../../src/texk/web2c/pdftexdir/utils.c:1366: warning: operation on ‘colstacks’ may be undefined ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=603&group_id=106

1 0

[ pdftex-Patches-603 ] Patch ColorStackTransformMatrix
by noreply＠sarovar.org 07 Sep '06

07 Sep '06

Patches item #603, was opened at 2006-09-07 10:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=603&group_id=106 Category: None Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Patch ColorStackTransformMatrix Initial Comment: Subject: Patch ColorStackTransformMatrix Date: 2006/09/07 Author: Heiko Oberdiek The patch is based on pdftex-1.40.0-beta-20060906 It tries to solve two FAQ problems: * missing color stack * wrong annotation rectangles (links, anchors) if the material was scaled or rotated. Files: ColorStackTransformMatrix.patch The patch, apply it in src/texk/web2c/pdftexdir: patch <ColorStackTransformMatrix.patch pdftex.def A modified version that uses the patch if the new primitives are found. A short test file: \documentclass{article} \usepackage{color} \usepackage{pdflscape} \usepackage{hyperref} \begin{document} \tableofcontents \section{Hello World} \label{sec:hello} \textcolor{blue}{Blue\newpage Blue} \begin{landscape} See \autoref{sec:hello}. \end{landscape} \end{document} Without the patch: * Text on first page before "Blue" is blue instead of black. * Text on second page is black instead of blue. * The link frame on page three is misplaced. With the patch and modified pdftex.def these things are fixed. New commands % color stack * \pdfcolorstackinit * \pdfcolorstack % matrix transformations * \pdfsetmatrix * \pdfsave * \pdfrestore Syntax: %% expandable commands: \pdfcolorstackinit [page] [direct] <general text> %% general commands: \pdfcolorstack <stack number> <stack action> <general text> \pdfsetmatrix \pdfsave \pdfrestore <stack action> ::= set | push | pop | current Description for color stack: This color stack implementation allows several independent stacks (upto 32686): * Stacks can be used for other properties than color, especially other graphics state parameters. * Several "text flows across pages" can be supported by color stacks. Example: footnotes. \pdfcolorstackinit [page] [direct] {<initial value>} A stack is initialized by \pdfcolorstackinit. It expands to the number of the new stack. The common case, the traditinal color stack is already initialized as first stack: \pdfcolorstackinit page direct {0 g 0 G} The keyword "page" means, that this stack is page based. At the start of the new page, the current stack value is automatically set: \textcolor{blue}{A\newpage B} The second page with "B" will start with blue setting. The keyword "direct" has the same meaning as "direct" for \pdfliteral. If the stack value is set, it is done by an equivalent of \pdfliteral direct {...}. The mandatory argument is the initial value on the stack. It should be the default at page start for the property, see PDF documentation. \pdfcolorstack <stack number> push {<new color>} pushes the current value on the stack and sets the <new color>. \pdfcolorstack <stack number> pop pops and sets the current stack value. \pdfcolorstack <stack number> current sets the current stack value without changing the stack. This is useful for stacks that are initialized without keyword "page". Thus the page start setting can be set manually. \pdfcolorstack <stack number> set {<new color>} The current value is set to <new color>. Example (changed pdftex.def): \chardef\GPT@colorstack=0 % \def\set@color{% \pdfcolorstack\GPT@colorstack push{\current@color}% \aftergroup\reset@color }% \def\reset@color{% \pdfcolorstack\GPT@colorstack pop\relax }% If someone wants to add color stack support for footnotes, the principle would be: \edef\stackfootnote{\pdfcolorstackinit direct{0 g 0 G}}% % Then at begin of the footnote area on the page: \pdfcolorstack\stackfoonote current\relax % During footnote processing the footnote stack is used: \let\GPT@colorstack\stackfoonote Description for matrix transformations: Currently matrix changes are done and hidden inside \pdfliteral nodes; pdfTeX doesn't parse its contents and does not know the new settings of the transform matrix. Thus the patch adds new primitives to save pdfTeX from parsing \pdfliteral contents and to notify pdfTeX about matrix changes to use them in calculating link and anchor positions. \pdfsetmatrix{<a> <c> <d>} is the equivalent to \pdfliteral{<a> <c> <d> 0 0 cm} \pdfsave is the equivalent to \pdfliteral{q} \pdfrestore is the equivalent to \pdfliteral{Q} Some remarks: * TeX already supports translations, thus the matrix is limited to four values for scaling and rotating. * There are some restrictions about \pdfsave and \pdfrestore: * They must be properly nested. * A pair must start and end in the same group at the same level. * A pair must start and end at the same position. Happily these restrictions are satisfied by the graphics package. Example (changed pdftex.def): \def\Grot@start{% \pdfsave \pdfsetmatrix{% \Grot@cos\space\Grot@sin\space \if-\Grot@sin\else-\Grot@sin\fi\space\Grot@cos }% \wd\z@\z@ }% \def\Grot@end{\pdfrestore} \def\Gscale@start{% \pdfsave \pdfsetmatrix{% \Gscale@x\space0 0 \Gscale@y }% }% Have fun Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=603&group_id=106

1 0

Protrusion: Bug and feature suggestion
by Mark Henning 05 Sep '06

05 Sep '06

I think, there is a bug in the protrusion feature. Try this LATEX example (I used pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5) (preloaded format=pdflatex 2006.8.25), but other versions show this problem as well): \documentclass{article} \usepackage{microtype} \begin{document} \begin{itemize} \item --E\\--E\\--E \end{itemize} \end{document} The first "--E" is not protruded. This may be reasonable from pdfTeX's point of view, as it is not the beginning of a line due to the leading char printed by the \item command. Nevertheless, for the human reader it is the beginning of a line. Maybe there are more situations where this happens than the first line of an item in the itemize environment as shown in this example. While thinking about a way to solve this, I got an idea: What about a "general protrusion" feature which protrudes each character which is at the begin of a line or follows a horizontal space of any kind? (In analogy: apply the same to each character which is at the end of a line or is followed by a horizontal space.) This would solve any protrusion issues as for example the first indented line of a paragraph (already solved by another workaround), the above mentioned first line of an \item and all other similar situations, which are currently unknown. Furthermore, this would give a new feature, which could improve the look enormously: The protrusion feature levels out differences in the gray-intensity at the left or right side of characters. But for human eyes there is no difference between the first character of a line and the first character of a word. (The same is for the last character of a line and the last character of a word). This could make the spaces between the words of a line more equal, resulting in a better grayscale distribution over the line. This demonstrates what I mean (quick&dirty hack): \documentclass{article} \usepackage{microtype} \begin{document} This\hspace{.1cm}is\hspace{.1cm}just\hspace{.1cm}a\hspace{.1cm}demonstration\hspace{.1cm}for\hspace{.1cm}the\hspace{.1cm}general\hspace{.1cm}protrusion\hspace{.1cm}feature. \parbox[b]{\linewidth}{This\hspace{.1cm}% \parbox[b]{\linewidth}{is\hspace{.1cm}% \parbox[b]{\linewidth}{just\hspace{.1cm}% \parbox[b]{\linewidth}{a\hspace{.1cm}% \parbox[b]{\linewidth}{demonstration\hspace{.1cm}% \parbox[b]{\linewidth}{for\hspace{.1cm}% \parbox[b]{\linewidth}{the\hspace{.1cm}% \parbox[b]{\linewidth}{general\hspace{.1cm}% \parbox[b]{\linewidth}{protrusion\hspace{.1cm}% \parbox[b]{\linewidth}{feature.% }}}}}}}}}}%I know: Bad code; just ignore the warnings coming here... \end{document} Bis dann, - Mark -- Wir lieben die Grenzerfahrung. Und wenn's scharf ist. Und damit meinen wir *richtig* scharf. Und keine Zungenpuderei... www.chili-fraktion.de

1 0

Re: [NTG-pdftex] itshape in beta-20060829-2.2
by Akira Kakuto 04 Sep '06

04 Sep '06

> 2006/9/4, Akira Kakuto <kakuto(a)fsci.fuk.kindai.ac.jp>: > > Is the following example ok in Linux in beta-20060829 ? > > Works for me: Thanks. I think I've fixed the W32 bug. Best regards, Akira

1 0

itshape in beta-20060829-2.2
by Akira Kakuto 04 Sep '06

04 Sep '06

Hi, Is the following example ok in Linux in beta-20060829 ? \documentclass{article} \begin{document} \textit{This is a test.} \end{document} In W32TeX version, pdflatex crashes. Maybe that is a bug in W32 only. I will investigate ASAP. Thanks, Akira

2 1

[CTAN] pax v0.1
by Martin Schröder 04 Sep '06

04 Sep '06

---------- Forwarded message ---------- From: CTAN Announcements <ctan-ann(a)dante.de> Date: 03.09.2006 15:54 Subject: CTAN has a new package: pax v0.1 To: ctan-ann(a)dante.de On Sat, 26 Aug 2006, Heiko Oberdiek submitted a new package pax to CTAN. Location on CTAN: macros/latex/contrib/pax/ License: other (lppl/gpl) ----------------------------------------------------------- >From the README: | A. PROJECT PAX | ============== | | If PDF files are included using pdfTeX, PDF annotations | are stripped. This project tries a solution without | altering pdfTeX. A Java program (pax.jar) parses the PDF file that | will later be included. It writes the data of the annotations | in a file that can be read by TeX. Then a LaTeX package (pax.sty) | extends the graphics package. If a PDF file is included, the package | looks for the file with the annotation data, reads them and puts | the annotations in the right place. | | Project status: experimental -----------------------------------------------------------

3 2

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 03 Sep '06

03 Sep '06

Bugs item #304, was opened at 2005-03-02 17:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- >Comment By: Robert (schlcht) Date: 2006-09-03 17:30 Message: Logged In: YES user_id=2217 I've attached an example using Kepler MM (tfm+pfb included, please delete after testing). MM fonts are probably the only case where one would not want to use the autoexpand feature. At first sight, saying "autoexpand" or not doesn't seem to make a difference, since pdftex will always prefer existing expanded fonts (pfb) over autoexpanding them, anyway. However, there are some slight differences in the pdf. This is probably because the provided tfm file is different from the metrics that pdf calculates itself in the case of autoexpand. That is, autoexpand may result in a mismatch between the provided pfb and the calculated tfm, is that correct? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-01 19:02 Message: Logged In: YES user_id=929 currently i even can't get a test file do expansion at all without "autoexpand". E. g. Robert's example above, without "autoexpand", doesn't use expanded fonts. Maybe that's the reason for the missing expand parameter in the log? Can anybody provide a test file for this case? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 10:47 Message: Logged In: YES user_id=421 Is this really a problem, i.e. is there a reason _not_ to use the autoexpand feature in new documents? Hartmut, did you look into this bug? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-15 22:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 15:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 20:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\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 (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 01 Sep '06

01 Sep '06

Bugs item #304, was opened at 2005-03-02 18:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-01 21:02 Message: Logged In: YES user_id=929 currently i even can't get a test file do expansion at all without "autoexpand". E. g. Robert's example above, without "autoexpand", doesn't use expanded fonts. Maybe that's the reason for the missing expand parameter in the log? Can anybody provide a test file for this case? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:47 Message: Logged In: YES user_id=421 Is this really a problem, i.e. is there a reason _not_ to use the autoexpand feature in new documents? Hartmut, did you look into this bug? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-16 00:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 17:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 22:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\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 (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

[ pdftex-Bugs-465 ] font expansion & \lastlinefit
by noreply＠sarovar.org 01 Sep '06

01 Sep '06

Bugs item #465, was opened at 2006-01-03 19:05 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=465&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: font expansion & \lastlinefit Initial Comment: With \lastlinefit > 0, the last line will always be expanded to the maximum (except if it doesn't contain a glue). Furthermore, I wonder whether \lastlinefit should ideally also effect the expansion amount (ie., the last line of the first paragraph should be set in cmr10-25, since the preceding one is set in cmr10-50)? \tracingoutput1 \showboxbreadth\maxdimen \pdftracingfonts1 \pdfadjustspacing2 \pdffontexpand\font 50 50 10 autoexpand \lastlinefit500 \hsize=16cm \input tufte\par \bye, Robert ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-09-01 11:55 Message: Logged In: YES user_id=710 I should work on it and other bugs related to hz stuff, but I haven't found the time to reread relevant codes yet. Please be patient with me. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 10:48 Message: Logged In: YES user_id=421 Hartmut? Thanh? Anybody working on this? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=465&group_id=106

1 0

[ pdftex-Bugs-465 ] font expansion & \lastlinefit
by noreply＠sarovar.org 01 Sep '06

01 Sep '06

Bugs item #465, was opened at 2006-01-03 20:05 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=465&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: font expansion & \lastlinefit Initial Comment: With \lastlinefit > 0, the last line will always be expanded to the maximum (except if it doesn't contain a glue). Furthermore, I wonder whether \lastlinefit should ideally also effect the expansion amount (ie., the last line of the first paragraph should be set in cmr10-25, since the preceding one is set in cmr10-50)? \tracingoutput1 \showboxbreadth\maxdimen \pdftracingfonts1 \pdfadjustspacing2 \pdffontexpand\font 50 50 10 autoexpand \lastlinefit500 \hsize=16cm \input tufte\par \bye, Robert ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:48 Message: Logged In: YES user_id=421 Hartmut? Thanh? Anybody working on this? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=465&group_id=106

1 0

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 01 Sep '06

01 Sep '06

Bugs item #304, was opened at 2005-03-02 18:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:47 Message: Logged In: YES user_id=421 Is this really a problem, i.e. is there a reason _not_ to use the autoexpand feature in new documents? Hartmut, did you look into this bug? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-16 00:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 17:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 22:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\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 (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

[ pdftex-Bugs-600 ] \pdfdraftmode: results in segfault + can be tricked
by noreply＠sarovar.org 01 Sep '06

01 Sep '06

Bugs item #600, was opened at 2006-08-23 23:51 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106 Category: None Group: v1.40.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: \pdfdraftmode: results in segfault + can be tricked Initial Comment: The following gives a segfault here (under cygwin): \pdfdraftmode=1 \immediate\pdfobj{x} %\pdfoutline goto name{x}{y} % with this, too \pdfcompresslevel=9 A \bye >From the terminal: This is pdfTeXk, Version 3.141592-1.40.0-beta-20060822 (Web2C 7.5.5) %&-line parsing enabled. entering extended mode (./bugs.tex [1{/cygdrive/c/Programme/TeXLive/texmf-var/fonts/map/pdftex/updmap/ pdftex.map} 133 [main] pdftex 1780 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) Also, the following will create a pdf file, although it shouldn't (or at least issue a warning about \pdfdraftmode being issued too late): \immediate\pdfobj{x} \pdfdraftmode=1 A \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-29 23:02 Message: Logged In: YES user_id=421 Updated patch that also gives an error in the case of a late \pdfdraftmode=1 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-29 22:43 Message: Logged In: YES user_id=421 Thanks. The attached patch fixes at least the crash. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106

1 0

[ pdftex-Bugs-481 ] "This can't happen (flushing)" with extra kerning+expansion+ligatures
by noreply＠sarovar.org 01 Sep '06

01 Sep '06

Bugs item #481, was opened at 2006-02-13 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=481&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) >Summary: "This can't happen (flushing)" with extra kerning+expansion+ligatures Initial Comment: With the following test file, pdftex will abort with "This can't happen (flushing)": \pdfadjustspacing=1 \pdffontexpand\font 20 20 4 autoexpand \pdfappendkern=1 \knaccode\font`i=100 \hsize10em foo fii foo foo foo foo % but this works: %foo f{}ii foo foo foo foo \bye Hartmut's analysis was: ----------------------------------- FWIW, this happens in function do_subst_font(). But it starts with auto_expand_kern(), where the given kern indeed is appended to the i of "fi" and also to the 2nd "i". It seems as if at this time "fi" is not yet seen as a ligature. Then in do_subst_font() the "fi" is somehow already a ligature, and now the kern is part of the lig_ptr list (which is wrong). Then font(r) is recursively changed to 51, the expanded font number, and so the kern, which should not be in this list, gets the 51 as its type. But it must be 11 for a kern. Maybe a change should be that the kern does not end up in the lig_ptr list, but should come after the "fi" ligature. No idea, how. ----------------------------------- ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:43 Message: Logged In: YES user_id=421 Is anybody working on this? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-02-13 21:25 Message: Logged In: YES user_id=929 My text above had a typo, sorry. Before you start searching... it's auto_append_kern(), not auto_expand_kern(). Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=481&group_id=106

1 0

[ pdftex-Bugs-600 ] \pdfdraftmode: results in segfault + can be tricked
by noreply＠sarovar.org 29 Aug '06

29 Aug '06

Bugs item #600, was opened at 2006-08-23 23:51 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106 Category: None Group: v1.40.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: \pdfdraftmode: results in segfault + can be tricked Initial Comment: The following gives a segfault here (under cygwin): \pdfdraftmode=1 \immediate\pdfobj{x} %\pdfoutline goto name{x}{y} % with this, too \pdfcompresslevel=9 A \bye >From the terminal: This is pdfTeXk, Version 3.141592-1.40.0-beta-20060822 (Web2C 7.5.5) %&-line parsing enabled. entering extended mode (./bugs.tex [1{/cygdrive/c/Programme/TeXLive/texmf-var/fonts/map/pdftex/updmap/ pdftex.map} 133 [main] pdftex 1780 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) Also, the following will create a pdf file, although it shouldn't (or at least issue a warning about \pdfdraftmode being issued too late): \immediate\pdfobj{x} \pdfdraftmode=1 A \bye ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-08-29 23:02 Message: Logged In: YES user_id=421 Updated patch that also gives an error in the case of a late \pdfdraftmode=1 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-29 22:43 Message: Logged In: YES user_id=421 Thanks. The attached patch fixes at least the crash. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106

1 0

[ pdftex-Bugs-600 ] \pdfdraftmode: results in segfault + can be tricked
by noreply＠sarovar.org 29 Aug '06

29 Aug '06

Bugs item #600, was opened at 2006-08-23 23:51 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106 Category: None Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) >Assigned to: Martin Schröder (oneiros) Summary: \pdfdraftmode: results in segfault + can be tricked Initial Comment: The following gives a segfault here (under cygwin): \pdfdraftmode=1 \immediate\pdfobj{x} %\pdfoutline goto name{x}{y} % with this, too \pdfcompresslevel=9 A \bye >From the terminal: This is pdfTeXk, Version 3.141592-1.40.0-beta-20060822 (Web2C 7.5.5) %&-line parsing enabled. entering extended mode (./bugs.tex [1{/cygdrive/c/Programme/TeXLive/texmf-var/fonts/map/pdftex/updmap/ pdftex.map} 133 [main] pdftex 1780 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) Also, the following will create a pdf file, although it shouldn't (or at least issue a warning about \pdfdraftmode being issued too late): \immediate\pdfobj{x} \pdfdraftmode=1 A \bye ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-08-29 22:43 Message: Logged In: YES user_id=421 Thanks. The attached patch fixes at least the crash. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106

1 0

pdfximage
by Hans Hagen 29 Aug '06

29 Aug '06

Hi, It's kind of annoying that pdftex has hard coded suffixes. how about something \pdfjpgsuffixes{jpg,jpeg,myjpg} \pdfpngsuffixes{png,somepng} \pdfpdfsuffixes{pdf,epdf,fdf} 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 8

[ pdftex-Bugs-600 ] \pdfdraftmode: results in segfault + can be tricked
by noreply＠sarovar.org 23 Aug '06

23 Aug '06

Bugs item #600, was opened at 2006-08-23 21:51 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106 Category: None Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: \pdfdraftmode: results in segfault + can be tricked Initial Comment: The following gives a segfault here (under cygwin): \pdfdraftmode=1 \immediate\pdfobj{x} %\pdfoutline goto name{x}{y} % with this, too \pdfcompresslevel=9 A \bye >From the terminal: This is pdfTeXk, Version 3.141592-1.40.0-beta-20060822 (Web2C 7.5.5) %&-line parsing enabled. entering extended mode (./bugs.tex [1{/cygdrive/c/Programme/TeXLive/texmf-var/fonts/map/pdftex/updmap/ pdftex.map} 133 [main] pdftex 1780 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) Also, the following will create a pdf file, although it shouldn't (or at least issue a warning about \pdfdraftmode being issued too late): \immediate\pdfobj{x} \pdfdraftmode=1 A \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106

1 0

1.40.0-beta-20060822
by Martin Schröder 22 Aug '06

22 Aug '06

http://sarovar.org/download.php/1066/pdftex-1.40.0-beta-20060822.tar.bz2 http://sarovar.org/download.php/1067/pdftex-1.40.0-beta-20060811-20060822.d… --------------------------------------------------------------- pdfTeX 3.141592-1.40.0-beta-20060822 was released on 2006-08-22 --------------------------------------------------------------- - new feature: with \pdfdraftmode=1 (or -draftmode) pdfTeX doesn't write an output pdf file and doesn't read the content of any image file, thus speeding up the run. This is usefull when you know you need another run of pdfTeX e.g. just to get all the references right, but don't care for the output of this run - changed the format of pdfTeX warnings and unified the four(!) functions pdfTeX uses for writing out errors and warnings - expanded the output of -version to include information about the libraries used - fixed a bug where -20060811 would loop forever - fixed some compilation problems with obsdcompat Have fun Martin

2 2

[ pdftex-Bugs-592 ] TrueType Font can't be embedded
by noreply＠sarovar.org 22 Aug '06

22 Aug '06

Bugs item #592, was opened at 2006-08-08 13:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106 Category: Fonts Group: v1.30.0 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael (takrl) Assigned to: Martin Schröder (oneiros) Summary: TrueType Font can't be embedded Initial Comment: I tried to embed a TTF in my PDF document (have done so before 100s of times, so I know the general proceedings). However, this is a new MS font (constantia), and pdf(e)tex doesn't seem to support it. Excerpt of the log file: This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5) entering extended mode <snip> [1{psfonts.map}] (ttftest.aux) ) (see the transcript file for additional information){T1-WGL4.enc}<constani.ttf Error: (file constani.ttf): unknown verssion of OS/2 table (0003) ==> Fatal error occurred, the output PDF file is not finished! >From what I saw so far on the net (for example, at http://partners.adobe.com/public/developer/opentype/index_os2.html ) this is the newest version of the font specification, and pdf(e)tex does only seem to support fonts using OS/2-table-versions lower than 3. ---------------------------------------------------------------------- >Comment By: Michael (takrl) Date: 2006-08-22 20:15 Message: Logged In: YES user_id=3803 Thanks for the hints. These may prove useful in 'real life'... ;-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-22 18:22 Message: Logged In: YES user_id=421 Thanks, the testcase helped. It can be simplified: Put all input files in one directory and instead of a separate mapfile use \pdfmapline. Then you don't need to fiddle with paths and mapfiles. ---------------------------------------------------------------------- Comment By: Michael (takrl) Date: 2006-08-09 11:03 Message: Logged In: YES user_id=3803 Ok, I just made up a zip file containing test data and attached it here... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-08 13:50 Message: Logged In: YES user_id=421 I've changed that line to if (version > 3) Michael, can you please attach a complete test case (all needed inputs) to this bug report for future testing? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-08-08 13:17 Message: Logged In: YES user_id=710 >From an email from Eddie Kohler: ================================================= (2) Otftotfm generates map lines that tell pdftex to embed the TTF directly (cool!). Unfortunately, pdftex does not like the Version 3.0 OS/2 table included in OpenType TTFs (boo!), so I hacked the font to change the OS/2 version number to 2.0. Alternately, one could recompile pdftex, after changing line 1026 of writettf.c to: if (version != 0x0000 && version != 0x0001 && version != 0x0002 && version != 0x0003) ================================================= Martin, can you please include this patch into the next release? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106

1 0

[ pdftex-Bugs-592 ] TrueType Font can't be embedded
by noreply＠sarovar.org 22 Aug '06

22 Aug '06

Bugs item #592, was opened at 2006-08-08 13:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106 Category: Fonts Group: v1.30.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael (takrl) >Assigned to: Martin Schröder (oneiros) Summary: TrueType Font can't be embedded Initial Comment: I tried to embed a TTF in my PDF document (have done so before 100s of times, so I know the general proceedings). However, this is a new MS font (constantia), and pdf(e)tex doesn't seem to support it. Excerpt of the log file: This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5) entering extended mode <snip> [1{psfonts.map}] (ttftest.aux) ) (see the transcript file for additional information){T1-WGL4.enc}<constani.ttf Error: (file constani.ttf): unknown verssion of OS/2 table (0003) ==> Fatal error occurred, the output PDF file is not finished! >From what I saw so far on the net (for example, at http://partners.adobe.com/public/developer/opentype/index_os2.html ) this is the newest version of the font specification, and pdf(e)tex does only seem to support fonts using OS/2-table-versions lower than 3. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-08-22 18:22 Message: Logged In: YES user_id=421 Thanks, the testcase helped. It can be simplified: Put all input files in one directory and instead of a separate mapfile use \pdfmapline. Then you don't need to fiddle with paths and mapfiles. ---------------------------------------------------------------------- Comment By: Michael (takrl) Date: 2006-08-09 11:03 Message: Logged In: YES user_id=3803 Ok, I just made up a zip file containing test data and attached it here... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-08 13:50 Message: Logged In: YES user_id=421 I've changed that line to if (version > 3) Michael, can you please attach a complete test case (all needed inputs) to this bug report for future testing? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-08-08 13:17 Message: Logged In: YES user_id=710 >From an email from Eddie Kohler: ================================================= (2) Otftotfm generates map lines that tell pdftex to embed the TTF directly (cool!). Unfortunately, pdftex does not like the Version 3.0 OS/2 table included in OpenType TTFs (boo!), so I hacked the font to change the OS/2 version number to 2.0. Alternately, one could recompile pdftex, after changing line 1026 of writettf.c to: if (version != 0x0000 && version != 0x0001 && version != 0x0002 && version != 0x0003) ================================================= Martin, can you please include this patch into the next release? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=592&group_id=106

1 0

[ pdftex-Patches-597 ] Patch for more structured font writing
by noreply＠sarovar.org 22 Aug '06

22 Aug '06

Patches item #597, was opened at 2006-08-20 16:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=597&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: Patch for more structured font writing Initial Comment: Now there are individual structures for font dictionaries and font descriptors. Several font objects can share the same descriptor structure. All structures are registered in AVL trees and flushed at the end. The fm_entry structure is cleaned up, now contains mostly map related stuff. Font descriptors can be shared also by embedded PDF files. tfm_of_fm() is gone. New makesubsettag() based on md5sum() with collision detection. Written encoding vectors are minimized in size (try it out on pdftex-t.tex :-) Replacement of Type1 fonts from embedded files seems to work. TrueType writing not yet done, currently broken. Help appreciated! More see readme.pdf included in patch .tar file. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-08-22 08:19 Message: Logged In: YES user_id=929 the patch doesn't fit to the TrueType model, needs more consideration... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=597&group_id=106

1 0

pdftex release?
by karl＠freefriends.org 21 Aug '06

21 Aug '06

Hi folks, I was wondering if there was any (even vague) ETA for the next release of pdftex. Not trying to push for one, I'm happy for TL06 to go out with the current release (and I have no clue yet when TL06 will be anywhere near ready). But if a new release is in the works anyway, that'd be good to know. Thanks, Karl

2 1

[ pdftex-Patches-597 ] Patch for more structured font writing
by noreply＠sarovar.org 20 Aug '06

20 Aug '06

Patches item #597, was opened at 2006-08-20 16:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=597&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: Patch for more structured font writing Initial Comment: Now there are individual structures for font dictionaries and font descriptors. Several font objects can share the same descriptor structure. All structures are registered in AVL trees and flushed at the end. The fm_entry structure is cleaned up, now contains mostly map related stuff. Font descriptors can be shared also by embedded PDF files. tfm_of_fm() is gone. New makesubsettag() based on md5sum() with collision detection. Written encoding vectors are minimized in size (try it out on pdftex-t.tex :-) Replacement of Type1 fonts from embedded files seems to work. TrueType writing not yet done, currently broken. Help appreciated! More see readme.pdf included in patch .tar file. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=597&group_id=106

1 0