October 2007 - ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] 2GB limit and Windows
by Akira Kakuto 31 Oct '07

31 Oct '07

Hi David, > do I understand correctly from the discussions and Svn logs that > PDFTeX is now ready to create large PDF files under GNU/Linux, but the > same can't be said of Windows? Please test the binary of W32TeX (1.50.0-alpha), and teach me the problem. I've used #ifdef WIN32 #include <io.h> void xfseek64 (FILE *f, __int64 offset, int wherefrom, char *filename) { fflush(f); if (_lseeki64(fileno(f), offset, wherefrom) < (__int64)0) FATAL_PERROR(filename); } #endif in void writestreamlength(integer length, longinteger offset) I myself don't have tested the large file. Best regards, Akira

4 4

2GB limit and Windows
by David Kastrup 31 Oct '07

31 Oct '07

Hi, do I understand correctly from the discussions and Svn logs that PDFTeX is now ready to create large PDF files under GNU/Linux, but the same can't be said of Windows? Any idea whether this will change? Would cross-compilation via mingw32 help here? Would the standard way in which executables are compiled for Windows be adaptable? Would there be downloadable binaries at some point of time? Thanks, -- David Kastrup

1 0

LFS
by Martin Schröder 27 Oct '07

27 Oct '07

Hi, trunk can now generate PDFs >2GiB, if you add the right flags to configure (see http://www.suse.de/~aj/linux_lfs.html) This is tested on Linux on amd64 and i386, but I'm interested in reports from other platforms. We will eventually have support for this in configure, but we are not there yet (autofoo ...:-(). Best Martin

1 0

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