- 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