> Usable color management is a major leap for any open source app. I'll second that, and then some. It's perhaps the most critical difference between being able to do 'my sports club newsletter' and 'my colour newspaper' IMHO.
> That is > not trivial. I might add there is more than can be done with the color > management stuff. The newest lcms 1.10 and 1.11 have a lot of work done > for optimizing color managed printing including new bits for controlling > ink limits, black point compensation and other subtle tricks. Oooh... does it have support for ink bleed controls? As I'm in newspaper print, I have to deal with 0.30 bleed, which is pretty horrible. For good colour photo printing etc the CMS must understand ink weight limits (we're limited to 80% black) and bleed. > Hence, HP > has sponsored littlecms in their last couple of releases. It says a lot > when the largest printer company in the world sponsors your open source > project. Anybody else seeing some potential CMS benefits to the hpijs driver collection? I bet HP would love to be able to say "If you're doing DTP under linux, HP printers are the only ones that can give accurate colour managed printing." > Crop marks - I have discussed this with Franz and sent some sample > postscript code, but this is where someone like your colleague can help. Interesting. We just moved away from using crop marks and registration - our printers now want a clean white 10mm border around all PDFs, and that's it. I gather that their new RIP and print process no longer needs or wants them, and is smart enough to do the registration properly from the page borders. > One thing that is important to say if it is not obvious is Franz has put > a lot of effort into optimizing PDF output of Scribus. When Franz > started Scribus I knew this was a good idea, but I did not know then how > *really* good it was. Having a solid PDF exporter has allowed Scribus > to overcome most all of of potential issues with Linux and open source > apps in the DTP world. I can't agree enough. I could, tomorrow, do a page of the newspaper I work for using Scribus under linux and the printers would print it quite happily. In fact, I doubt they'd notice the change. So long as it's a standard PDF that fits their specs, they don't care. The move of commercial publishing from QuarkXPress to PDF as the print file standard really opens up the market, and Scribus is getting right into it when the going is good. I'll be doing a few house ads in Scribus soon, using one on the inside pages of the paper, and seeing how we go. If that works out OK, it'll be time to test a colour house ad or two. > Given its rapid growth, it is not hard for me to imagine as Scribus > matures, when one could use Scribus as the main production app for this > magazine. Already, I am replicating content for test printing and really > do not expect any issues with Scribus files in the work flow. My only serious concern currently is the raster PDF and EPS import, and it's tendancy to result in very large output PDFs. Even then, nothing would stop us doing ads in Scribus, since we don't need to import big PDFs or EPSes for that. I have a few concerns based on reports on the list about text-box linking and reflow issues, but that also doesn't matter for ad layout. Basically, I don't think I could use it for final pages, but could probably do ads in it now. I'll be having a play to see. Craig Ringer
