- ntg-pdftex - NTG Mailing Lists

[ 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