- ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-427 ] Character positioning patch
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #427, was opened at 2005-09-11 12:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106 Category: Positioning >Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hans Hagen (hagen) Summary: Character positioning patch Initial Comment: Experimental patch increases resolution of /Widths array by 1 fractional digit, makes corrections of type ")-1(" and ")1(" in the TJ array happen much less often, particularily for CM fonts. Gives e. g. 1 % PDF file size shrink for pdfetex web sources compiled into PDF. Rough patch only, not for production. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:06 Message: Logged In: YES user_id=929 Patch extended: Now pdf_set_origin has (h, v) parameters, simplifies pdf_begin_text procedure. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 00:25 Message: Logged In: YES user_id=929 Removed pdf_first_space_corr variable, as it seems that it was defunct anyway: There was no pdf_end_string procedure call (only place where something is done with pdf_first_space_corr), where afterwards the pdf_h variable (then modified by pdf_first_space_corr) would actually be used. E. g. pdf_moveto uses pdf_last_h instead, and after pdf_end_text there is anyway a pdf_set_origin call. And pdf_begin_string gets simpler. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-03 01:16 Message: Logged In: YES user_id=929 patch updated: now the TJ array building in procedure pdf_begin_string is simplified/tidied up. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106

1 0

[ pdftex-Patches-415 ] various extensions and fixes
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #415, was opened at 2005-08-19 09:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106 Category: Primitives >Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: various extensions and fixes Initial Comment: This is a patch for various experimental extensions: - \pdfinsertht: return the height of an insert (requested by Hans); this has similar syntax to \pdftexrevision. - do not fail when \pdfobj is used with an invalid object number (requested by Hans) - snapping: support for grid typesetting -- see snap.txt for details - kern before space: allow changing interword glues in a flexible way and inserting a kern before certain characters -- see kern-before-interword-glue.txt for details The notes in snap.txt and kern-before-interword-glue.txt are from email correspondence with people interested in; hence these notes are somewhat informal, inaccurate or out-of-date. How to apply: ~~~~~~~~~~~~~ cd /path/to/pdftex-1.30.0-srcdir/src/texk patch -p1 < /path/to/pdftex-20050818.patch cd web2c make pdfetex ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-09-04 18:22 Message: Logged In: YES user_id=421 The patch for invalid object numbers is included in 1.30.1++ ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106

1 0

[ pdftex-Patches-416 ] new primitive pdflastlink
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #416, was opened at 2005-08-19 09:42 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106 Category: Primitives >Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Ralf Utermann (ralfu) Assigned to: Hartmut Henkel (hhenkel) Summary: new primitive pdflastlink Initial Comment: This patch implements a new primitive \pdflastlink (analogous to \pdflastannot) which returns the object number of the last object created with \pdfstartlink. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106

1 0

[ pdftex-Patches-386 ] grow obj_tab and dest_names arrays dynamically
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #386, was opened at 2005-07-10 20:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=386&group_id=106 Category: Memory allocation >Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: grow obj_tab and dest_names arrays dynamically Initial Comment: experimental patch to grow the obj_tab and dest_names arrays dynamically; arrays initially have 1000 entries. This required also update of file avlstuff.c. Similar to patch-366, which did this already for the pdf_mem array. Then all (?) pdftex-specific memory configuration parameters, obj_tab_size, dest_names_size, and pdf_mem_size in texmf.cnf would be ignored. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=386&group_id=106

1 0

[ pdftex-Patches-462 ] HZ font expansion by text matrix manipulation
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #462, was opened at 2005-12-23 23:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106 Category: Positioning Group: v1.40.0 Status: Open >Resolution: Later Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: HZ font expansion by text matrix manipulation Initial Comment: Use textmatrix Tm instead of /FontMatrix for font expansion. Then a font file will be embedded only once for all expansion factors. Gives smaller PDF files. Works then also for non-embedded fonts. TrueType not tried yet. Rough patch only, incomplete, work in progress, no warranty, not for production. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 19:41 Message: Logged In: YES user_id=421 The last word from Hartmut was that it's not ready yet and he'd be working on an improved version. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-02-13 19:05 Message: Logged In: YES user_id=2217 Will this make it into 1.40? I would love to see it included. I've tested it a bit and did not find any problems (I'm also using it for the pre-built microtype documentation on CTAN). Regards, Robert ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106

1 0

[ pdftex-Bugs-488 ] In pdfLaTeX Turkish babel won't work with graphicx package
by noreply＠sarovar.org 24 Feb '06

24 Feb '06

Bugs item #488, was opened at 2006-02-24 06:42 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=488&group_id=106 Category: Image inclusion Group: None >Status: Closed >Resolution: Rejected >Priority: 2 Submitted By: Nerhun YILDIZ (nerhun) Assigned to: Martin Schröder (oneiros) Summary: In pdfLaTeX Turkish babel won't work with graphicx package Initial Comment: I use Turkish bible in MiKTeX 2.4. When I use graphics or graphicx package and pdfLaTeX my document it crashes with about 30 errors. There is no difficulty in LaTeXing the same document and processing DVI instead of PDF. Here is the piece of minimal LaTeX code that crashes: \documentclass{report} \usepackage[turkish]{babel} \usepackage{graphicx} \begin{document} \end{document} ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-02-24 13:53 Message: Logged In: YES user_id=421 Closed, as this is a LaTeX/babel/pdftex.def problem. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2006-02-24 11:26 Message: Logged In: YES user_id=1276 Hello, Turkish.ldf makes '=' active that will break many packages. Graphicx loads pdftex.def and pdftex.def loads supp-pdf.tex delayed (\AtBeginDocument) that loads supp-mis.tex that relies on '=' with catcode 12 instead of an active one. Babel makes '=' active \AtBeginDocument. Because babel is loaded first, '=' is made active before supp-mis.tex is loaded. Solutions: * Other order of packages: \usepackage{graphicx} \usepackage[turkish]{babel} * Fixing the catcode for stuff that is loaded \AtBeginDocument between babel and document start: \usepackage[turkish]{babel} \AtBeginDocument{\shorthandoff{=}}% right after babel \usepackage{graphicx} ... \AtBeginDocument{\shorthandon{=}}% % right before \begin{document} \begin{document} * Also I have updated pdftex.def to 0.03o in order to catch some catcode problems. The bug is related to the choice of '=' as shorthand character in turkish.ldf. It is definitly no matter of pdfTeX, thus the bug can be closed here. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=488&group_id=106

1 0

[ pdftex-Bugs-488 ] In pdfLaTeX Turkish babel won't work with graphicx package
by noreply＠sarovar.org 24 Feb '06

24 Feb '06

Bugs item #488, was opened at 2006-02-24 06:42 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=488&group_id=106 Category: Image inclusion Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nerhun YILDIZ (nerhun) Assigned to: Martin Schröder (oneiros) Summary: In pdfLaTeX Turkish babel won't work with graphicx package Initial Comment: I use Turkish bible in MiKTeX 2.4. When I use graphics or graphicx package and pdfLaTeX my document it crashes with about 30 errors. There is no difficulty in LaTeXing the same document and processing DVI instead of PDF. Here is the piece of minimal LaTeX code that crashes: \documentclass{report} \usepackage[turkish]{babel} \usepackage{graphicx} \begin{document} \end{document} ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2006-02-24 11:26 Message: Logged In: YES user_id=1276 Hello, Turkish.ldf makes '=' active that will break many packages. Graphicx loads pdftex.def and pdftex.def loads supp-pdf.tex delayed (\AtBeginDocument) that loads supp-mis.tex that relies on '=' with catcode 12 instead of an active one. Babel makes '=' active \AtBeginDocument. Because babel is loaded first, '=' is made active before supp-mis.tex is loaded. Solutions: * Other order of packages: \usepackage{graphicx} \usepackage[turkish]{babel} * Fixing the catcode for stuff that is loaded \AtBeginDocument between babel and document start: \usepackage[turkish]{babel} \AtBeginDocument{\shorthandoff{=}}% right after babel \usepackage{graphicx} ... \AtBeginDocument{\shorthandon{=}}% % right before \begin{document} \begin{document} * Also I have updated pdftex.def to 0.03o in order to catch some catcode problems. The bug is related to the choice of '=' as shorthand character in turkish.ldf. It is definitly no matter of pdfTeX, thus the bug can be closed here. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=488&group_id=106

1 0

[ pdftex-Bugs-488 ] In pdfLaTeX Turkish babel won't work with graphicx package
by noreply＠sarovar.org 24 Feb '06

24 Feb '06

Bugs item #488, was opened at 2006-02-24 07:42 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=488&group_id=106 Category: Image inclusion Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nerhun YILDIZ (nerhun) Assigned to: Martin Schröder (oneiros) Summary: In pdfLaTeX Turkish babel won't work with graphicx package Initial Comment: I use Turkish bible in MiKTeX 2.4. When I use graphics or graphicx package and pdfLaTeX my document it crashes with about 30 errors. There is no difficulty in LaTeXing the same document and processing DVI instead of PDF. Here is the piece of minimal LaTeX code that crashes: \documentclass{report} \usepackage[turkish]{babel} \usepackage{graphicx} \begin{document} \end{document} ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=488&group_id=106

1 0

pdftex-1.40.0-beta-20060213 glitches for -std=c99 in utils.c
by George N. White III 23 Feb '06

23 Feb '06

On SGI Irix using MipsPro compilers, pdftexdir/utils.c fails to compile. DBL_EPSILON was not defined (it is defined in float.h). In line 729, ";" should be ",". The following patch was "tested" (e.g., "pdftex story" seems to work) on Irix and i686 debian linux with -std=c99 to get snprint: gwhite@guth3: ~/W/TeX/src/pdftex-1.40.0-beta-20060213 $ nm i686-linux/texk/web2c/pdftexdir/utils.o | fgrep snprintf U snprintf U vsnprintf *** utils.c.orig Fri Jan 20 21:56:17 2006 --- utils.c Wed Feb 22 15:34:23 2006 *************** *** 32,37 **** --- 32,38 ---- #include <kpathsea/c-fopen.h> #include <string.h> #include <time.h> + #include <float.h> /* for DBL_EPSILON */ /*@unused@*/ static const char perforce_id[] = *************** *** 726,732 **** j = 0; for (i = 0; i < lin; i++) { #if defined (__STDC_VERSION__) && __STDC_VERSION__ >=199901L ! snprintf (buf, sizeof (buf); #else sprintf (buf, #endif --- 727,733 ---- j = 0; for (i = 0; i < lin; i++) { #if defined (__STDC_VERSION__) && __STDC_VERSION__ >=199901L ! snprintf (buf, sizeof (buf), #else sprintf (buf, #endif -- George N. White III <aa056(a)chebucto.ns.ca> Head of St. Margarets Bay, Nova Scotia

2 1

[ pdftex-Feature Requests-385 ] \pdfnoligatures should leave kerning intact
by noreply＠sarovar.org 20 Feb '06

20 Feb '06

Feature Requests item #385, was opened at 2005-07-10 17:38 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=385&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: \pdfnoligatures should leave kerning intact Initial Comment: % The new \ptexnoligatures primitive will break the % horizontal positioning of \mathaccents if the base % character is slanted. % There is no problem with \accent, nor with \mathaccent % on upright characters: $\dot{A} \dot{\rm{A}} \dot{\Delta} \dot{\mit\Delta}$ {\tenit \accent'137 A} \ptexnoligatures\tenit % OK \ptexnoligatures\textfont0 % = cmr10, \rm % OK \ptexnoligatures\textfont1 % = cmmi10, \mit % breaks shift $\dot{A} \dot{\rm{A}} \dot{\Delta} \dot{\mit\Delta}$ {\tenit \accent'137 A} \bye, Robert ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2006-02-20 17:50 Message: Logged In: YES user_id=1608 Maybe we should just document the weird behaviour then and keep the thing marked experimental? I do not have lots of time to spend on this hack right now, nor do I want to, since everything I do now will have to be thrown out again for version 1.50. The change file that is attached to this feature item can then be ignored, except for that one line that re-enables \tagcode. ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-20 17:32 Message: Logged In: YES user_id=3344 Looking at Taco's change file, it should be possible to break his "non-vmode fix" by inserting \vbox{\pdfnoligatures\font} or \vadjust{\pdfligatures\font} in hmode. A final fix is to reimplement this \pdfnoligatures primitive: Either do not only change the |tag| field in the char_info for all font glyphs, but remove the ligs from the lig/kern program. Or save the information that no ligature should be constructed within the hlist (using a special node to start and end the nolig part similar to the setlanguage whatsit nodes or by adding the nolig flag to the character nodes). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-02-20 16:40 Message: Logged In: YES user_id=2217 Ah, I didn't realize it had such confusing effects. However, I still believe that disallowing it in non-vmode is too restrictive. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-20 09:56 Message: Logged In: YES user_id=1608 But it is not global for the current paragraph, it is only applied to words that are looked at for hyphenation. Try this test, and have a close look at the first and third word of the paragraph. There are even stranger possibilities when \language is taken into account. \font\tst=cmr10 \hsize=2in \noindent \tst efficiency efficiency \hbox{efficiency} \pdfnoligatures\tst efficiency efficiency efficiency \bye ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-02-19 19:19 Message: Logged In: YES user_id=2217 In my opinion, this latest patch is too restrictive. It should be sufficient to document \pdfnoligatures as one of those commands whose scope is global to the current paragraph (and the rest of the document), just like setting, say, \hyphenpenalty or \hsize in the middle of a paragraph affects the complete paragraph. The current behaviour is also consistent with that of the hz-related stuff: \rpcode and friends have a retroactive effect, too. (Besides, the patch would break microtype.sty, which sets up the fonts as they are being loaded, which would happen in horizontal mode, mostly... ;-) PS. If it was for me, this feature request could be closed; I totally accept the "known limitation". ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-15 10:58 Message: Logged In: YES user_id=1608 The attached patch disallows \pdfnoligatures and \tagcode in non-vmodes, and restores the assignment functionality of \tagcode (that was an unrelated bug in 1.40-beta) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-15 10:17 Message: Logged In: YES user_id=1608 We can disallow the primitive in non-vertical mode. Makes sense. ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-15 10:10 Message: Logged In: YES user_id=3344 Another limitation which should be documented: If \ptexnoligatures<font> is applied within a paragraph, the ligs and kerns created and inserted before this command are removed depending if a hyphenation pass is necessary to justify the paragraph. \ptexnoligatures<font> has the _global_ side effect to suppress all ligs and kerns of the font which are created _afterwards in time_. TeX breaks the lines of a paragraph at the end of the paragraph. If hyphenation has to be applied, ligs are remapped to single chars, (implicit) kerns are removed ... and reconstituted afterwards using the font information valid at this (later) time. If the font info is changed in between, which is true if \ptexnoligatures<font> is applied, already inserted ligs and kerns are removed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-12 22:23 Message: Logged In: YES user_id=421 Changing this into a feature request. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-07-10 18:50 Message: Logged In: YES user_id=1608 This is because it (\ptexnoligatures) also disables the kerning information for the font. You'll have to accept that as a "known limitation" for now. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=385&group_id=106

1 0