- ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-709 ] merging patch 597 by Hartmut
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Patches item #709, was opened at 2006-12-04 09:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106 Category: Fonts Group: v1.40.0 >Status: Closed Resolution: None Priority: 6 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: merging patch 597 by Hartmut Initial Comment: This is a patch against pdftex-1.40.0-beta-20061018 that merges patch 597 by Hartmut and does some clean up in the font mechanism. Testing welcome very much. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-06 18:05 Message: Logged In: YES user_id=710 patch updated to fix a bug with pdf inclusion. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-05 23:52 Message: Logged In: YES user_id=710 patch updated; tested with pdftex manual, microtype manual and base latex doc. A fix for bug #693 is included. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 14:38 Message: Logged In: YES user_id=710 ah, sorry, my mistake. It's against pdftex-1.40.0-beta-20061108 (the latest beta), not pdftex-1.40.0-beta-20061018 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 14:25 Message: Logged In: YES user_id=710 are you saying that you have troubles applying the patch against pdftex-1.40.0-beta-20061017? Can you please try to apply against pdftex-1.40.0-beta-20061018? I have checked everything again from the beginning as follows: - download and unpack http://sarovar.org/download.php/1100/pdftex-1.40.0-beta-20061017.tar.bz2 - download, ungzip and apply http://sarovar.org/download.php/1108/pdftex-1.40.0-beta-20061017-20061108.d… - download http://sarovar.org/tracker/download.php/106/495/709/237/pdftex-20061204-2.p… - cd /path/to/pdftex-1.40.0-beta-20061017/src - patch -p1 --dry-run /path/to/pdftex-20061204-2.patch The patch applied ok, apart from change-files.txt (I removed it from pdftexdir, as it's no longer relevant to pdftex). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-04 13:33 Message: Logged In: YES user_id=421 I'm having troubles applying pdftex-20061204-2.patch against pdftex-1.40.0-beta-20061017, especially pdftex.web. Can you attach a diff against 1.40.0-beta-20061108 or your patched pdftex.web? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 12:02 Message: Logged In: YES user_id=710 I updated the patch to revert auto kerns to be explicit. This will disable hyphenation if auto kern is used. On the other hand this is much more robust. The pending problems are: bug #693: still trying bug #484: will not be fixed, better treat it as a limitation bug #465: unlikely to be fixed ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106

1 0

[ pdftex-Patches-705 ] Patch to allow vf_nf grow dynamically
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Patches item #705, was opened at 2006-11-22 20:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106 Category: Fonts Group: v1.40.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: Patch to allow vf_nf grow dynamically Initial Comment: This patch allows the array vf_e_fnts and vf_i_fnts grow dynamically, instead of having fixed size font_max as currently. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-11-26 21:01 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-25 10:58 Message: Logged In: NO Hi! It's been applied on Debian/unstable, and it works! Top notch! Thanks Danai SAE-HAN ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-11-23 08:18 Message: Logged In: YES user_id=710 yes. this patch also contains a fix by Akira the segfault bug (one line added) and a fix for bug #692 (another line). It's not hard to fix bug #694 and #696 too. However I didn't mention them, as I am considering to remove the relevant code. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-23 02:26 Message: Logged In: NO Hi! Does this mean that the bug "SGML output fails with pdflatex" will also be solved? Cheers Danai SAE-HAN ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106

1 0

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

20 Dec '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: Closed 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

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

20 Dec '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: Closed >Resolution: Accepted 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-12-01 11:26 Message: Logged In: YES user_id=421 We've removed it from beta again; it introduces additional problems and needs more time to stabilize. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-30 16:22 Message: Logged In: YES user_id=2217 It's great to have this included! However, pdftex is now a bit too keen on autoexpanding -- it does so, even if `autoexpand' is not specified. Although the pre-created metrics are read, the physical font (pfb resp. pk) is ignored. As has been discussed re: bug 304, *not* using autoexpansion gives better results for MM (and MF) fonts, since the fonts are not stretched blindly but stroke widths are adjusted etc. Compare the output of the test file from bugs/304 compiled with an old pdftex and with 20060928. With the latter, the strokes are slightly heavier. Same here (with an existing file cmr10+100.mf): \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr =cmr10 \cmr \pdffontexpand\cmr 100 0 100 %autoexpand Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye ---------------------------------------------------------------------- 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-696 ] pdftex always autoexpands -- even if it shouldn't
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Bugs item #696, was opened at 2006-11-15 02:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106 Category: hz Group: v1.40.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: pdftex always autoexpands -- even if it shouldn't Initial Comment: pdftex is now a bit too keen on autoexpanding -- it does so, even if `autoexpand' is not specified. Although the pre-created metrics are read, the physical font (pfb resp. pk) is ignored. As has been discussed re: bugs/304, *not* using autoexpansion gives better results for MM (and MF) fonts, since the fonts are not stretched blindly but stroke widths are adjusted etc. I've moved the test file from bugs/304 here. Another example is (with an existing file cmr10+100.mf): \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr =cmr10 \cmr \pdffontexpand\cmr 100 0 100 %autoexpand Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-20 16:26 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106

1 0

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Bugs item #304, was opened at 2005-03-02 18:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Open >Resolution: Fixed Priority: 3 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-20 16:26 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-11-15 02:23 Message: Logged In: YES user_id=2217 problem with autoexpanding now at bugs/696 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 12:23 Message: Logged In: YES user_id=710 Here is an attempt to fix this problem (reversed patch attached). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-03 19:30 Message: Logged In: YES user_id=2217 I've attached an example using Kepler MM (tfm+pfb included, please delete after testing). MM fonts are probably the only case where one would not want to use the autoexpand feature. At first sight, saying "autoexpand" or not doesn't seem to make a difference, since pdftex will always prefer existing expanded fonts (pfb) over autoexpanding them, anyway. However, there are some slight differences in the pdf. This is probably because the provided tfm file is different from the metrics that pdf calculates itself in the case of autoexpand. That is, autoexpand may result in a mismatch between the provided pfb and the calculated tfm, is that correct? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-01 21:02 Message: Logged In: YES user_id=929 currently i even can't get a test file do expansion at all without "autoexpand". E. g. Robert's example above, without "autoexpand", doesn't use expanded fonts. Maybe that's the reason for the missing expand parameter in the log? Can anybody provide a test file for this case? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:47 Message: Logged In: YES user_id=421 Is this really a problem, i.e. is there a reason _not_ to use the autoexpand feature in new documents? Hartmut, did you look into this bug? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-16 00:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 17:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 22:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\tenrm t ...\tenrm (+20) e Without font expansion, this default should be compatible with TeX's original log output. If \pdftracingfonts is set to 1 (or greater), we get a more verbose log (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

Re: [NTG-pdftex] suspicious line in vfpacket.c
by Thanh Han The 18 Dec '06

18 Dec '06

yes indeed. Thanks for pointing it out. Thanh On Mon, Dec 18, 2006 at 05:27:25PM +0100, Taco Hoekwater wrote: > Hi guys, > > This function looks odd to me. My guess is that the > second fontec should be fontbc. > > Best, Taco > > > void vf_free(void) > { > vf_entry *v; > int n; > char **p; > if (vf_array != NULL) { > for (v = vf_array; v < vf_ptr; v++) { > xfree(v->len); > n = fontec[v->font] - fontec[v->font] + 1; > for (p = v->data; p - v->data < n; p++) > xfree(*p); > xfree(v->data); > } > xfree(vf_array); > } > xfree(packet_array); > } > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex

1 0

suspicious line in vfpacket.c
by Taco Hoekwater 18 Dec '06

18 Dec '06

Hi guys, This function looks odd to me. My guess is that the second fontec should be fontbc. Best, Taco void vf_free(void) { vf_entry *v; int n; char **p; if (vf_array != NULL) { for (v = vf_array; v < vf_ptr; v++) { xfree(v->len); n = fontec[v->font] - fontec[v->font] + 1; for (p = v->data; p - v->data < n; p++) xfree(*p); xfree(v->data); } xfree(vf_array); } xfree(packet_array); }

1 0

[ pdftex-Bugs-714 ] Inclusion of PDF1.7 reference fails with lookup_fd_entry: Assertion `s != ((void *)0)'
by noreply＠sarovar.org 14 Dec '06

14 Dec '06

Bugs item #714, was opened at 2006-12-14 00:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=714&group_id=106 Category: Fonts Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: Inclusion of PDF1.7 reference fails with lookup_fd_entry: Assertion `s != ((void *)0)' Initial Comment: The attached test (including the PDF 1.7 reference) fails with [...] <use pdf17.pdf, page 22> <use pdf17.pdf, page 23> <use pdf17.pdf, page 24> [1 <./pdf17.pdf{/home/ms/.texmf-var/fonts/map/pdftex/updmap/pdftex.map}> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17. pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdfpdflatex: ../../../../src/texk/web2c/pdftexdir/writefont.c:192: lookup_fd_entry: Assertion `s != ((void *)0)' failed. Abgebrochen (core dumped) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 02:21 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-12-14 02:14 Message: Logged In: YES user_id=929 it happened with the map line "rpsyr Symbol" containing one of the 14 standard font names, but no font file name. These map lines are useful for typesetting, but not for font replacement. Still this was tried, as a check for missing font file was missing. The patch should repair this. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 01:33 Message: Logged In: YES user_id=421 Since this doesn't happen with \pdfmapline{}, I've attached the pdftex.map used. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 00:51 Message: Logged In: YES user_id=421 bt from core: #0 0x00002af9ad264aa5 in raise () from /lib64/libc.so.6 #1 0x00002af9ad265e60 in abort () from /lib64/libc.so.6 #2 0x00002af9ad25e246 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000489f58 in lookup_fd_entry (s=0x0, slant=0, extend=0) at ../../../../src/texk/web2c/pdftexdir/writefont.c:192 #4 0x00000000004a1fa3 in epdf_create_fontdescriptor (fm=0xdbd410) at ../../../../src/texk/web2c/pdftexdir/epdf.c:40 #5 0x000000000049bce2 in copyFont (tag=0xa3e6b0 "T1_3", fontRef=0x7ffffdae4ef0) at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:396 #6 0x000000000049c1a2 in copyFontResources (obj=0x7ffffdae5120) at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:426 #7 0x000000000049cfb2 in write_epdf () at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:928 #8 0x000000000049a767 in writeimage (img=14) at ../../../../src/texk/web2c/pdftexdir/writeimg.c:348 #9 0x000000000044a3b8 in zpdfwriteimage (n=15) at pdftex2.c:384 #10 0x0000000000451a57 in zpdfshipout (p=5967, shippingpage=1) at pdftex2.c:2856 #11 0x00000000004532c6 in zshipout (p=5967) at pdftex2.c:3398 #12 0x000000000046a82f in zboxend (boxcontext=1073807360) at pdftex2.c:11127 #13 0x000000000046adfe in zbeginbox (boxcontext=1073807360) at pdftex2.c:11307 #14 0x000000000046ae3b in zscanbox (boxcontext=1073807360) at pdftex2.c:11322 #15 0x00000000004789d9 in maincontrol () at pdftex3.c:5478 #16 0x0000000000416787 in mainbody () at pdftexini.c:5664 #17 0x000000000047ee9b in main (ac=2, av=0x7ffffdae54b8) at pdftexextra.c:341 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 00:49 Message: Logged In: YES user_id=421 attached the log file ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=714&group_id=106

1 0

[ pdftex-Bugs-714 ] Inclusion of PDF1.7 reference fails with lookup_fd_entry: Assertion `s != ((void *)0)'
by noreply＠sarovar.org 14 Dec '06

14 Dec '06

Bugs item #714, was opened at 2006-12-14 00:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=714&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: Inclusion of PDF1.7 reference fails with lookup_fd_entry: Assertion `s != ((void *)0)' Initial Comment: The attached test (including the PDF 1.7 reference) fails with [...] <use pdf17.pdf, page 22> <use pdf17.pdf, page 23> <use pdf17.pdf, page 24> [1 <./pdf17.pdf{/home/ms/.texmf-var/fonts/map/pdftex/updmap/pdftex.map}> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17. pdf> <./pdf17.pdf> <./pdf17.pdf> <./pdf17.pdfpdflatex: ../../../../src/texk/web2c/pdftexdir/writefont.c:192: lookup_fd_entry: Assertion `s != ((void *)0)' failed. Abgebrochen (core dumped) ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-12-14 02:14 Message: Logged In: YES user_id=929 it happened with the map line "rpsyr Symbol" containing one of the 14 standard font names, but no font file name. These map lines are useful for typesetting, but not for font replacement. Still this was tried, as a check for missing font file was missing. The patch should repair this. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 01:33 Message: Logged In: YES user_id=421 Since this doesn't happen with \pdfmapline{}, I've attached the pdftex.map used. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 00:51 Message: Logged In: YES user_id=421 bt from core: #0 0x00002af9ad264aa5 in raise () from /lib64/libc.so.6 #1 0x00002af9ad265e60 in abort () from /lib64/libc.so.6 #2 0x00002af9ad25e246 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000489f58 in lookup_fd_entry (s=0x0, slant=0, extend=0) at ../../../../src/texk/web2c/pdftexdir/writefont.c:192 #4 0x00000000004a1fa3 in epdf_create_fontdescriptor (fm=0xdbd410) at ../../../../src/texk/web2c/pdftexdir/epdf.c:40 #5 0x000000000049bce2 in copyFont (tag=0xa3e6b0 "T1_3", fontRef=0x7ffffdae4ef0) at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:396 #6 0x000000000049c1a2 in copyFontResources (obj=0x7ffffdae5120) at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:426 #7 0x000000000049cfb2 in write_epdf () at ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc:928 #8 0x000000000049a767 in writeimage (img=14) at ../../../../src/texk/web2c/pdftexdir/writeimg.c:348 #9 0x000000000044a3b8 in zpdfwriteimage (n=15) at pdftex2.c:384 #10 0x0000000000451a57 in zpdfshipout (p=5967, shippingpage=1) at pdftex2.c:2856 #11 0x00000000004532c6 in zshipout (p=5967) at pdftex2.c:3398 #12 0x000000000046a82f in zboxend (boxcontext=1073807360) at pdftex2.c:11127 #13 0x000000000046adfe in zbeginbox (boxcontext=1073807360) at pdftex2.c:11307 #14 0x000000000046ae3b in zscanbox (boxcontext=1073807360) at pdftex2.c:11322 #15 0x00000000004789d9 in maincontrol () at pdftex3.c:5478 #16 0x0000000000416787 in mainbody () at pdftexini.c:5664 #17 0x000000000047ee9b in main (ac=2, av=0x7ffffdae54b8) at pdftexextra.c:341 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-14 00:49 Message: Logged In: YES user_id=421 attached the log file ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=714&group_id=106

1 0