<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1433298472382_238539">Thanks for the replies. I agree that there are many valid reasons for the size. One thing in particular that I have noticed noticed with my compressed versions is that the text is no longer searchable, nor can I copy text from the compressed versions. However, for normal printing either on my own printer or by using commercial copy centres, I have been unable to see any difference in quality between the original and the compressed version. </div><div id="yui_3_16_0_1_1433298472382_238539" dir="ltr"><br></div><div id="yui_3_16_0_1_1433298472382_238539" dir="ltr">As for the comment by Peter </div><div id="yui_3_16_0_1_1433298472382_238539" dir="ltr">"<i id="yui_3_16_0_1_1433298472382_238944">So my opinion is of course that if you think the the files created by Scribus are to big, maybe you are using the wrong tool?</i>"<br></div><div id="yui_3_16_0_1_1433298472382_238539"><br></div><div id="yui_3_16_0_1_1433298472382_238539">Scribus is a very powerful and useful tool which I have now been using regularly since about 2008. I am never printing much more than 100 copies, so offset printing is not really an economical option. For me personally, using the script I mentioned (and someone form our LINUX users group has now kindly modified it to remove the .meta file and to provide a -r option to replace the original file with the compressed one) is quite an acceptable solution the file size issue. </div><div id="yui_3_16_0_1_1433298472382_238539"><br></div><div id="yui_3_16_0_1_1433298472382_238539">Since some of the things I produce have lots of high resolution photographs, that is likely a contributing factor to the large size of the original. </div><div id="yui_3_16_0_1_1433298472382_238539"><br></div><div id="yui_3_16_0_1_1433298472382_238539" dir="ltr">I will look at the settings suggested below, but I may not want to get into that for the beginner level course that I am currently teaching.</div><div id="yui_3_16_0_1_1433298472382_238539"><br></div><div id="yui_3_16_0_1_1433298472382_238539" dir="ltr">I am not in any way criticizing the normal PDF output of Scribus, nor suggesting that it be changed. Nor do I need the feature I am requesting for my own work. I just think it would be very useful for those who want to use it to make posters, newsletters, greeting cards, photo books, etc. and find that the normal output is too large to E-Mail to a copy centre for printing.</div><div id="yui_3_16_0_1_1433298472382_238539" dir="ltr"><br></div><div id="yui_3_16_0_1_1433298472382_238539" dir="ltr">I especially appreciate all of the fine work that has been done, and continues in the development of this great software. I also greatly appreciate the help I have received in the past from contributors to this list.</div><div id="yui_3_16_0_1_1433298472382_238539" dir="ltr"><br></div><div id="yui_3_16_0_1_1433298472382_238539" dir="ltr">Murray</div><div id="yui_3_16_0_1_1433298472382_238539"><br></div><div id="yui_3_16_0_1_1433298472382_238539"><br></div><div id="yui_3_16_0_1_1433298472382_238539">-------------------------------------------------------------------------------------------</div><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_1_1433298472382_238534"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_1_1433298472382_238533"><div class="y_msg_container" id="yui_3_16_0_1_1433298472382_238563"> 3. Scribus feature request--produce compressed PDF output<br> (Murray Strome)<br> 4. Re: Scribus feature request--produce compressed PDF output<br> (Gregory Pittman)<br> 5. Re: Scribus feature request--produce compressed PDF output<br> (Peter Nermander)<br> 6. Re: Scribus feature request--produce compressed PDF output<br> (Thorsten Rochelmeyer)<br> 7. Re: Scribus feature request--produce compressed PDF output<br> (Rolf-Werner Eilert)<br>-------------- next part --------------<br><br><br>I am teaching Scribus to several people, most of whom use Microsoft Windows. In my own experience over the years, I have found that the PDF files created by Scribus are very large. I normally do my own work in LINUX, and have found a workflow to create compressed PDF files which works fine for me, but would not be suitable for most of the students in my class, as none of them use LINUX nor are they at all familiar with working with Scripts. The ideal solution would be to have an option within Scribus when creating a PDF file to produce either full or compressed version. An acceptable alternative would be to have a separate GUI based program to run the script in Windows as well as Mac and LINUX. The Script I use to do the job is a slightly modified version of the Perl script, compress_newsletter.pl, the original for which can be found here:<a href="http://wiki.scribus.net/canvas/Web_optimised_PDF" target="_blank" id="yui_3_16_0_1_1433298472382_238627">http://wiki.scribus.net/canvas/Web_optimised_PDF</a>(I don't think the original works any more).I have attached the script I use as a text file called compress_newsletter.pl.txt -- remove the ".txt" and make it executable to run. I was not permitted to attach it with the .pl extension.My normal work-flow is to run the script:compress-newsletter.pl {original file name}.pdf<br>the result is {original file name}.new.pdf<br>The script cleans up a lot of the temporary files it creates, but does leave a file {original file name}.meta, which really should be deleted within the script (I delete it manually).<br>Normally, I then do:rm {original file name}.pdfmv {original file name}.new.pdf {original file name}.pdf<br>It would be nice if the script were modified so thata) the meta file is removed automaticallyb) an option would be to replace the original file. I would suggest that running it without any option would leave both files, but doing:<br><br>compress-newsletter.pl -r {original file name}.pdf<br>would result in the original file be replaced.<br>----------<br>Now comes the more interesting challenge:<br>As I mentioned earlier, virtually all of the people attending my Scribus training are using Windows and have relatively limited computer skills. It would be great to have a GUI to run this script in Windows to accomplish this task, or better yet, to have the functionality built into Scribus<br>Anyone interested in the challenge of creating something like this (it would be even nicer if it would run in LINUX and OS-X)?<br>Thanks.<br> <br>-------------- next part --------------<br><br><br><br>Here is something worth looking at:<br><br><a href="http://wiki.scribus.net/canvas/Image_DPI_and_Scaling,_and_Resultant_File_Sizes" target="_blank">http://wiki.scribus.net/canvas/Image_DPI_and_Scaling,_and_Resultant_File_Sizes</a><br><br>What it shows are some methods to reduce PDF size simply by various<br>settings for images. In many cases, I think users will load a huge image<br>file into Scribus, and because they make its dimensions small in<br>Scribus, they think the data has shrunk. It hasn't.<br><br>I think much of the bulk in PDFs can be traced to images. Pure text PDFs<br>from Scribus are not that big.<br><br>Greg<br><br>-------------------<br>There are valid reason for the size.<br><br>First and foremost, Scribus was created to be used to design for print (as<br>in printing magazines, books etc, not printing on your office laser<br>printer). A PDF for print has higher requirements than a PDF for<br>"distribution". In the printing industry large files are normal, the<br>printing industry was one of the major users of Iomega Zip drives (before<br>CD-RW became common), because of their need to transfer large files. I<br>think even today many printers accept originals on Zip disks.<br><br>One of the main reasons for the large size of a Scribus PDF is that each<br>glyph is placed by its own. Most other programs place the cursor at the<br>start of the line and print whole words or lines, but Scribus will place<br>the cursor accurately for each glyph. This means the PDF will contain A LOT<br>of cursor placement commands, and they occupy space.<br><br>Second, an embedded Open Type font can be 15-30 MB in size, a document with<br>10 embedded fonts will thus have 150-300 MB of fonts in it. And remember,<br>regular and bold counts as two fonts, since Scribus does not use "fake<br>bold".<br><br>And as Greg mentioned, high resolution images is of course one major<br>contributor to large files for printing.<br><br>So my opinion is of course that if you think the the files created by<br>Scribus are to big, maybe you are using the wrong tool?<br><br>It's not really the fault of the Scribus or its developers that there are<br>so few other programs for creating "simpler" PDF documents, but at least<br>Open/Libre Office can export directly to PDF and I think they are generally<br>smaller.<br><br><br>/Peter<br>-------------- next part --------------<br><br>Am 03.06.2015 um 21:10 schrieb Murray Strome:<br>> It would be great to have a GUI to run this script in Windows to accomplish this task, or better yet, to have the functionality built into Scribus<br>><br>In my experience it is helpful to open the scribus-generated PDF with a<br>viewer of your choice and then print it to PDF from there (using<br>different filename of course). Resulting PDF is usually much smaller -<br>somewhere between 10% and 30% of the original filesize.<br>This works with Linux / KDE / Okular - not sure if you can expect the<br>same results in a windows environment with acrobat.<br><br>Thorsten<br><br><br><br><br>Am 04.06.2015 07:29, schrieb Peter Nermander:<br>> I am teaching Scribus to several people, most of whom use Microsoft<br>>> Windows. In my own experience over the years, I have found that the PDF<br>>> files created by Scribus are very large. I<br>>><br>> There are valid reason for the size.<br>><br><br>While this is certainly all very true, there remain yet a lot of cases <br>where the user does not publish for a professional offset printer but <br>for use in the net etc. or at least does so in parallel.<br><br>For those cases it would be extremely useful if Scribus would offer such <br>a solution out of itself. An appropriate location might be the "Output <br>for" option list in the PDF making dialogue. When I choose "for <br>monitor/Internet", I would actually expect Scribus to do just this: Not <br>setting each glyph separately but linewise, not including whole font <br>sets but excerpts or just the glyphs used, automagically reducing image <br>resolutions etc. so that it produces a small RGB pdf file which can be <br>published over the net - e. g. some handbook or whatever. Then I can <br>choose "For printer", and I get CMYK and each glyph separately etc. for <br>my offset printing service. Of course one might think about something in <br>between the two with higher resolution images for the colour home <br>printer machine.<br><br>The "only" thing that pops up in my mind for realizing this would be <br>that there should be some interface from the canvas to the outside that <br>allows for tapping the linewise text instead of glyph-wise one. But the <br>coders should know better here. IMHO there is a connection already: it <br>goes into the editor, doesn't it?<br><br>Regards<br><br>Rolf<br><br></div> </div> </div> </div></body></html>