Is there a limit to the size of PDF files?

newer
Re: [NTG-pdftex] [tex-live] pdfTeX...

older
[ pdftex-Bugs-877 ] PDFs limited...

Akira Kakuto

17 Oct 2007 17 Oct '07

3:41 p.m.

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

Show replies by date

David Kastrup

17 Oct 17 Oct

3:49 p.m.

Akira Kakuto writes:

...

...
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.

In Linux/glibc, I find The fseeko() and ftello() functions are identical to fseek() and ftell() (see fseek(3)), respectively, except that the offset argument of fseeko() and the return value of ftello() is of type off_t instead of long. On many architectures both off_t and long are 32-bit types, but compilation with #define _FILE_OFFSET_BITS 64 will turn off_t into a 64-bit type. Is there something like this to be had in MSVC++? Is MSVC++ obligatory for compiling PDFTeX in win32? -- David Kastrup

Martin Schröder

3:56 p.m.

2007/10/17, David Kastrup :

...

Is there something like this to be had in MSVC++? Is MSVC++ obligatory for compiling PDFTeX in win32?

I don't know about win32, but the size of PDFs is limited to 10GiB. If we can't easily fix the 2G limit on win32, we should at least fix the error message. Best Martin

Taco Hoekwater

3:57 p.m.

David Kastrup wrote:

...

Is there something like this to be had in MSVC++? Is MSVC++ obligatory for compiling PDFTeX in win32?

Have you tried already whether a pdf > 2GB can be opened by your target audience? If not, there is not much point in investigating further. Best wishes, Taco

David Kastrup

4 p.m.

Taco Hoekwater writes:

...

David Kastrup wrote:

...
Is there something like this to be had in MSVC++? Is MSVC++ obligatory for compiling PDFTeX in win32?

Have you tried already whether a pdf > 2GB can be opened by your target audience?

Presumably not a problem. But I have to search for other venues, anyway, since binary replacement is not feasible right now in this project. And frankly, 2GB for a 150 page document is ridiculous.

...

If not, there is not much point in investigating further.

Maybe. -- David Kastrup

Martin Schröder

4:54 p.m.

2007/10/17, David Kastrup :

...

Taco Hoekwater writes:

...
Have you tried already whether a pdf > 2GB can be opened by your target audience?

Presumably not a problem. But I have to search for other venues, anyway, since binary replacement is not feasible right now in this project. And frankly, 2GB for a 150 page document is ridiculous.

AR8@Linux can not open files >2GB (I just tested). Best Martin

Martin Schröder

5:05 p.m.

2007/10/17, Martin Schröder :

...

AR8@Linux can not open files >2GB (I just tested).

And pdfTeX@Linux will happily produce files >2G, but these are broken: The byte offset for objects is only 32bit and wraps around. :-( Best Martin

Martin Schröder

5:29 p.m.

2007/10/17, Martin Schröder :

...

And pdfTeX@Linux will happily produce files >2G, but these are broken: The byte offset for objects is only 32bit and wraps around. :-(

It works if you are on a 64bit plattform and compile with -DNO_DUMP_SHARE (see texk/web2c/config.h). Best Martin

David Kastrup

6:01 p.m.

"Martin Schröder" writes:

...

2007/10/17, David Kastrup :

...
Taco Hoekwater writes:

...
Have you tried already whether a pdf > 2GB can be opened by your target audience?

Presumably not a problem. But I have to search for other venues, anyway, since binary replacement is not feasible right now in this project. And frankly, 2GB for a 150 page document is ridiculous.

AR8@Linux can not open files >2GB (I just tested).

Actually, I just discovered \pdfobjcompresslevel. Maybe we will get this circumnavigated. -- David Kastrup

Reinhard Kotucha

6:59 p.m.

David Kastrup writes:

...

Actually, I just discovered \pdfobjcompresslevel. Maybe we will get this circumnavigated.

Don't expect too much if there are many graphics. They are compressed already and take most of the space. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

David Kastrup

7:13 p.m.

Reinhard Kotucha writes:

...

David Kastrup writes:

...
Actually, I just discovered \pdfobjcompresslevel. Maybe we will get this circumnavigated.

Don't expect too much if there are many graphics. They are compressed already and take most of the space.

Given their size, they can't be compressed all too much (5 to 10MB PDF per piece, presumably generated by Imagemagick). I already wrote a ticket for replacing Imagemagick with sam2p (I guess I trust Peter more about squeezing size), but I don't know whether my guesses about which does what in image preprocessing are correct. -- David Kastrup

Hartmut Henkel

9:19 p.m.

On Wed, 17 Oct 2007, Reinhard Kotucha wrote:

...

David Kastrup writes:

...
Actually, I just discovered \pdfobjcompresslevel. Maybe we will get this circumnavigated.

Don't expect too much if there are many graphics. They are compressed already and take most of the space.

... and any kind of stream objects are not touched at all by object compression. The \pdfobjcompresslevel affects only objects that are pure dictionaries. Regards, Hartmut

6281

Age (days ago)

6281

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Akira Kakuto
David Kastrup
Hartmut Henkel
Martin Schröder
Reinhard Kotucha
Taco Hoekwater