- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-609 ] Pdf "convert" primitives bug
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Bugs item #609, was opened at 2006-09-28 18:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106 Category: Primitives Group: v1.40.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Taco Hoekwater (taco) >Summary: Pdf "convert" primitives bug Initial Comment: The problem: When tex calls `conv_toks()' to execute `convert' commands, a string may already be being built. A call to scan_toks (pdf_scan_ext_toks) at that moment will incorporate that partial string to the argument of the `convert' primitive, and erase it from the output. Example code: \message{\pdfmdfivesum{knuth}} \input knuth\pdfmdfivesum{} \bye Affected primitives: \pdfescapestring \pdfescapename \pdfescapehex \pdfunescapehex \pdffilemoddate \pdffilesize \pdffiledump \pdfmdfivesum \pdfstrcmp The needed fix: Somewhen before calling scan_pdf_ext_toks, you have to store the partial string as a true tex string, then its `partialness' has to be restored sometime later before leaving conv_toks(). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:57 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-10-04 16:43 Message: Logged In: YES user_id=1608 patch against pdftex.web from 20060928 attached. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-09-28 18:52 Message: Logged In: YES user_id=1608 sorry, it is a bug, of course ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106

1 0

[ pdftex-Patches-663 ] fix for bugs #481--483
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Patches item #663, was opened at 2006-10-21 14:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106 >Category: hz >Group: v1.40.0 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) >Assigned to: Hartmut Henkel (hhenkel) Summary: fix for bugs #481--483 Initial Comment: This is an attempt to fix bug #481--483 - This patch applies to the pristine pdftex-1.40.0-beta-20061017 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - How to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20061017/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:54 Message: Logged In: YES user_id=421 Thanks! Any idea for 484? :-) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106

1 0

[ pdftex-Bugs-483 ] extra kerning inhibits extra spacing
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Bugs item #483, was opened at 2006-02-13 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=483&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: extra kerning inhibits extra spacing Initial Comment: The new extension don't work together: \pdfadjustinterwordglue=1 \knbscode\font`\e=1000 The test \pdfappendkern=1 \knaccode\font`\e=1 The test \bye ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:52 Message: Logged In: YES user_id=421 Fixed; see patch 663. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=483&group_id=106

1 0

[ pdftex-Bugs-482 ] extra kerning does not work with ligatures
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Bugs item #482, was opened at 2006-02-13 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=482&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: extra kerning does not work with ligatures Initial Comment: Appending or prepending kerns with the new primitives does not work with ligatures. It works, though, when the ligatures are accessed via \char: \pdfprependkern=1 \pdfappendkern=1 \def\setkn#1{% \knbccode\font #1 = 200\relax \knaccode\font #1 = 200\relax } \setkn{`a} \setkn{11} % ff \setkn{12} % fi \setkn{`z} afffiz\par a\char11 \char12 z \bye ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:52 Message: Logged In: YES user_id=421 Fixed; see patch 663. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=482&group_id=106

1 0

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

21 Oct '06

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

1 0

[ pdftex-Patches-663 ] fix for bugs #481--483
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Patches item #663, was opened at 2006-10-21 12:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: fix for bugs #481--483 Initial Comment: This is an attempt to fix bug #481--483 - This patch applies to the pristine pdftex-1.40.0-beta-20061017 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - How to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20061017/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106

1 0

[ pdftex-Feature Requests-662 ] avoid creating "fixed destination"
by noreply＠sarovar.org 20 Oct '06

20 Oct '06

Feature Requests item #662, was opened at 2006-10-20 13:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=662&group_id=106 Category: None >Group: v1.50 Status: Open Resolution: None Priority: 5 Submitted By: Ulrich Diez (ulrichdiez) >Assigned to: The Thanh Han (hanthethanh) >Summary: avoid creating "fixed destination" Initial Comment: When referencing a non-existing destination, you get this warning: ! pdfTeX warning (dest): name{<something>} has been referenced but does not exist, replaced by a fixed one I always like the warning about non-existing destinations, but sometimes I'd prefer pdfTeX not to take action besides issuing a warning-message/I'd prefer pdfTeX not to create a "fixed" destination. E.g., when creating several separate pdf-files with pdfTeX (for later merging them together by means of external software like "pdftk" or "pdfcat") whereby the named destination is not known/available when compiling file A but is available/provided in file B so that in the result from merging these files, everything will be fine. Does it make sense/is it possible to implement some mechanism for forking if creation of fixed destination shall be avoided or not? (Either a new token/primitive similar to \globaldefs which can be used within TeX source or some command- line-option which can be specified at the command-line when running pdfTeX ?) Sincerely Ulrich ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=662&group_id=106

1 0

[ pdftex-Feature Requests-662 ] avoid creating "fixed destination"
by noreply＠sarovar.org 20 Oct '06

20 Oct '06

Feature Requests item #662, was opened at 2006-10-20 11:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=662&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ulrich Diez (ulrichdiez) Assigned to: Nobody (None) Summary: avoid creating "fixed destination" Initial Comment: When referencing a non-existing destination, you get this warning: ! pdfTeX warning (dest): name{<something>} has been referenced but does not exist, replaced by a fixed one I always like the warning about non-existing destinations, but sometimes I'd prefer pdfTeX not to take action besides issuing a warning-message/I'd prefer pdfTeX not to create a "fixed" destination. E.g., when creating several separate pdf-files with pdfTeX (for later merging them together by means of external software like "pdftk" or "pdfcat") whereby the named destination is not known/available when compiling file A but is available/provided in file B so that in the result from merging these files, everything will be fine. Does it make sense/is it possible to implement some mechanism for forking if creation of fixed destination shall be avoided or not? (Either a new token/primitive similar to \globaldefs which can be used within TeX source or some command- line-option which can be specified at the command-line when running pdfTeX ?) Sincerely Ulrich ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=662&group_id=106

1 0

Re: [NTG-pdftex] why is TeX breaking the line?
by Taco Hoekwater 18 Oct '06

18 Oct '06

Hi Péter, Szabo Peter wrote: > Dear Taco, > > Do you have an idea why TeX is breaking the line at the \discretionary > in the source file below, thus producing an Overfull \hbox -- but if it > hadn't broken the line there, there would be no overfull boxes? > > If you don't know the answer, could you please recommend a forum or > mailing list? CC the pdftex mailing list, perhaps Thanh or Bernd knows, even though it is not really a pdfTeX question. To me, it looks like it may even be a bug. Greetings, Taco

5 5

[ pdftex-Patches-580 ] Patch to make ToUnicode for Type1 fonts
by noreply＠sarovar.org 17 Oct '06

17 Oct '06

Patches item #580, was opened at 2006-07-14 22:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=580&group_id=106 Category: None >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to make ToUnicode for Type1 fonts Initial Comment: This is a patch to pdftex so that it can create ToUnicode entries for Type1 fonts. The main purpose is to make ligatures and some other glyphs like smallcap letters or oldstyle digits from OpenType fonts searchable. This patch also contains a minor fix that allows use of fonts without embedding, for example MinionPro or MyriadPro (which are distributed with Acrobat Reader >= 7.0 but from their use is restricted with Acrobat Reader only). How to apply: ~~~~~~~~~~~~~ - this patch applies to the pristine pdftex-1.40.0-beta-20060213 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - how to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20060213/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdfetex `-------- If you want to be careful, try the patch with the option '--dry-run' first to see whether the patch can be applied without problems. Usage: ~~~~~~ add the following lines into your document, somewhere at the beginning: ,-------- | \input glyphtounicode.tex | \pdfgentounicode=1 `-------- Customization: ~~~~~~~~~~~~~ If pdftex cannot generate the right ToUnicode value for some glyphs (probably because the glyph name is not ``known'' to pdftex), it's possible to add further entries so pdftex can learn how to generate unicode for such ``unknown'' glyphs. The syntax is simple: \pdfglyphtounicode{<glyph-name>}{<unicode-value>} Example: \pdfglyphtounicode{A}{0041} says that glyph 'A' has its unicode U+0041 The entries in glyphtounicode.tex cover Adobe Glyph List (glyphlist.txt version 2.0) and some addtional glyphs (texglyphlist.txt version 2.33, coming from from lcdf-typetools), plus some additional entries for ligatures. If some glyph name cannot be found, pdftex does some simple name translations: - remove any ".xxx" suffix from glyph name, where "xxx" is a string consisting of alphabetic characters. For example "A.sc" => "A" - remove suffix like "small", "oldstyle", "inferior" and "superior" from glyph name. For example "Asmall" => "A" The result name then is looked up again to find a unicode. Ligatures require a special form of ToUnicode. Example: \pdfglyphtounicode{ff}{00660066} here '0066' is the unicode string for 'f'. Some ligatures have their name like 'f_f_i', in such case the command should be \pdfglyphtounicode{f_f_i}{006600660069} ie '_' is removed from the glyph name, and then all letters are translated to their unicode string. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-17 15:39 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-07 11:44 Message: Logged In: YES user_id=710 Patch updated to fix a bug reported by Akira. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-06 13:34 Message: Logged In: YES user_id=710 This is a patch to pdftex that includes: - a fix for bug #611 - some changes to ToUnicode support (patch #580) to make the implementation follow guidelines at http://partners.adobe.com/public/developer/opentype/index_glyph.html How to apply: ~~~~~~~~~~~~~ - this patch applies to the pristine pdftex-1.40.0-beta-20060928 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - how to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20060928/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- If you want to be careful, try the patch with the option '--dry-run' first to see whether the patch can be applied without problems. Usage: ~~~~~~ add the following lines into your document, somewhere at the beginning: ,-------- | \input glyphtounicode.tex | \pdfgentounicode=1 `-------- Customization: ~~~~~~~~~~~~~ If pdftex cannot generate the right ToUnicode value for some glyphs (probably because the glyph name is not ``known'' to pdftex), it's possible to add further entries so pdftex can learn how to generate unicode for such ``unknown'' glyphs. The syntax is simple: ,-------- | \pdfglyphtounicode{<glyph-name>}{<unicode-value>} `-------- Example: ,-------- | \pdfglyphtounicode{A}{0041} `-------- says that glyph 'A' has its unicode U+0041. \pdfglyphtounicode requires that the second parameter consists of uppercase hexadecimal digits (0..9, A..F) and spaces. If this is not the case the entry is simply discarded (with a warning). Later entries overwrite previous entries with the same name (1st arg). The entries in glyphtounicode.tex cover: - glyphlist.txt (Adobe Glyph List v2.0) - zapfdingbats.txt (ITC Zapf Dingbats Glyph List v2.0) - texglyphlist.txt (lcdf-typetools texglyphlist.txt v2.33) - additional.tex (additional entries) Ligatures require a special form of ToUnicode. Example: ,-------- | \pdfglyphtounicode{ff}{00660066} `-------- here '0066' is the unicode string for 'f'. Spaces are ignored in the second parameter of \pdfglyphtounicode, hence it is possible to write the above command as ,-------- | \pdfglyphtounicode{ff}{0066 0066} `-------- which is easier to read and understand IMO. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-07-19 08:08 Message: Logged In: YES user_id=710 patch updated to fix a bug reported by Dohyun Kim ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-07-16 13:19 Message: Logged In: YES user_id=710 patch updated by a bug fix from Akira ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=580&group_id=106

1 0