New scribus and PDF size

[Trenien]

I suppose most people here are aware of the problem there is with the size of the pdf files scribus generate. I like the soft, but I must say it has become quite a problem when it comes to make photo books.
In any case, although I haven't seen anything to that effect in the release notes, one can always hope: is there any improvement on that front in the new version?

[a.l.e]

hi trenien,

as far i can tell, there should not be huge issues with creating pdfs for photobooks.

if you have pdfs that are mostly composed by big images and the size of the pdf is bigger than the size of the images you're putting in there, i'm sure that the team will be glad to look at your case.

if you can give more details (and sample files) about the issue you're getting, we can check if the problem is still there in 1.5svn and -- if it is the case -- look for the causes.

have fun!
a.l.e

[GarryP]

Trenien, one thing to add to what a.l.e. said above is that Scribus doesn't trim images to the frames when it creates a PDF. This means that if you show, for example, 10% of an image in a frame, the whole image will be included in the exported PDF and not just the bit that can be seen. This might make it seem that the file is larger than you think it should be.

To get Scribus to make a smaller PDF you can tell it to set a maximum image resolution when you export but for a photo book that's probably not much use (and it can add greatly to the time taken to export).

To paraphrase what a.l.e. said above, if you add up the file sizes of all of the images you're using and that size is much smaller than the PDF size then - unless you're also using loads of other text/vectors/etc. - that's probably a problem that needs to be looked at. On the other hand, if the total image size isn't much smaller than the PDF size then that's to be expected (given what I said earlier).

[GarryP]

Oh, and you probably know this already but it's worth saying for anyone else reading this: If you're using PNGs and they don't need transparency then make sure they haven't got an alpha channel as that can double the size of an image file. (Gimp can remove the alpha channel very easily so it's worth having a look to see if that's an issue.)

[Dogil]

Trenien, one thing to add to what a.l.e. said above is that Scribus doesn't trim images to the frames when it creates a PDF. This means that if you show, for example, 10% of an image in a frame, the whole image will be included in the exported PDF and not just the bit that can be seen. This might make it seem that the file is larger than you think it should be.

oh, that could explain an issue I have with a huge file that doesn't load well in Acrobat (does nicely in any Linux PDF program though). I have many Images which are only shown partly and some of them are rotated a few degrees.

Is there a way to process the PDF so that this data gets purged?

[GarryP]

Dogil, there's a script here: https://wiki.scribus.net/canvas/Image_crop,_resize_and_CMYK_conversion._Save_and_reload_in_TIFF_format that might be of some use but I've never used it myself so I can't say how well it will work (if it does at all).

I think - from what I've heard in the past - that automatic cropping of images is more difficult than it might seem at first glance but I'm not aware of the exact details. Something to do with lots of different formats working differently.

There's also a possible issue where lots of parts of the same image are used in the same document. There could be a chance that the resultant PDF is larger than it would otherwise be if the cropping function isn't clever about what it's doing. I.e. You could end up using, say, ten small images where one slightly larger one would cover what was needed.

All said and done (at the moment) it's best to crop the images yourself - using GIMP or similar - and make sure everything is as you want it rather than hoping that the software will automatically do what you think it should do.

[Nermander]

The major issue with automatic cropping is JPEG images. JPEG images are compressed in blocks (I think 4x4 pixels, but it might be 16x16). If you crop through a block, that block needs to re-compressed (affecting the quality of the image). So cropping needs to be "rounded" to the nearest block border to make it lossless.

I think most other format can be losslessly cropped without problems.

[Dogil]

Dogil, there's a script here: https://wiki.scribus.net/canvas/Image_crop,_resize_and_CMYK_conversion._Save_and_reload_in_TIFF_format that might be of some use but I've never used it myself so I can't say how well it will work (if it does at all).

Thanks, I get the error "Put group string in your language in "stringsDic"." No idea what this means.
Also, from my limited understanding of the python, it seems the script ignores the rotation angle of the images.
This really should be a checkbox in the PDF export dialog, not a script I have to run on every single image of my 300 images in this book.

[Dogil]

as far i can tell, there should not be huge issues with creating pdfs for photobooks.

There is a huge issue with my book. I can't print it because it's not opening properly in Acrobat. I was planning to present this in a week, but it seems impossible. The printshop insists there is a problem with my file.

[a.l.e]

hi dogil,

i believe that you're facing issues with your project.

i had a look at your .sla and created a pdf. it can be read by evince without any issue.

what i noticed, is that it requires two fonts that, probably are never being used. are you including the fonts in the pdf?
(yes, i agree, the should not be required... but: who knows?)

of course, it generates a 600 MB pdf... but if your printer produces photo books, i'm not sure that this is such a huge exception.

as long as the printer does not tell what the problems are (or you don't tell us...) it's almost impossible for me / for us to guess what is going wrong.

once it's clear what the problem is, you're welcome to open a ticket in the scribus bug tracker... but in the current state of the issue, i'm not sure that the programmers can do much for you...

[Dogil]

many thanks for having a look.
About the fonts: I don't know why Scribus always claims that there are fonts used which aren't used actually, but that is not the issue, i have this with all the documents I printed at this printshop.
I also open it on my computer on Linux without any issues. But try opening this in Windows Acrobat and it freezes.
The printer says, he needs to be able to look at the file and scroll through. Right now he needs to wait literally 10 minutes until the page displays, and when he touches the scrollbar it locks up for another 10 minutes.

hi dogil,

i believe that you're facing issues with your project.

i had a look at your .sla and created a pdf. it can be read by evince without any issue.

what i noticed, is that it requires two fonts that, probably are never being used. are you including the fonts in the pdf?
(yes, i agree, the should not be required... but: who knows?)

of course, it generates a 600 MB pdf... but if your printer produces photo books, i'm not sure that this is such a huge exception.

as long as the printer does not tell what the problems are (or you don't tell us...) it's almost impossible for me / for us to guess what is going wrong.

once it's clear what the problem is, you're welcome to open a ticket in the scribus bug tracker... but in the current state of the issue, i'm not sure that the programmers can do much for you...

[a.l.e]

on a mac "preview" opens the pdf with no issue.

not so the adobe acrobat reader...

it looks like, scribus is doing something that adobe does not like... or the malicious would say that adobe is doing it on purpose :-)

i had some doubts... about the images being the culprit...
i've created a new document and pasted there you're first page, then multiplied it 6 times...
preview has some issues displaying the pdf... but it somehow works...
adobe: nah.

i then created a pdf without the first and last pages (you can pick the 2-91 range when exporting): oh wonder, it opens instantly in adobe reader!

next try: ungroup the first page, send the car to the patterns, delete all the page content, insert the care from the patter and multiple duplicate it. copy paste the first page to the last page.
ok, in preview, but still no chance in adobe. (well, this time i could see the first page, but it still was unusable.)

last try: remove all shapes from the first and last pages, insert a full page rectangle, set its background color as a pattern and choose the car you previsously have put in the patterns.
bingo: shows instantly in adobe acrobat reader!

so, i guess that what we could ask scribus to do, is to check what is the difference between duplicating a pattern or using a pattern as a filler...

[a.l.e]

p.s.: so, the supposition that scribus should not have huge issues with photobooks has been confirmed (and there have been a few photobooks done with scribus!)...

[a.l.e]

hey

next time you also open a ticket for your problem, please cross link the forum post and the ticket :-)

https://bugs.scribus.net/view.php?id=14113

[Dogil]

Oh, thank you so much for giving this a try!

Interesting, I haven't done the pattern before. Unfortunately it isn't a perfect pattern (there is a cyclist and a pedestrian hidden amongst the cars) Also the Scribus pattern turned out super blurry and low res in the pdf export.
Anyways, I saved it as a PNG in Inkscape and will bring the file tomorrow like that to the printer. We'll see if it works.

Thanks again!

next try: ungroup the first page, send the car to the patterns, delete all the page content, insert the care from the patter and multiple duplicate it. copy paste the first page to the last page.
ok, in preview, but still no chance in adobe. (well, this time i could see the first page, but it still was unusable.)

last try: remove all shapes from the first and last pages, insert a full page rectangle, set its background color as a pattern and choose the car you previsously have put in the patterns.
bingo: shows instantly in adobe acrobat reader!

so, i guess that what we could ask scribus to do, is to check what is the difference between duplicating a pattern or using a pattern as a filler...