February 2006 - ntg-pdftex - NTG Mailing Lists

[ 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