- ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] [tex-live] pdfTeX and ToUnicode CMaps
by Heiko Oberdiek 25 Oct '07

25 Oct '07

Hello, I think a better place for this issue is the (ntg-)pdftex mailing list, therefore I have CCed the ntg-pdftex mailing list. On Wed, Oct 24, 2007 at 09:25:19AM +0200, Werner LEMBERG wrote: > > > What exactly is the status of automatic ToUnicode CMap generation > > > within pdfTeX? There is a very nebulous entry in the NEWS file > > > (BTW, the versions in TeXLive's Build and Master tree differ), but > > > the manual is completely silent about it... > > > > Thanh knows all about it. :-) > > Did you read patch 580 (http://preview.tinyurl.com/38fjr9)? > > I now did. Thanks to the pointer. How comes that this feature is > neither mentioned in the NEWS file nor in the documentation? It was presented by Han at EuroBachoTeX 2007: `Font-specific issues in pdfTeX' (I don't know whether slides exist on-line, via google I only found a non-existing pdf file, but at least google's html view was available.) Section "5. Support for ToUnicode map". > I consider this as *very bad*. Lack of documentation is inexcusable. I think there are unsolved issues. Now there are two methods for adding CMaps: (a) \pdffontattr, package cmap (b) \pdfgentounicode, glyphtounicode.tex Both methods have its limitations, e.g. (b) only works for Type 1 fonts. Thus you could need both methods to cover all fonts, but the methods doesn't know each other, thus fonts can end up with two CMap tables. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de>

2 3

Is there a limit to the size of PDF files?
by Akira Kakuto 17 Oct '07

17 Oct '07

> Could it be that PDFTeX (as in TeXlive2007 for win32) aborts with an > obscure error message when the size of the generated PDF file exceeds > 2GB? The prototype of fseek() in my old MSVC++ reads int fseek(FILE *stream, long offset, int origin) and long (the same as int) is signed 32 bit integer. Therefore I think 2GB is the limit in the TL win32 pdfTeX. > If yes, is there a chance to work around this in some way? I cannot find a workaround. Best regards, Akira

6 11

[ pdftex-Bugs-877 ] PDFs limited to 2G
by noreply＠sarovar.org 17 Oct '07

17 Oct '07

Bugs item #877, was opened at 2007-10-17 16:46 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=877&group_id=106 Category: None Group: v1.40.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: PDFs limited to 2G Initial Comment: pdfTeX will happily produce pdfs >2G, if the fs and os allow that, but these are broken: pdf_offset et.al. are only ints, i.e. 32bit. So all objects after 2GB are not accessible. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-10-17 17:51 Message: Logged In: YES user_id=421 Future versions of pdftex will catch overflows of pdf_offset and abort with an error. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-17 17:09 Message: Logged In: YES user_id=421 It works if you are on a 64bit platform and compile with -DNO_DUMP_SHARE ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=877&group_id=106

1 0

[ pdftex-Bugs-877 ] PDFs limited to 2G
by noreply＠sarovar.org 17 Oct '07

17 Oct '07

Bugs item #877, was opened at 2007-10-17 16:46 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=877&group_id=106 Category: None Group: v1.40.5 Status: Open Resolution: None Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: PDFs limited to 2G Initial Comment: pdfTeX will happily produce pdfs >2G, if the fs and os allow that, but these are broken: pdf_offset et.al. are only ints, i.e. 32bit. So all objects after 2GB are not accessible. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-10-17 17:09 Message: Logged In: YES user_id=421 It works if you are on a 64bit platform and compile with -DNO_DUMP_SHARE ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=877&group_id=106

1 0

[ pdftex-Bugs-877 ] PDFs limited to 2G
by noreply＠sarovar.org 17 Oct '07

17 Oct '07

Bugs item #877, was opened at 2007-10-17 16:46 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=877&group_id=106 Category: None Group: v1.40.5 Status: Open Resolution: None Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: PDFs limited to 2G Initial Comment: pdfTeX will happily produce pdfs >2G, if the fs and os allow that, but these are broken: pdf_offset et.al. are only ints, i.e. 32bit. So all objects after 2GB are not accessible. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=877&group_id=106

1 0

Is there a limit to the size of PDF files?
by David Kastrup 17 Oct '07

17 Oct '07

Could it be that PDFTeX (as in TeXlive2007 for win32) aborts with an obscure error message when the size of the generated PDF file exceeds 2GB? If yes, is there a chance to work around this in some way? Thanks, -- David Kastrup

1 0

[ pdftex-Patches-876 ] I forgot...
by noreply＠sarovar.org 16 Oct '07

16 Oct '07

Patches item #876, was opened at 2007-10-15 13:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=876&group_id=106 Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Nobody (None) Summary: I forgot... Initial Comment: In my previous submission concerning breaking synchronization when using for example "dvipdfm -x ... -y ...", I forgot to mention that dvi- >pdf filters need not really be synchronization aware. On mac os x, TeXShop and iTeXMac2 frontends both use (shell script) wrappers to launch the above filters, such that only the wrappers need to be synchronization aware. At least on Mac OS X, there is no need to patch the various dvipdf like tools, only the wrappers, and this is the responsibility of the frontends developers who want to fully support synchronization. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=876&group_id=106

1 0

Anybody success compiling the current PDFTeX source?
by David Kastrup 15 Oct '07

15 Oct '07

I drop out after cd source;./build.sh with gcc -DHAVE_CONFIG_H -I. -I../../../src/texk/web2c -I.. -I../../../src/texk/web2c/.. -I../../libs/obsdcompat -I../../libs/obsdcompat/.. -I../../../src/texk/web2c/../../libs/obsdcompat -I../../../src/texk/web2c/../../libs/obsdcompat/.. -g -O2 -c pdftexextra.c -o pdftexextra.o pdftexextra.c: In function ‘maininit’: pdftexextra.c:190: warning: assignment from incompatible pointer type pdftexextra.c:191: warning: assignment from incompatible pointer type cd pdftexdir && make -w CC='gcc' CFLAGS='-g -O2 ' LDFLAGS='' libpdf.a make[2]: Entering directory `/rep/pdftex/pdftex/source/build/texk/web2c/pdftexdir' make[2]: *** No rule to make target `../../../../src/texk/web2c/pdftexdir/../../web2c/c-auto.h', needed by `epdf.o'. Stop. make[2]: Leaving directory `/rep/pdftex/pdftex/source/build/texk/web2c/pdftexdir' make[1]: *** [pdftexdir/libpdf.a] Error 2 make[1]: Leaving directory `/rep/pdftex/pdftex/source/build/texk/web2c' make: *** [pdftexbin] Error 2 -- David Kastrup

2 1

[ pdftex-Patches-876 ] I forgot...
by noreply＠sarovar.org 15 Oct '07

15 Oct '07

Patches item #876, was opened at 2007-10-15 13:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=876&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Nobody (None) Summary: I forgot... Initial Comment: In my previous submission concerning breaking synchronization when using for example "dvipdfm -x ... -y ...", I forgot to mention that dvi- >pdf filters need not really be synchronization aware. On mac os x, TeXShop and iTeXMac2 frontends both use (shell script) wrappers to launch the above filters, such that only the wrappers need to be synchronization aware. At least on Mac OS X, there is no need to patch the various dvipdf like tools, only the wrappers, and this is the responsibility of the frontends developers who want to fully support synchronization. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=876&group_id=106

1 0

[ pdftex-Patches-871 ] Synchronization: pdfsync.sty embedded (1)
by noreply＠sarovar.org 15 Oct '07

15 Oct '07

Patches item #871, was opened at 2007-09-30 10:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106 Category: User interaction Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Martin Schröder (oneiros) Summary: Synchronization: pdfsync.sty embedded (1) Initial Comment: To the administrator, please remove the preceding patch submission The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf PS: I have problems with my connection ---------------------------------------------------------------------- >Comment By: Jerome LAURENS (jlaurens) Date: 2007-10-15 09:21 Message: Logged In: YES user_id=4698 Synchronize3.zip is available. It just adds a flag in the .sync file to indicate whether dvi or pdf mode was used. So far I have found only one problem, using dvips or dvipdf with a concrete offset (-x and -y options) will break the synchronization. If such a filter is gentle enough to indicate that it used a custom offset, then viewers can take this into account and the synchronization is not broken. Viewers will check the above mentionned flag to look for customized offset. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-01 00:00 Message: Logged In: YES user_id=421 You didn't attach Synchronize 2.zip yet... ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:10 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:09 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106

1 0

[ pdftex-Bugs-874 ] problem with writettf?
by noreply＠sarovar.org 12 Oct '07

12 Oct '07

Bugs item #874, was opened at 2007-10-11 14:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106 Category: Fonts Group: v1.40.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Hartmut Henkel (hhenkel) Summary: problem with writettf? Initial Comment: Hello I'm using texlive 2007 and encountered the following problem with a truetype font: [...] {/usr/local/apps/texlive-2007/texmf/fonts/enc/ttf2pk/ba se/T1-WGL4.enc}<Auto1-Light.ttfpdflatex: ../../../../texk/web2c/pdftexdir/writettf.c:848: prepend_subset_tags: Assertion `index > 0 && index < name_record_num && fd_cur->subset_tag != ((void *)0)' failed. Upgrading pdftex to 1.40.5 still produces the same error. My previous texlive version (2005 or 2006) didn't have that problem. Replacing Auto1-Light.ttf by another ttf, such as technicn.ttf, does not result in an error. So it's probably related to the Auto1-Light.ttf file itself, but it seems the behaviour of pdftex has changed over the years... Best regards Stefan ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-12 20:59 Message: Logged In: YES user_id=929 seems in the TTF 'name' table normally the name_id is the same number as the running entry index i. Then everything runs fine. But with the Auto1-Light font that's not the case: at i = 0 there is name_id = 1. So AFAICS the font file might be a little unusual but it's ok, and pdftex/luatex should be patched. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-12 13:36 Message: Logged In: YES user_id=929 ah the font file is in your testcase tar, thanks! ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-12 13:31 Message: Logged In: YES user_id=929 thanks a lot for the test, but the fact that it works after the patch suggests that actually your TT font is broken (not pdftex) -- which might even generate broken or non-standard PDF files, beware! Seems the index = 0 should never happen with a normal font. So it would help a lot to have your font for inspection. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2007-10-12 09:54 Message: Logged In: YES user_id=4723 Changing index > 0 into index >= 0 did solve the problem. I have attached anyway the minimal testcase (generated after the suggested patch). Thanks for solving this problem! Stefan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-11 19:21 Message: Logged In: YES user_id=421 Can you create a minimal testcase and attach it here together with the font? systems/mkjobtexmf from CTAN might be helpful. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-11 16:14 Message: Logged In: YES user_id=929 does it go away if you change in pdftex-1.40.5, writettf.c in function prepend_subset_tag() the line assert(index > 0... into assert(index >= 0...? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106

1 0

[\immediate]\pdfximage
by David Kastrup 12 Oct '07

12 Oct '07

Hi, in an application of ours, we have the situation that quite a number of graphics files are checked for their size and stuff, and then a decision is made whether to use them in the resulting PDF. If we do the checks using \pdfximage, the resulting file handle (and internal data structures) are kept open until the end of the TeX run, waiting to see whether actually a \pdfrefximage will ever occur. Bad. We actually run out of file handles on some platforms because of that. If we do the checks using \immediate\pdfximage, then the graphics file will be written out to the PDF even though it will never get displayed or used. Since probably only one of five files actually _is_ supposed to be printed, this will blow up the PDF completely unnecessarily. Any idea how to deal with this? How about something like [\immediate]\pdfcloseximage which makes PDFTeX forget all about a previously included file, freeing the resources? Or is there something I don't understand? -- David Kastrup

2 1

[ pdftex-Bugs-874 ] problem with writettf?
by noreply＠sarovar.org 12 Oct '07

12 Oct '07

Bugs item #874, was opened at 2007-10-11 14:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106 Category: Fonts Group: v1.40.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Hartmut Henkel (hhenkel) Summary: problem with writettf? Initial Comment: Hello I'm using texlive 2007 and encountered the following problem with a truetype font: [...] {/usr/local/apps/texlive-2007/texmf/fonts/enc/ttf2pk/ba se/T1-WGL4.enc}<Auto1-Light.ttfpdflatex: ../../../../texk/web2c/pdftexdir/writettf.c:848: prepend_subset_tags: Assertion `index > 0 && index < name_record_num && fd_cur->subset_tag != ((void *)0)' failed. Upgrading pdftex to 1.40.5 still produces the same error. My previous texlive version (2005 or 2006) didn't have that problem. Replacing Auto1-Light.ttf by another ttf, such as technicn.ttf, does not result in an error. So it's probably related to the Auto1-Light.ttf file itself, but it seems the behaviour of pdftex has changed over the years... Best regards Stefan ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-12 13:36 Message: Logged In: YES user_id=929 ah the font file is in your testcase tar, thanks! ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-12 13:31 Message: Logged In: YES user_id=929 thanks a lot for the test, but the fact that it works after the patch suggests that actually your TT font is broken (not pdftex) -- which might even generate broken or non-standard PDF files, beware! Seems the index = 0 should never happen with a normal font. So it would help a lot to have your font for inspection. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2007-10-12 09:54 Message: Logged In: YES user_id=4723 Changing index > 0 into index >= 0 did solve the problem. I have attached anyway the minimal testcase (generated after the suggested patch). Thanks for solving this problem! Stefan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-11 19:21 Message: Logged In: YES user_id=421 Can you create a minimal testcase and attach it here together with the font? systems/mkjobtexmf from CTAN might be helpful. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-11 16:14 Message: Logged In: YES user_id=929 does it go away if you change in pdftex-1.40.5, writettf.c in function prepend_subset_tag() the line assert(index > 0... into assert(index >= 0...? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106

1 0

[ pdftex-Bugs-874 ] problem with writettf?
by noreply＠sarovar.org 12 Oct '07

12 Oct '07

Bugs item #874, was opened at 2007-10-11 14:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106 Category: Fonts Group: v1.40.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Hartmut Henkel (hhenkel) Summary: problem with writettf? Initial Comment: Hello I'm using texlive 2007 and encountered the following problem with a truetype font: [...] {/usr/local/apps/texlive-2007/texmf/fonts/enc/ttf2pk/ba se/T1-WGL4.enc}<Auto1-Light.ttfpdflatex: ../../../../texk/web2c/pdftexdir/writettf.c:848: prepend_subset_tags: Assertion `index > 0 && index < name_record_num && fd_cur->subset_tag != ((void *)0)' failed. Upgrading pdftex to 1.40.5 still produces the same error. My previous texlive version (2005 or 2006) didn't have that problem. Replacing Auto1-Light.ttf by another ttf, such as technicn.ttf, does not result in an error. So it's probably related to the Auto1-Light.ttf file itself, but it seems the behaviour of pdftex has changed over the years... Best regards Stefan ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-12 13:31 Message: Logged In: YES user_id=929 thanks a lot for the test, but the fact that it works after the patch suggests that actually your TT font is broken (not pdftex) -- which might even generate broken or non-standard PDF files, beware! Seems the index = 0 should never happen with a normal font. So it would help a lot to have your font for inspection. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2007-10-12 09:54 Message: Logged In: YES user_id=4723 Changing index > 0 into index >= 0 did solve the problem. I have attached anyway the minimal testcase (generated after the suggested patch). Thanks for solving this problem! Stefan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-11 19:21 Message: Logged In: YES user_id=421 Can you create a minimal testcase and attach it here together with the font? systems/mkjobtexmf from CTAN might be helpful. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-11 16:14 Message: Logged In: YES user_id=929 does it go away if you change in pdftex-1.40.5, writettf.c in function prepend_subset_tag() the line assert(index > 0... into assert(index >= 0...? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106

1 0

[ pdftex-Bugs-874 ] problem with writettf?
by noreply＠sarovar.org 12 Oct '07

12 Oct '07

Bugs item #874, was opened at 2007-10-11 14:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106 Category: Fonts Group: v1.40.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Hartmut Henkel (hhenkel) Summary: problem with writettf? Initial Comment: Hello I'm using texlive 2007 and encountered the following problem with a truetype font: [...] {/usr/local/apps/texlive-2007/texmf/fonts/enc/ttf2pk/ba se/T1-WGL4.enc}<Auto1-Light.ttfpdflatex: ../../../../texk/web2c/pdftexdir/writettf.c:848: prepend_subset_tags: Assertion `index > 0 && index < name_record_num && fd_cur->subset_tag != ((void *)0)' failed. Upgrading pdftex to 1.40.5 still produces the same error. My previous texlive version (2005 or 2006) didn't have that problem. Replacing Auto1-Light.ttf by another ttf, such as technicn.ttf, does not result in an error. So it's probably related to the Auto1-Light.ttf file itself, but it seems the behaviour of pdftex has changed over the years... Best regards Stefan ---------------------------------------------------------------------- >Comment By: Stefan Becuwe (sbecuwe) Date: 2007-10-12 09:54 Message: Logged In: YES user_id=4723 Changing index > 0 into index >= 0 did solve the problem. I have attached anyway the minimal testcase (generated after the suggested patch). Thanks for solving this problem! Stefan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-11 19:21 Message: Logged In: YES user_id=421 Can you create a minimal testcase and attach it here together with the font? systems/mkjobtexmf from CTAN might be helpful. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-11 16:14 Message: Logged In: YES user_id=929 does it go away if you change in pdftex-1.40.5, writettf.c in function prepend_subset_tag() the line assert(index > 0... into assert(index >= 0...? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106

1 0

Docs for xpdf libraries or poppler?
by David Kastrup 11 Oct '07

11 Oct '07

Having cloned the source repository of poppler, I could not fail to notice that there is no API documentation that I could discern. Now PDFTeX obviously _has_ been able to make sense of the libraries. What source of information has been used for this? Key point is that I have to read some PDF files, process them at some rather shallow object level, and write out the results. So far, I have not even been able to figure out whether one of those libs would be suitable for that. Since PDFTeX does reading and writing of PDF (also of included PDF files), some basic facility would seem to be there? -- David Kastrup

2 3

[ pdftex-Bugs-874 ] problem with writettf?
by noreply＠sarovar.org 11 Oct '07

11 Oct '07

Bugs item #874, was opened at 2007-10-11 14:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106 Category: Fonts Group: v1.40.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Hartmut Henkel (hhenkel) Summary: problem with writettf? Initial Comment: Hello I'm using texlive 2007 and encountered the following problem with a truetype font: [...] {/usr/local/apps/texlive-2007/texmf/fonts/enc/ttf2pk/ba se/T1-WGL4.enc}<Auto1-Light.ttfpdflatex: ../../../../texk/web2c/pdftexdir/writettf.c:848: prepend_subset_tags: Assertion `index > 0 && index < name_record_num && fd_cur->subset_tag != ((void *)0)' failed. Upgrading pdftex to 1.40.5 still produces the same error. My previous texlive version (2005 or 2006) didn't have that problem. Replacing Auto1-Light.ttf by another ttf, such as technicn.ttf, does not result in an error. So it's probably related to the Auto1-Light.ttf file itself, but it seems the behaviour of pdftex has changed over the years... Best regards Stefan ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-10-11 19:21 Message: Logged In: YES user_id=421 Can you create a minimal testcase and attach it here together with the font? systems/mkjobtexmf from CTAN might be helpful. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-11 16:14 Message: Logged In: YES user_id=929 does it go away if you change in pdftex-1.40.5, writettf.c in function prepend_subset_tag() the line assert(index > 0... into assert(index >= 0...? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106

1 0

[ pdftex-Bugs-874 ] problem with writettf?
by noreply＠sarovar.org 11 Oct '07

11 Oct '07

Bugs item #874, was opened at 2007-10-11 14:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106 Category: Fonts Group: v1.40.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Hartmut Henkel (hhenkel) Summary: problem with writettf? Initial Comment: Hello I'm using texlive 2007 and encountered the following problem with a truetype font: [...] {/usr/local/apps/texlive-2007/texmf/fonts/enc/ttf2pk/ba se/T1-WGL4.enc}<Auto1-Light.ttfpdflatex: ../../../../texk/web2c/pdftexdir/writettf.c:848: prepend_subset_tags: Assertion `index > 0 && index < name_record_num && fd_cur->subset_tag != ((void *)0)' failed. Upgrading pdftex to 1.40.5 still produces the same error. My previous texlive version (2005 or 2006) didn't have that problem. Replacing Auto1-Light.ttf by another ttf, such as technicn.ttf, does not result in an error. So it's probably related to the Auto1-Light.ttf file itself, but it seems the behaviour of pdftex has changed over the years... Best regards Stefan ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2007-10-11 16:14 Message: Logged In: YES user_id=929 does it go away if you change in pdftex-1.40.5, writettf.c in function prepend_subset_tag() the line assert(index > 0... into assert(index >= 0...? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106

1 0

[ pdftex-Bugs-874 ] problem with writettf?
by noreply＠sarovar.org 11 Oct '07

11 Oct '07

Bugs item #874, was opened at 2007-10-11 14:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106 Category: Fonts Group: v1.40.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Hartmut Henkel (hhenkel) Summary: problem with writettf? Initial Comment: Hello I'm using texlive 2007 and encountered the following problem with a truetype font: [...] {/usr/local/apps/texlive-2007/texmf/fonts/enc/ttf2pk/ba se/T1-WGL4.enc}<Auto1-Light.ttfpdflatex: ../../../../texk/web2c/pdftexdir/writettf.c:848: prepend_subset_tags: Assertion `index > 0 && index < name_record_num && fd_cur->subset_tag != ((void *)0)' failed. Upgrading pdftex to 1.40.5 still produces the same error. My previous texlive version (2005 or 2006) didn't have that problem. Replacing Auto1-Light.ttf by another ttf, such as technicn.ttf, does not result in an error. So it's probably related to the Auto1-Light.ttf file itself, but it seems the behaviour of pdftex has changed over the years... Best regards Stefan ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=874&group_id=106

1 0

increasing max_strings
by David Kastrup 10 Oct '07

10 Oct '07

Hi, because of exceeded TeX capacity, I increased the following limit in the source: svn diff Index: source/src/texk/web2c/tex.ch =================================================================== --- source/src/texk/web2c/tex.ch (Revision 241) +++ source/src/texk/web2c/tex.ch (Arbeitskopie) @@ -200,7 +200,7 @@ @y @d file_name_size == maxint @d ssup_error_line = 255 -@d ssup_max_strings == 262143 +@d ssup_max_strings == 500000 {Larger values than 65536 cause the arrays consume much more memory.} @d ssup_trie_opcode == 65535 @d ssup_trie_size == @"3FFFFF Does anybody know offhand whether I can expect bad effects? After all, why would the ssup-setting not be the maximum possible value? And if there was a reason to set it that way, what other things would I have to change? I ask because the job that was now able to compile produced a corrupt PDF. There can be a number of other reasons for that, but since the run is quite slow, I'd want to have this ruled out if possible. Thanks, -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

2 2

gcc 4.1.2@ubuntu breaks pdftex
by Martin Schröder 08 Oct '07

08 Oct '07

Hi, I (and David) just spend some hours tracking down a compiler bug on Ubuntu 7.04 (gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)): If you compile trunk with build.sh, the resulting binary can not include pdfs (xpdf: reading PDF image failed). If I use my own build.sh, everythings fine. The difference: I set the CFLAGS/CXXFLAGS to -g, while the default is -g -O2. So -O2 breaks pdftex. :-( Best Martin

4 13

Re: [NTG-pdftex] gcc 4.1.2 at ubuntu breaks pdftex
by Akira Kakuto 07 Oct '07

07 Oct '07

Hi Martin, > 2007/10/6, Akira Kakuto <kakuto(a)fsci.fuk.kindai.ac.jp>: > > I'm using the following change on Windows because > > pdftex crashes on Windows 2000 if I use non-argument > > version of GlobalParams(). > > But our patched xpdf provides GlobalParams()... I know that. If GlobalParams() is not provided, a compiler error occurs. The compiling is fine, but the provided one causes the access violation on Windows 2000 in the case of pdf inclusion. I don't know why. Best regards, Akira

1 0

Re: [NTG-pdftex] gcc 4.1.2 at ubuntu breaks pdftex
by Akira Kakuto 06 Oct '07

06 Oct '07

Hi, I'm using the following change on Windows because pdftex crashes on Windows 2000 if I use non-argument version of GlobalParams(). Probably it is not related to the present problem. Best regards, Akira --- pdftoepdf.cc.orig Mon Jul 09 19:10:07 2007 +++ pdftoepdf.cc Sat Oct 06 18:08:37 2007 @@ -678,7 +678,15 @@ float pdf_version_found, pdf_version_wanted; // initialize if (!isInit) { +// +// access violation on Windows 2000 +// in the case of GlobalParams(); +// +#ifdef WIN32 + globalParams = new GlobalParams(0); +#else globalParams = new GlobalParams(); +#endif globalParams->setErrQuiet(gFalse); isInit = gTrue; }

2 1

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 03 Oct '07

03 Oct '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-10-03 20:51 Message: Logged In: YES user_id=421 Fix is in the works. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-01 07:08 Message: Logged In: YES user_id=421 Adding /Group to the /Page is not an option for us (and probably wrong): What should we do when we have more than one included pdf on a page and they have different /CS entries? And why does transparency in an /XObject need an entry in the /Page? The entry in the /XObject should suffice. I wouldn't be surprised if AR is faulty here. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-10-01 02:04 Message: Logged In: YES user_id=4699 After adding /Group << /CS /DeviceRGB /Type /Group /S /Transparency >> to the /Page object in newfile2-1.pdf it displays correctly in Acrobat. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-01 01:04 Message: Logged In: YES user_id=421 The attached file newfile2-1.pdf has a copied page group, which as I now know, should be correct. Still, AR8@Linux shows different colours for it and TestSkizze.pdf . ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:51 Message: Logged In: YES user_id=3168 > Why is this WONTFIX? Sorry, this bug was once closed when this additional info was not available. -> I reopened this bug. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:46 Message: Logged In: YES user_id=3168 Why is this WONTFIX? I mean: > The file TestSkizze.pdf specifies the color blending space > with "/CS /DeviceRGB" in the transparency group. In > the PDF produced by pdftex this has been stripped out. So the bug is that pdftex strips out the color space. If you really think it's WONTFIX, then tell me what is the correct way of specifying the color space so that I can forward this to the Inkscape developers. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-09-30 15:34 Message: Logged In: YES user_id=4699 The file TestSkizze.pdf specifies the color blending space with "/CS /DeviceRGB" in the transparency group. In the PDF produced by pdftex this has been stripped out. When the color space is not specified Acrobat defaults to CMYK. This results in RGB colors being converted to CMYK, blended in CMYK color space, then converted back to RGB. This will produce different results compared to blending the colors in RGB space. This problem was also reported to the cairo list: http://lists.cairographics.org/archives/cairo/2007-September/011471.html ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-03 19:41 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-03 15:48 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 01 Oct '07

01 Oct '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-10-01 07:08 Message: Logged In: YES user_id=421 Adding /Group to the /Page is not an option for us (and probably wrong): What should we do when we have more than one included pdf on a page and they have different /CS entries? And why does transparency in an /XObject need an entry in the /Page? The entry in the /XObject should suffice. I wouldn't be surprised if AR is faulty here. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-10-01 02:04 Message: Logged In: YES user_id=4699 After adding /Group << /CS /DeviceRGB /Type /Group /S /Transparency >> to the /Page object in newfile2-1.pdf it displays correctly in Acrobat. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-01 01:04 Message: Logged In: YES user_id=421 The attached file newfile2-1.pdf has a copied page group, which as I now know, should be correct. Still, AR8@Linux shows different colours for it and TestSkizze.pdf . ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:51 Message: Logged In: YES user_id=3168 > Why is this WONTFIX? Sorry, this bug was once closed when this additional info was not available. -> I reopened this bug. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:46 Message: Logged In: YES user_id=3168 Why is this WONTFIX? I mean: > The file TestSkizze.pdf specifies the color blending space > with "/CS /DeviceRGB" in the transparency group. In > the PDF produced by pdftex this has been stripped out. So the bug is that pdftex strips out the color space. If you really think it's WONTFIX, then tell me what is the correct way of specifying the color space so that I can forward this to the Inkscape developers. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-09-30 15:34 Message: Logged In: YES user_id=4699 The file TestSkizze.pdf specifies the color blending space with "/CS /DeviceRGB" in the transparency group. In the PDF produced by pdftex this has been stripped out. When the color space is not specified Acrobat defaults to CMYK. This results in RGB colors being converted to CMYK, blended in CMYK color space, then converted back to RGB. This will produce different results compared to blending the colors in RGB space. This problem was also reported to the cairo list: http://lists.cairographics.org/archives/cairo/2007-September/011471.html ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-03 19:41 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-03 15:48 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0