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

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

[ 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 15: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: Robert (schlcht) Date: 2006-02-20 15: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 08: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 18: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 09: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 09: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 09:10 Message: Logged In: YES user_id=3344 Another limitation which should be documented: If \ptexnoligatures 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 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 is applied, already inserted ligs and kerns are removed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-12 20:23 Message: Logged In: YES user_id=421 Changing this into a feature request. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-07-10 16: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

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

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

19 Feb '06

Feature Requests item #385, was opened at 2005-07-10 15: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: \ptexnoligatures 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: Robert (schlcht) Date: 2006-02-19 18: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 09: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 09: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 09:10 Message: Logged In: YES user_id=3344 Another limitation which should be documented: If \ptexnoligatures 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 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 is applied, already inserted ligs and kerns are removed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-12 20:23 Message: Logged In: YES user_id=421 Changing this into a feature request. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-07-10 16: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

[ pdftex-Patches-93 ] \quitvmode
by noreply＠sarovar.org 19 Feb '06

19 Feb '06

Patches item #93, was opened at 2004-07-15 10:12 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=93&group_id=106 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: \quitvmode Initial Comment: The change file adds a new primitive called \quitvmode. In vertical modes, it is identical to \indent, but in horizontal and math modes it is \noindent. See http://www.metatex.org/web/quitvmode.html ---------------------------------------------------------------------- >Comment By: Hans Hagen (hagen) Date: 2006-02-14 14:01 Message: Logged In: YES user_id=927 the original name was \dontleavehmode (kind of counterpart of \leavevmode) but taco cooked up the \quitvmode name (in my opinion \leavevmode often does more harm than good -) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-14 12:20 Message: Logged In: YES user_id=1608 http://www.metatex.org/web/quitvmode.html Bernd, this is a repository for patches. Discussion normally takes place on the ntg-pdftex mailing list, not here. Cheers, Taco ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 12:02 Message: Logged In: YES user_id=3344 IMHO the name should include a \...indent to be consistent with the existing \indent/\noindent, if this primitive has similar functionality. And why not using a macro solution? (This means that I ask to please add a small rationale when introducing new primitives.) \def\quitvmode{% \ifvmode \indent \else \noindent \fi} If I make this a \protected\def (using e-\TeX) this will also cover the cases where TeX is looking ahead and expanding tokens (i.e., inside alignments looking for \omit, \span etc.). Is there any unseen advantage of the new primitive not covered by this macro resp. plain's \leavevmode macro? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-13 14:42 Message: Logged In: YES user_id=421 This has been included in 1.21a ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=93&group_id=106

9 22

do we need pdfTeXk?
by Hartmut Henkel 17 Feb '06

17 Feb '06

TeXk is there since it is a modified TeX and therefore (i guess) it had to be given a different name. Does a similar formal or other reason exist for pdfTeXk vs. pdfTeX? If not, we could change all "pdfTeXk" containing messages to "pdfTeX", as done already with the "e". The various "k" features, like "%&-line parsing enabled." are anyway individually flagged at program start. Regards, Hartmut

3 2

hash in \pdfescapestring
by Paweł Jackowski 16 Feb '06

16 Feb '06

Heiko, \pdfescapestring{#} returns doubled hash of category 12. Is that ok? I mean if it was two hashes in category 6 it wouldn't that strange, but all the characters returned by \pdfescape* are \other. So I think the result for \pdfescapestring{#} should be just one hash of cat 12. ? pdftex-1.40.0-beta-20060213 -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

3 5

Roadmap
by Martin Schröder 15 Feb '06

15 Feb '06

Hi, this weekend I've met Hans, Hartmut and Taco in Schwetzingen (we attended the christmas party of the Darmstadt TeXies with Hermann Zapf) and we discussed the status and future of pdfTeX. We came down with this "roadmap": 1.40 (200603): - all the current patches plus \primitive et.al - cleanup the code (fewer patchfiles) to have a better starting point for lua - move project to Gforge hosted by Fabrice, and setup a complete code repository there - start of "pdfTeX news" 1.50 - more bits, i.e. use more than 16 (and enough) where possible 1.60 or later - general map file handling for pdfTeX and all programs that use map files - OpenType -- this requires more bits and can be done in steps - lua -- integration can be done post 1.40, but the TeX<->Lua interface needs much testing and developement, so lua will stay experimental for quite some time sometime (i.e. whenever it's ready) - tagged pdf - merging hyperlinks in included documents Best Martin -- http://www.tm.oneiros.de

10 68

[ pdftex-Patches-469 ] \currentexpansionmode + \ifalignscanning - \ifinedef
by noreply＠sarovar.org 15 Feb '06

15 Feb '06

Patches item #469, was opened at 2006-01-12 02:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=469&group_id=106 Category: Primitives Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: Morten Høgholm (morten) Assigned to: The Thanh Han (hanthethanh) Summary: \currentexpansionmode + \ifalignscanning - \ifinedef Initial Comment: Here's a patch made against pdftex-1.40.0-alpha-20060111. It removes the \ifinedef primitive for a different primitive, namely \currentexpansionmode. This read-only register is 0 when doing regular typesetting, 1 when inside \edef or \xdef and 2 in other cases of full expansion with scan_toks. It could possibly be extended to distinguish between \marks and \write etc. Comments more than welcome on this one! I have also added an \ifalignscanning test. It is true whenever TeX is looking for \noalign etc. so is most useful for a \stopalignscanning function defined as \def\stopalignscanning{\ifalignscanning\relax\fi} ---------------------------------------------------------------------- Comment By: Frank Mittelbach (mittelbach) Date: 2006-02-15 18:38 Message: Logged In: YES user_id=3421 concerning register versus individual \if... primitves: I agree that numeric values are less easy to read but if the numeric codes are well chosen then they have the advantage of not cluttering the code, eg if you have to test for a number of different cases then a set of nested \if's is also not really helpful. Suppose for example you have to do different actions depending on the type of expansion. Then the register allows you to do this in a since \ifcase or in some \ifnum ...> . But of course this only works is the order is adjusted to typical usages. And non-numerical ones could still be implemented efficently at the macro level, eg \def\ifinedef{\ifnum 1=\currentexpansionmode} as to \stopalignscanning: this is not identical to \protected as protection prevents expansion in all cases which is not necessarily what you need my 2 cents frank ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-17 23:22 Message: Logged In: YES user_id=927 concerning alignments: - how about adding \everyaligncell (in addition to \everycr) - how about the other iftests? - (and \nospan -) ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-16 21:23 Message: Logged In: YES user_id=3333 @None: An \ifalignscanning primitive can also help macros like LaTeX's \multicolumn and other code that relies on seeing \noalign or \omit to recover gracefully with a comprehensible error message. ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-13 05:50 Message: Logged In: YES user_id=3333 Yes, just ideas here, which is why I asked for comments. We can discuss this on the list (once my subscription is accepted). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-01-12 11:22 Message: Logged In: YES user_id=1608 Like Hans, I also prefer separate if primitives, mainly because I do not want to have to remember the meanings of the possible integer values (for that reason, I'm not too happy about \currentgrouptype either). Taco ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-01-12 10:14 Message: Logged In: NO i wonder why we need \ifalignscanning or \stopalignscanner at all when eTeX already has this feature - any \protected macro stops the scanning. ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-12 09:08 Message: Logged In: YES user_id=927 somehow i think that if's are a better idea than a register because in your case the register only registers one case at the same time (when i saw this patch the first time, i wondered why not a complete set was implemented) - ifincsname - ifinedef - ifinwrite - ifinspecial - ifinpdfliteral - ifinannotbody - ifinmessage (special case of write) - ifinalign - ifinmark probably some more (ok, normally all those conditions can comfortably be catched in a macro package but if we add them, we should be complete in addition to this there can be a register which keeps track of the innermost one (we can have ifcsname inside an edef inside an align concerning the \stopalignscanner i think it's better to have something primitive like \crcr, say \endalign because using if's can have its own problem (we should not worry to much about a name clash, since one can always let it to another one); so, we should wait with adding this patches till (1) we agree and (2) it is complete remark: also, it's dangerous to add patched before a decent decission/interface is dediced upon; once it's in, we cannot change it any more Hans ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=469&group_id=106

1 0

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

15 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: \ptexnoligatures 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-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 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 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 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

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

15 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: \ptexnoligatures 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-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 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 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 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

poppler usage, autoconf
by Frank Küster 15 Feb '06

15 Feb '06

Hi, I've worked on the patch originally proposed at http://sarovar.org/tracker/index.php?func=detail&aid=474&group_id=106&atid=… I have rewritten the changes to the source files, so that they continue to use the xpdf code copy in the source tree and only use libpoppler if the compiler (or rather preprocessor) is called with -DPOPPLER. This version is attached. The harder part is the autoconf magic required for the switching, and not even writing autoconf (at least not yet), but rather incorporating the changes: On my system, "./reautoconf" does not work, instead complains: autoconf: invalid option -m I have $ autoconf --version autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. Or is there a different way to regenerate configure after changes to its source files? TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)

4 7

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

15 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: \ptexnoligatures 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: Bernd Raichle (bernd) Date: 2006-02-15 10:10 Message: Logged In: YES user_id=3344 Another limitation which should be documented: If \ptexnoligatures 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 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 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

Re: [NTG-pdftex] poppler usage, autoconf
by Thomas Esser 15 Feb '06

15 Feb '06

> However, only if I'm sure that we will be able to incorporate this into > the standalone pdftex tarball, and into texlive. Is there any > documentation how Peter did it, and what needs to be done for simple > updates? He has put his material (patches + instructions; both excellent) here: ftp://ftpth.mppmu.mpg.de/pub/peb/web2c/autoconf/ Peter has also contacted several authors IIRC, so he might have additional information beyond this. And, as I already wrote, my current stuff is available from rsync://tug.org/tetexdevsrc/ and the migration has already happened there (Peter, I'd be happy if you look at this). > And are there any binaries in texlive that aren't in the teTeX > tree and already converted? I am not aware of any. Peter? Thomas

1 0

[ pdftex-Patches-93 ] \quitvmode
by noreply＠sarovar.org 14 Feb '06

14 Feb '06

Patches item #93, was opened at 2004-07-15 12:12 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=93&group_id=106 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: \quitvmode Initial Comment: The change file adds a new primitive called \quitvmode. In vertical modes, it is identical to \indent, but in horizontal and math modes it is \noindent. See http://www.metatex.org/web/quitvmode.html ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2006-02-14 13:20 Message: Logged In: YES user_id=1608 http://www.metatex.org/web/quitvmode.html Bernd, this is a repository for patches. Discussion normally takes place on the ntg-pdftex mailing list, not here. Cheers, Taco ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 13:02 Message: Logged In: YES user_id=3344 IMHO the name should include a \...indent to be consistent with the existing \indent/\noindent, if this primitive has similar functionality. And why not using a macro solution? (This means that I ask to please add a small rationale when introducing new primitives.) \def\quitvmode{% \ifvmode \indent \else \noindent \fi} If I make this a \protected\def (using e-\TeX) this will also cover the cases where TeX is looking ahead and expanding tokens (i.e., inside alignments looking for \omit, \span etc.). Is there any unseen advantage of the new primitive not covered by this macro resp. plain's \leavevmode macro? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-13 16:42 Message: Logged In: YES user_id=421 This has been included in 1.21a ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=93&group_id=106

1 0