Two essentials for publishing users.
Inkscape needs two more features for publishing. First, the CMYK color model needs to be a real option. ImageMagick will convert an svg file to CMYK but that means going from vector to bitmap.
Second, there should be an option for PDF output in PDF X/1-a format to satisfy the largest POD printer, Lightning Source Inc. (LSI). Currently my only path is to import all or part of a cover image into Scribus 1.5.0 (development version) and save it from there.
Two requests from the trenches.
Feature requests really need to be made in our bug tracker and they will be flagged as wishlist.
https://bugs.launchpad.net/inkscape
Cheers, Josh
On Tue, 2010-09-14 at 11:19 -0400, John Culleton wrote:
Inkscape needs two more features for publishing. First, the CMYK color model needs to be a real option. ImageMagick will convert an svg file to CMYK but that means going from vector to bitmap.
Second, there should be an option for PDF output in PDF X/1-a format to satisfy the largest POD printer, Lightning Source Inc. (LSI). Currently my only path is to import all or part of a cover image into Scribus 1.5.0 (development version) and save it from there.
Two requests from the trenches.
Hello John,
thank you for your comments.
Despite the CMYK that is not present in the generated pdf, what are you missing on the generated pdf?
Regards,
the Adib.
On Tue, Sep 14, 2010 at 5:19 PM, John Culleton <john@...1202...> wrote:
Inkscape needs two more features for publishing. First, the CMYK color model needs to be a real option. ImageMagick will convert an svg file to CMYK but that means going from vector to bitmap.
Second, there should be an option for PDF output in PDF X/1-a format to satisfy the largest POD printer, Lightning Source Inc. (LSI). Currently my only path is to import all or part of a cover image into Scribus 1.5.0 (development version) and save it from there.
Two requests from the trenches.
John Culleton Wexford Press "Create Book Covers with Scribus" Printable E-book 38 pages $5.95 http://www.booklocker.com/books/4055.html
Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Sep 14, 2010 at 12:19 PM, John Culleton <john@...1202...> wrote:
Inkscape needs two more features for publishing. First, the CMYK color model needs to be a real option. ImageMagick will convert an svg file to CMYK but that means going from vector to bitmap.
Second, there should be an option for PDF output in PDF X/1-a format to satisfy the largest POD printer, Lightning Source Inc. (LSI). Currently my only path is to import all or part of a cover image into Scribus 1.5.0 (development version) and save it from there.
Since we use Cairo, this format should ideally be added as an option to Cairo's PDF backend. And if we want CMYK output in PDF, we need Cairo support for that as well. If it's done, it will benefit not only Inkscape but other cairo-using apps as well.
2010/9/14 John Culleton <john@...1202...>:
Inkscape needs two more features for publishing. First, the CMYK color model needs to be a real option. ImageMagick will convert an svg file to CMYK but that means going from vector to bitmap.
Here's a thing I don't understand. Most print shops want CMYK documents. Logically, if correct color reproduction is the objective, they should accept either RGB documents with an ICC profile for your monitor, or CMYK documents with the ICC profile of their printing equipment. But they usually don't provide any profile, and some of them explicitly discourage sending RGB+ICC.
Can color management incompetence be so widespread in the publishing world that even professionals treat CMYK as a magic switch that makes the colors better (even though in theory it can't, but sometimes does so in practice because of luck)? Or is there some special aspect of using CMYK that I don't understand?
Regards, Krzysztof
2010/9/15 Krzysztof Kosiński wrote
Logically, if correct color reproduction is the objective, they should accept either RGB documents with an ICC profile for your monitor
You say *that* and then you discuss someone else's color management incompetence? No way Jose :) What use would be for someone to have your monitor's profile? :)
In reality press bureaus differ from each other. Some demand already separated files. Some want to do separation themselves. Some will even ask for source documents like Corel's CDRs or Adobe's AIs. Or Quark XPress documents, with fonts (I really mean it).
Or is there some special aspect of using CMYK that I don't understand?
This aspect is called it-is-me-who-decides-how-to-get-my-job-done :)
The point of working with CMYK natively is that you
a) immediately see what your print is going to look like and b) can tweak things right away.
CMYK is not the only holy grail. There are other features like [1] and [2] that some people like to delegate to press bureaus even though you are going to see lots and lots of users who in their *real* life have to deal with different press bureaus and have different workflows supported.
The world of printing is a mess. You can't change it. Saying "Uh. Oh. This is wrong, we won't do it." is not going to make users happy, because it won't help them to get their job done.
[1] http://en.wikipedia.org/wiki/Trap_%28printing%29 [2] http://en.wikipedia.org/wiki/Imposition
Alexandre Prokoudine http://libregraphicsworld.org
2010/9/15 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
You say *that* and then you discuss someone else's color management incompetence? No way Jose :)
Let's try harder to avoid personal attacks. I think Krzysztof's question is perfectly legitimate.
What use would be for someone to have your monitor's profile? :)
The profile provides a mapping from the colors in document to the device-independent colors, which the printer will then be able to convert to its own device-specific print colors. What's wrong with that?
In reality press bureaus differ from each other. Some demand already separated files. Some want to do separation themselves. Some will even ask for source documents like Corel's CDRs or Adobe's AIs. Or Quark XPress documents, with fonts (I really mean it).
If anything, this rather strengthens Krzysztof's suggestion that ignorance and blindly following the hard-learned ways play a surprisingly large role in printers' practices and requirements.
The point of working with CMYK natively is that you
a) immediately see what your print is going to look like and
This is an illusion. Different printers will still print your CMYK file differently. Generic CMYK preview is only barely useful: it will warn you about some wildly out-of-gamut colors, but that's all. Other than that, producing a CMYK without a target profile is an exercise in futility - and it's doubly frustrating that so many print providers routinely expect you to do exactly this.
The world of printing is a mess. You can't change it. Saying "Uh. Oh. This is wrong, we won't do it." is not going to make users happy, because it won't help them to get their job done.
I fully agree that it is a mess. But I reject your attitude. On the contrary, saying loudly and clearly what's messy and wrong, and ahy, can't be but beneficial for everyone involved.
On Wed, Sep 15, 2010 at 7:20 PM, bulia byak wrote:
What use would be for someone to have your monitor's profile? :)
The profile provides a mapping from the colors in document to the device-independent colors
*sigh*
No, it doesn't, the reason being -- there is a universe large difference between monitor's profile color space and a working color space. With current design colors in documents are defined via Document Properties > CMS and picked in CMS tab of Fill'n'Stroke dialog.
The point of working with CMYK natively is that you
a) immediately see what your print is going to look like and
This is an illusion. Different printers will still print your CMYK file differently. Generic CMYK preview is only barely useful: it will warn you about some wildly out-of-gamut colors, but that's all. Other than that, producing a CMYK without a target profile is an exercise in futility - and it's doubly frustrating that so many print providers routinely expect you to do exactly this.
Who said that one doesn't have a target profile? :)
The world of printing is a mess. You can't change it. Saying "Uh. Oh. This is wrong, we won't do it." is not going to make users happy, because it won't help them to get their job done.
I fully agree that it is a mess. But I reject your attitude. On the contrary, saying loudly and clearly what's messy and wrong, and ahy, can't be but beneficial for everyone involved.
Well, rejecting my attitude won't help our users either :) As well as just supporting it :)
Absence of color separated PDF exporting is a deal breaker for gazillions of Inkscape users. You don't have to like it. Just accept it.
Alexandre Prokoudine http://libregraphicsworld.org
On Wed, Sep 15, 2010 at 12:32 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
The profile provides a mapping from the colors in document to the device-independent colors
*sigh*
No, it doesn't, the reason being -- there is a universe large difference between monitor's profile color space and a working color space.
What you're saying is that the user's display does not match the display profile he's indicating for his documents. Yes, this is common, but at least this is a problem a user is perfectly able to fix, by calibrating his display and/or creating a custom display profile. What's important is that this is something you can do on your own, without any knowledge or access to the printer or its profile.
And in any case, from my experience, differences between RGB profiles are generally much smaller than between CMYK profiles of different printers, and the need to calibrate displays is now much less than it was in the era or CRT monitors. So even if the user neglects all this and simply sends his document assuming standard sRGB, the potential color mismatch in printing is going to be smaller than if the same user, disquieted by "experts" claiming he "must" produce CMYK, creates some random-profile CMYK file and sends that instead.
Absence of color separated PDF exporting is a deal breaker for gazillions of Inkscape users. You don't have to like it. Just accept it.
I don't have to "accept" it if it can be dealt with differently and quite satisfactorily in a lot of cases. So many times I heard from someone, "Hey, can you make it a CMYK file, I heard that will make it print better", but got only a blank stare when I asked them for the printer profile.
On Wed, Sep 15, 2010 at 8:31 PM, bulia byak wrote:
*sigh*
No, it doesn't, the reason being -- there is a universe large difference between monitor's profile color space and a working color space.
What you're saying is that the user's display does not match the display profile he's indicating for his documents.
No, this is absolutely not what I'm saying. If I said anything like this I'd live in shame to the end of my days, abandoned by friends and family. Nobody would come to my burial.
There is no point whatsoever to assign a monitor's ICC profile to a document. When it comes to RGB, you work in a widegamut color space. This has been best practice ever since dinosaurs ruled the world. In fact I do believe that trilobites were first to use AdobeRGB 1998, before T-rex came some dozen of millions years later with ProPhotoRGB and other fancy stuff :)
Absence of color separated PDF exporting is a deal breaker for gazillions of Inkscape users. You don't have to like it. Just accept it.
I don't have to "accept" it if it can be dealt with differently and quite satisfactorily in a lot of cases.
The point is that currently it can't.
Alexandre Prokoudine http://libregraphicsworld.org
On Wed, Sep 15, 2010 at 8:20 AM, bulia byak - buliabyak@...400... wrote:
The world of printing is a mess. You can't change it. Saying "Uh. Oh. This is wrong, we won't do it." is not going to make users happy, because it won't help them to get their job done.
I fully agree that it is a mess. But I reject your attitude. On the contrary, saying loudly and clearly what's messy and wrong, and ahy, can't be but beneficial for everyone involved.
Actually just saying it is a mess and discussing it comes up a bit short of what really CAN be done:
1) Someone who feels sufficiently competent, write a hint that describes an intelligent approach to using RGB, CMYK, and ICC in a work flow. 2) Each person who has access to the hint and regularly uses the same print service could discuss with someone at the service what they mutually know about implementing such a work flow. 3) After said discussion, perhaps the printer could be persuaded to publish the work flow, or their local modification, to their public web presence. This need not be the front page or any page that is readily found, but somewhere a customer who understands the issue could be directed so the shop and the customer could bring their work flows together.
If this is done often enough, the knowledge will become "Common".
On Wed, Sep 15, 2010 at 7:43 PM, inkscape-devel.neophyte_rep wrote:
Actually just saying it is a mess and discussing it comes up a bit short of what really CAN be done:
- Someone who feels sufficiently competent, write a hint that
describes an intelligent approach to using RGB, CMYK, and ICC in a work flow. 2) Each person who has access to the hint and regularly uses the same print service could discuss with someone at the service what they mutually know about implementing such a work flow. 3) After said discussion, perhaps the printer could be persuaded to publish the work flow, or their local modification, to their public web presence. This need not be the front page or any page that is readily found, but somewhere a customer who understands the issue could be directed so the shop and the customer could bring their work flows together.
If this is done often enough, the knowledge will become "Common".
Amen to that :) Any takers?
Alexandre Prokoudine http://libregraphicsworld.org
On Wednesday 15 September 2010 11:50:18 Alexandre Prokoudine wrote:
On Wed, Sep 15, 2010 at 7:43 PM, inkscape-devel.neophyte_rep wrote:
Actually just saying it is a mess and discussing it comes up a bit short of what really CAN be done:
- Someone who feels sufficiently competent, write a hint that
describes an intelligent approach to using RGB, CMYK, and ICC in a work flow. 2) Each person who has access to the hint and regularly uses the same print service could discuss with someone at the service what they mutually know about implementing such a work flow. 3) After said discussion, perhaps the printer could be persuaded to publish the work flow, or their local modification, to their public web presence. This need not be the front page or any page that is readily found, but somewhere a customer who understands the issue could be directed so the shop and the customer could bring their work flows together.
If this is done often enough, the knowledge will become "Common".
Amen to that :) Any takers?
Alexandre Prokoudine http://libregraphicsworld.org
----------- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
The physical printing press will either use spot colors or the process colors of CMYK. That is the target. That is how modern printing presses work. They mix those four colors and not Red Green and Blue. So I suggest:
1. Use CMYK from the beginning to develop a print document. This gets around the smaller gamut problem.
2. For exact colors don't depend on a monitor representation, calibrated or no. Take the CMYK values and look them up on e.g. Galaxy Color Gauge Color Pro. This still won't be "exact exact" but it will be the closest you can get without having the printer produce a proof copy.
As my father used say, don't fight the problem. Printing presses use process colors AKA CMYK. Work backwards from that.
The software products Photoshop, Scribus, Krita, InDesign, TeX, Open Office etc. all can work in and produce a pdf file with CMYK generated colors. So they solve the problem insofar as it can be solved. Inkscape needs to be added to that group IMO.
On Wed, Sep 15, 2010 at 1:29 PM, John Culleton <john@...1202...> wrote:
- Use CMYK from the beginning to develop a print document. This gets
around the smaller gamut problem.
That is achievable through softproofing, which already works in Inkscape. But again, it works best when you can use the specific profile of the target printer.
- For exact colors don't depend on a monitor representation,
calibrated or no. Take the CMYK values and look them up on e.g. Galaxy Color Gauge Color Pro. This still won't be "exact exact" but it will be the closest you can get without having the printer produce a proof copy.
As my father used say, don't fight the problem. Printing presses use process colors AKA CMYK. Work backwards from that.
My impression is that the really smart printing presses do make their print profiles available, so that users can softproof their work and correct gamut problems, but then still accept art it RGB and do separation themselves, if only because there are many many gotchas in this process, often idiosyncratic to the specific printer, which the user is unlikely to get right without the right experience.
Of course I'm not arguing against adding CMYK to PDF export, there are lots of legitimate uses for that. I just don't think it's as "absolute" prerequisite for professional printing as many make it out to be.
On Wed, Sep 15, 2010 at 8:47 PM, bulia byak wrote:
Of course I'm not arguing against adding CMYK to PDF export, there are lots of legitimate uses for that.
Then what are we arguing about? :)
I just don't think it's as "absolute" prerequisite for professional printing as many make it out to be.
The thing is, when you settle down and start business, you deal with a limited amount of printing companies, because you want reliable service, no surprises. But workflows you get used to don't necessarily are the same everywhere.
Alexandre Prokoudine http://libregraphicsworld.org
Can we try this again?
Who, among those active in this thread, actually produces Inkscape data for printing on a regular basis? What does your print service know about this issue? (Assuming you've asked, of course.)
Who, among those lurking, is a printer who understands the issue being discussed? Would you be willing to publish a work flow that you would find technically competent?
On 15 September 2010 19:17, <inkscape-devel.neophyte_rep@...2295...> wrote:
Can we try this again?
Who, among those active in this thread, actually produces Inkscape data for printing on a regular basis?
I must say I don't. I am satisfied with screen output or color laser printouts without color matching if I want some text with color diagrams for reading offline.
What does your print service know about this issue? (Assuming you've asked, of course.)
When it comes to small print services operating on tight budget I can imagine they know next to nothing, or that not all of the staff is competent.
The requirement to send CMYK PDF as input is then something I would understand. If you send a CMYK PDF tagged with the correct profile they can see that as a proof that you checked what the printout will look like. You can't say there was a gradient in the picture you sent and it's flat in the printout, it will be exactly what you sent, and they don't guarantee more.
Especially they won't send/show you previews, do test prints, etc. because it costs money for material and/or salary and they would be more expensive than competition if they did.
If they are really incompetent they can even require it just because everybody else does.
Note that this is all mostly speculation but I have seen a print shop with no competent staff and heard quite a bit of complaints from people who actuall try to get things printed. Obviously this would also vary in different places.
I guess it all comes to picking the right print shop for the job. Pick any two: fast, good, cheap.
Thanks
Michal
On Wednesday 15 September 2010 13:53:11 Michal Suchanek wrote:
On 15 September 2010 19:17,
<inkscape-devel.neophyte_rep@...2295...> wrote:
Can we try this again?
Who, among those active in this thread, actually produces Inkscape data for printing on a regular basis?
I must say I don't. I am satisfied with screen output or color laser printouts without color matching if I want some text with color diagrams for reading offline.
What does your print service know about this issue? (Assuming you've asked, of course.)
When it comes to small print services operating on tight budget I can imagine they know next to nothing, or that not all of the staff is competent.
The requirement to send CMYK PDF as input is then something I would understand. If you send a CMYK PDF tagged with the correct profile they can see that as a proof that you checked what the printout will look like. You can't say there was a gradient in the picture you sent and it's flat in the printout, it will be exactly what you sent, and they don't guarantee more.
Especially they won't send/show you previews, do test prints, etc. because it costs money for material and/or salary and they would be more expensive than competition if they did.
If they are really incompetent they can even require it just because everybody else does.
Note that this is all mostly speculation but I have seen a print shop with no competent staff and heard quite a bit of complaints from people who actuall try to get things printed. Obviously this would also vary in different places.
I guess it all comes to picking the right print shop for the job. Pick any two: fast, good, cheap.
Thanks
Michal
----------- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Let's work backward again. To sell a book you need to have it on Amazon and available to other online bookstores. The most cost- effective way to do that is to print it via LSI and set a discount of 20%. That way you have no inventory cost and no shipping costs. As books are sold Amazon will replenish their stock. As books are sold Amazon will pay the publisher.
LSI wants either a tiff or a PDF file for the cover. In PDF the file should be in the format PDF X/1-a. If not they will preprocess it, rasterize it and probably degrade the appearance of text and bar codes. PDF X/1-a doesn't allow for RGB.
Fellows and gals, I just didn't make all this up. Those of us in the world of self and small publishers have wrestled with these problems for years and came up with the above minimally acceptable solution, not because we love LSI but because Amazon won't deal with individual publishers at anything like a reasonable discount. You can indeed use Amazon Advantage, maintain a stock of books at Amazon, pay for shipping and, oh yes, give Amazon a 55% discount.
To get on Amazon etc. at a reasonable profit level one has to use LSI. To use LSI and have a decent looking cover without double rasterization you have to give them a pdf X/1-a file. They really prefer if you use Acrobat distiller but thus far I have gotten away with files exported from Scribus 1.5.0, the bleeding edge version which features PDF X/1-a export.
You don't get to pick other printers. Createspace (Amazon subsidiary) wants 40% discount. Other printers have no direct entree into Amazon.
So that is the problem situation. It must be LSI and if it is LSI it must be PDF X/1-a.
Let's work on the solution for Inkscape, shall we?
On Wed, Sep 15, 2010 at 3:24 PM, John Culleton <john@...1202...> wrote:
So that is the problem situation. It must be LSI and if it is LSI it must be PDF X/1-a.
Let's work on the solution for Inkscape, shall we?
Like I said, it's rather unlikely that this will be a "solution for inkscape" only. We have purged our own PDF exporter in favor of cairo's. Since it would be better to avoid reinventing the wheel, maybe Scribus devels can help Cairo devs add this format to their PDF backend, or otherwise make their PDF code usable for cairo-using apps.
bulia byak wrote the following on 9/15/2010 2:40 PM:
On Wed, Sep 15, 2010 at 3:24 PM, John Culleton<john@...1202...> wrote:
So that is the problem situation. It must be LSI and if it is LSI it must be PDF X/1-a.
Let's work on the solution for Inkscape, shall we?
Like I said, it's rather unlikely that this will be a "solution for inkscape" only. We have purged our own PDF exporter in favor of cairo's. Since it would be better to avoid reinventing the wheel, maybe Scribus devels can help Cairo devs add this format to their PDF backend, or otherwise make their PDF code usable for cairo-using apps.
It may not be pretty or work directly in Inkscape but here's my external method using Imagemagick (should work on Linux, Windows and Mac)
# Convert RGB PNG (Exported from Inkscape) to CMYK (US SWOP) TIF convert /home/heathenx/Desktop/rgb.png -profile /usr/share/color/icc/sRGBColorSpaceProfile.icm -profile /usr/share/color/icc/USWebCoatedSWOP.icc /home/heathenx/Desktop/rgb-cmyk.tif
# Convert CMYK (US SWOP) TIF to CMYK PDF convert /home/heathenx/Desktop/rgb-cmyk.tif -profile /usr/share/color/icc/USWebCoatedSWOP.icc /home/heathenx/Desktop/rgb-cmyk.pdf
# Verify output identify -verbose /home/heathenx/Desktop/rgb-cmyk.pdf | grep Colorspace:
Of course I design in RGB and can use soft proofing to check colors. But let it be known that I never have a use for CMYK personally (at this point anyway). The Imagemagick commands are more of a proof that a conversion can be done...not that it is the most accurate way to go about it. This is a very generic conversion.
heathenx
On Wed, Sep 15, 2010 at 4:13 PM, heathenx <heathenx@...400...> wrote:
It may not be pretty or work directly in Inkscape but here's my external method using Imagemagick (should work on Linux, Windows and Mac)
That is definitely workable, but it's a bitmap, which makes converting to PDF kinda pointless. You might just as well submit CMYK TIFF then. Which may work fine in a lot of situations, but not all - sometimes crisp vector text is necessary, or some vector shape using a spot color.
bulia byak wrote the following on 9/15/2010 3:53 PM:
On Wed, Sep 15, 2010 at 4:13 PM, heathenx<heathenx@...400...> wrote:
It may not be pretty or work directly in Inkscape but here's my external method using Imagemagick (should work on Linux, Windows and Mac)
That is definitely workable, but it's a bitmap, which makes converting to PDF kinda pointless. You might just as well submit CMYK TIFF then. Which may work fine in a lot of situations, but not all - sometimes crisp vector text is necessary, or some vector shape using a spot color.
Agree. :)
heathenx
On Sep 15, 2010, at 11:40 AM, bulia byak wrote:
On Wed, Sep 15, 2010 at 3:24 PM, John Culleton <john@...1202...> wrote:
So that is the problem situation. It must be LSI and if it is LSI it must be PDF X/1-a.
Let's work on the solution for Inkscape, shall we?
Like I said, it's rather unlikely that this will be a "solution for inkscape" only. We have purged our own PDF exporter in favor of cairo's. Since it would be better to avoid reinventing the wheel, maybe Scribus devels can help Cairo devs add this format to their PDF backend, or otherwise make their PDF code usable for cairo-using apps.
Yes, this is in progress.
Christoph Schäfer is the main contact on the Scribus side of things.
<PatentTalkWarning> CYMK is lossy. But good for .most. jobs. Understanding it's limits is a journey of professionalism. The limits of costs vs. quality vs. time delivery. cmyk compresses the upper saturation values in a sort of log scale (??). So the loss is less obvious to the eye. And impurities in ink are bearable. To print high saturation, Matthew Bernasconi found he could invert the compressed data & over print in rgb. This recovers the saturation and delivers very predictable results. He spent many nights hunched over a Celcius scanner in Many, Sydney re-routing the optic computer to find this. So he risked his house on a patent. He relocated to the US to 'bump' the industry. Now in Charlotte with his crew, Opaltone. The results are the images you hope for.
MarkT
<PatentTalkWarning>
On Wed, Sep 15, 2010 at 12:17 PM, <inkscape-devel.neophyte_rep@...2295...> wrote:
Who, among those active in this thread, actually produces Inkscape data for printing on a regular basis?
Not for color stuff - they all want CMYK (here in the US, ~20 print companies). Producing CMYK files from Inkscape is too much of a hassle. I sometimes draw portions in Inkscape, but I end up doing final assembly in Illustrator.
What does your print service know about this issue? (Assuming you've asked, of course.)
Since I do the design, I'm not always sure who the print service even *is* sometimes. So if it's a full-color print job CMYK is the lowest common denominator (and usually required). And I am on a budget - I don't have time to go head-to-head with every print company out there over some idealogical war about color spaces ;)
Who, among those lurking, is a printer who understands the issue being discussed?
Does building a screen press make me a printer? ;-) I've run (and repaired) large format printers using due and pigment inks as well.
Would you be willing to publish a work flow that you would find technically competent?
Wow - loaded question. The so-called way might look something like: - Design in a calibrated environment, in RGB - Use soft proofing, based on the printer's profile if available - Send RGB files with embedded profile
The unfortunate reality is that since I do not get to choose my printing service (as a freelancer), I must conform to what said service wants - and it's almost *always* generic CMYK.
Yes it's entirely broken, wrong and terrible - but in order to use Inkscape for color work I need to be able to work in a generic CMYK color space (coated SWOP for example), and be able to embed that profile into output PDF and EPS formats. I also need to be able to specify CMYK ink levels for particular colors (100%K vs 60%C 40%M 40%Y 100%K). Spot colors are a must (think metallics, or embossing).
When I was running the large format printers, I did not care if the files were CMYK or RGB - just as long as they had a profile. I could just as easily/accurately RIP from Generic_CMYK->Printer_CMYK as I could RGB->Printer_CMYK.
Chris
On Sep 15, 2010, at 11:15 AM, Chris Mohler wrote:
The unfortunate reality is that since I do not get to choose my printing service (as a freelancer), I must conform to what said service wants - and it's almost *always* generic CMYK.
No, since there is no such thing as "generic CMYK". :-)
They usually need *a* generic CMYK colorspace. For work in North America that would default to SWOP. However, for other countries the colorspace and the numeric values will be different.
Yes it's entirely broken, wrong and terrible - but in order to use Inkscape for color work I need to be able to work in a generic CMYK color space (coated SWOP for example),
Bingo!!!!
You need a *specific* CMYK colorspace. This is usually specified via an ICC profile such as SWOP or ISO or SNAP. In this case "SWOP CMYK" (I'd assume v2) is the specific 'generic' CMYK.
At the moment Inkscape lets you work with such proper CMYK, but the export drops it.
and be able to embed that profile into output PDF and EPS formats. I also need to be able to specify CMYK ink levels for particular colors (100%K vs 60%C 40%M 40%Y 100%K). Spot colors are a must (think metallics, or embossing).
Yes. EPS is a bit dated, so getting such output into the proper type of PDF is key. The scribus guys have given me several sample files that I'm working on breaking apart technically so we can have good examples for the Cairo guys to be able to tune their API to support.
But... recent versions of Scribus have started to support CMYK ICC from Inkscape-generated SVG files. They don't support quite all the SVG features we do... yet. However if the SVG gets *in* to Scribus successfully, then Scribus will do a very nice job getting profesional PDF output.
But the *HUGE* problem is that there is no such thing as "the CMYK colorsystem". If a print shop is going to produce the same color from one week to the next, they need to be working in a *specific* CMYK colorspace.
I based my understanding of this issue in ImageMagick documentation: http://www.imagemagick.org/Usage/formats/
"RGB and CMYK are not colorspaces, they are color systems (which IM controls using the "-colorspace" operator). There is no single RGB or CMYK colorspace, but a literally infinite amount of different colorspaces are possible in each color system."
About using a "specific", "generic" CMYK ICC profile, why don't use by default the same as Scribus, or sK1? Problem solved! If the user need to change, the user can do that.
I think what you really *need* is to get consistent visual output, not
consistent ink saturation. There is a very subtle difference, but one that means if you do a reprint on a job a month later the newer copies will match the original ones.
Get my point: I set in Inkscape the fill of a shape with C0 M50 Y100 K0 that is orange. I need in the C off-set platewith no cyan ink, M off-set plate with 50% of magenta ink, Y off-set plate with 100% of yellow ink and K off-set plate with no black ink. If I save it in a PDF in RGB, I'll need a ICC profile to convert these values to CMYK. But doing this will never give me the real values I want (C0 M50 Y100 K0). They will always convert the colors based on the profile conversion. What can I do? That is what I want to say, the ICC profile is not a must to have an output in CMYK because some people (like me) just want the exact values used in the draw.
Thanks.
On Thu, Sep 16, 2010 at 12:05 AM, Jon Cruz <jon@...18...> wrote:
On Sep 15, 2010, at 11:15 AM, Chris Mohler wrote:
The unfortunate reality is that since I do not get to choose my printing service (as a freelancer), I must conform to what said service wants - and it's almost *always* generic CMYK.
No, since there is no such thing as "generic CMYK". :-)
They usually need *a* generic CMYK colorspace. For work in North America that would default to SWOP. However, for other countries the colorspace and the numeric values will be different.
Yes it's entirely broken, wrong and terrible - but in order to use Inkscape for color work I need to be able to work in a generic CMYK color space (coated SWOP for example),
Bingo!!!!
You need a *specific* CMYK colorspace. This is usually specified via an ICC profile such as SWOP or ISO or SNAP. In this case "SWOP CMYK" (I'd assume v2) is the specific 'generic' CMYK.
At the moment Inkscape lets you work with such proper CMYK, but the export drops it.
and be able to embed that profile into output PDF and EPS formats. I also need to be able to specify CMYK ink levels for particular colors (100%K vs 60%C 40%M 40%Y 100%K). Spot colors are a must (think metallics, or embossing).
Yes. EPS is a bit dated, so getting such output into the proper type of PDF is key. The scribus guys have given me several sample files that I'm working on breaking apart technically so we can have good examples for the Cairo guys to be able to tune their API to support.
But... recent versions of Scribus have started to support CMYK ICC from Inkscape-generated SVG files. They don't support quite all the SVG features we do... yet. However if the SVG gets *in* to Scribus successfully, then Scribus will do a very nice job getting profesional PDF output.
Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 9/16/10, Jonatã Bolzanwrote:
But the *HUGE* problem is that there is no such thing as "the CMYK colorsystem". If a print shop is going to produce the same color from one week to the next, they need to be working in a *specific* CMYK colorspace.
I based my understanding of this issue in ImageMagick documentation: http://www.imagemagick.org/Usage/formats/
"RGB and CMYK are not colorspaces, they are color systems (which IM controls using the "-colorspace" operator). There is no single RGB or CMYK colorspace, but a literally infinite amount of different colorspaces are possible in each color system."
Looks like you are on a terminology dispute :) There are color models (same as systems) such as RGB, CMYK, CIE XYZ, Munsell and so on. They are single. And then there are color spaces whose amount is truely infinite. So there's nothing to argue about. You guys just put different meaning into the word "system" :)
Get my point: I set in Inkscape the fill of a shape with C0 M50 Y100 K0 that is orange. I need in the C off-set platewith no cyan ink, M off-set plate with 50% of magenta ink, Y off-set plate with 100% of yellow ink and K off-set plate with no black ink. If I save it in a PDF in RGB, I'll need a ICC profile to convert these values to CMYK. But doing this will never give me the real values I want (C0 M50 Y100 K0). They will always convert the colors based on the profile conversion. What can I do? That is what I want to say, the ICC profile is not a must to have an output in CMYK because some people (like me) just want the exact values used in the draw.
Yes, there are cases when RGB to CMYK conversion should be color unmanaged. For this very reason such optional functionality was added to CMYKTool in one of the recent versions.
Alexandre Prokoudine http://libregraphicsworld.org
On Sep 16, 2010, at 6:52 AM, Jonatã Bolzan wrote:
Get my point: I set in Inkscape the fill of a shape with C0 M50 Y100 K0 that is orange. I need in the C off-set platewith no cyan ink, M off-set plate with 50% of magenta ink, Y off-set plate with 100% of yellow ink and K off-set plate with no black ink. If I save it in a PDF in RGB, I'll need a ICC profile to convert these values to CMYK. But doing this will never give me the real values I want (C0 M50 Y100 K0). They will always convert the colors based on the profile conversion. What can I do? That is what I want to say, the ICC profile is not a must to have an output in CMYK because some people (like me) just want the exact values used in the draw.
Yes.
*If* you work in an SVG document with a CMYK profile specified, then you get those four discrete CMYK values stored. Then if you bring it into Scribus you will end up with a PDF that preserves exactly the percentages you had specified.
The CMYK profile is a must, since you can't just say "Magenta ink". What you can say is "The Magenta ink as mixed in north america for web-based coated printing". Then when the print shop gets it they say "oh, he wants Magenta 50% in SWOP, but todays calibration for offset press number two on the third floor needs to be told 48% to get the desired end color" and they do their magic behind their doors to make things match any references and proofs you have.
So far all the normal cases I have encountered in real life where an artist or designer *thought* he wanted to control exact CMYK ink application in the plates, the desire turned out to be misguided. That was the *how* of the designer trying to end up with consistent color. The *why* is not to control ink levels, but to end up with the same color specified and the same color he had been getting last week or last month. With a CMYK profile involved the latter is easily achievable; without any specifics on the CMYK specified, it is not.
Even in the case where a print shop does no color management at all, things are much better if you come in saying "Here are my CMYK values as defined in SWOP". They then have a standard to be held to and it is *their* responsibility to get print output on their specific presses that is close enough to SWOP 50% magenta. Even in cheap one-off shops in China our users have seen good color prints with just that simple mechanism (essentially saying "here is what it should end up looking like, match it")
On 15 September 2010 18:29, John Culleton <john@...1202...> wrote:
The physical printing press will either use spot colors or the process colors of CMYK. That is the target. That is how modern printing presses work. They mix those four colors and not Red Green and Blue. So I suggest:
- Use CMYK from the beginning to develop a print document. This gets
around the smaller gamut problem.
- For exact colors don't depend on a monitor representation,
calibrated or no. Take the CMYK values and look them up on e.g. Galaxy Color Gauge Color Pro. This still won't be "exact exact" but it will be the closest you can get without having the printer produce a proof copy.
As my father used say, don't fight the problem. Printing presses use process colors AKA CMYK. Work backwards from that.
Well, they actually don't. Most at least half-professional print shops work with six colors or more to make the available color space somewhat less limited.
The really professional ones can mix you custom colors or load colors that can't be represented in any sane color space known so far like shades of gold color.
Still if your print shop insists on CMYK PDFs there is no reason to deny them that output so long as they give you the profile and Cairo gets the feature implemeted (or somebody hacks it as addon to inkscape if they must).
Thanks
Michal
On Wed, Sep 15, 2010 at 9:22 PM, Michal Suchanek wrote:
Still if your print shop insists on CMYK PDFs there is no reason to deny them that output so long as they give you the profile and Cairo gets the feature implemeted (or somebody hacks it as addon to inkscape if they must).
That addon already exists.
http://www.inkscapeforum.com/viewtopic.php?f=11&t=5943
Alexandre Prokoudine http://libregraphicsworld.org
On 15 September 2010 19:28, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Wed, Sep 15, 2010 at 9:22 PM, Michal Suchanek wrote:
Still if your print shop insists on CMYK PDFs there is no reason to deny them that output so long as they give you the profile and Cairo gets the feature implemeted (or somebody hacks it as addon to inkscape if they must).
That addon already exists.
http://www.inkscapeforum.com/viewtopic.php?f=11&t=5943
Alexandre Prokoudine http://libregraphicsworld.org
Then I don't know what this whole thread is about?
You can get the CMYK output if your print shop demads it, you can check your work using the printer profile when available, it's all well and good.
Thanks
Michal
On Wed, Sep 15, 2010 at 9:38 PM, Michal Suchanek wrote:
Still if your print shop insists on CMYK PDFs there is no reason to deny them that output so long as they give you the profile and Cairo gets the feature implemeted (or somebody hacks it as addon to inkscape if they must).
That addon already exists.
Then I don't know what this whole thread is about?
You can get the CMYK output if your print shop demads it, you can check your work using the printer profile when available, it's all well and good.
Quoting the initial message in the forum's thread
"The extension will find the objects that are named with "cmyk" and convert it into CMYK bitmaps. Due to a technical issue, there isn't the possibility to generate PDFs with CMYK + alpha bitmaps. And it runs only on Linux. "
Alexandre Prokoudine http://libregraphicsworld.org
Hi there
The software products Photoshop, Scribus, Krita, InDesign, TeX, Open
Office etc. all can work in and produce a pdf file with CMYK generated
colors. So they solve the problem insofar as it can be solved.
Inkscape needs to be added to that group IMO.
OpenOffice doesn't generate PDF in CMYK colorsystem.
Who, among those active in this thread, actually produces Inkscape
data for printing on a regular basis?
Me :)
What does your print service know about this issue? (Assuming you've
asked, of course.)
They only accept files using CMYK colorsystem. Usually we send in CDR (CorelDRAW) format for film (photolith). When it is a CTP service we send in PDF format. When I use Inkscape to draw the art, I need to use the extension "Export TIFF CMYK". Then I generate a TIFF of all the work, put in Scribus and generate a PDF in CMYK. Never got problem with that. When I need to generate PDF with CMYK values for vector graphics (text for example) I have 2 options: from Scribus import SVG and convert the RGB values to CMYK using the plugin "rgb2cmyk" or in Inkscape using the extension "Export PDF CMYK".
It is a bit strange to talk in CMYK and RGB ICC profiles been extremely essential for printing. For example, most users and even designers that use proprietary software doesn't even know what is a ICC profile - they will know this just when someone asks. Get my point: those people just open a software, draw and save in CMYK, they doesn't adjust any ICC profile. Of course, using ICC profiles is the best. But not in all cases.
In my case, I need to get the exact value of CMYK that I put in Inkscape into the off set plate. Could some ICC profile help me in it? My experience says "no".
Who, among those lurking, is a printer who understands the issue being
discussed?
I think I'm understanding :)
Would you be willing to publish a work flow that you would find
technically competent?
I can suggest you about the Brazilian Inkscape Users Wiki, here: http://wiki.softwarelivre.org/InkscapeBrasil/EspecificacaoCMYK
Thanks for the attention.
On Wed, Sep 15, 2010 at 2:22 PM, Michal Suchanek <hramrach@...704...>wrote:
On 15 September 2010 18:29, John Culleton <john@...1202...> wrote:
The physical printing press will either use spot colors or the process colors of CMYK. That is the target. That is how modern printing presses work. They mix those four colors and not Red Green and Blue. So I suggest:
- Use CMYK from the beginning to develop a print document. This gets
around the smaller gamut problem.
- For exact colors don't depend on a monitor representation,
calibrated or no. Take the CMYK values and look them up on e.g. Galaxy Color Gauge Color Pro. This still won't be "exact exact" but it will be the closest you can get without having the printer produce a proof copy.
As my father used say, don't fight the problem. Printing presses use process colors AKA CMYK. Work backwards from that.
Well, they actually don't. Most at least half-professional print shops work with six colors or more to make the available color space somewhat less limited.
The really professional ones can mix you custom colors or load colors that can't be represented in any sane color space known so far like shades of gold color.
Still if your print shop insists on CMYK PDFs there is no reason to deny them that output so long as they give you the profile and Cairo gets the feature implemeted (or somebody hacks it as addon to inkscape if they must).
Thanks
Michal
Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sep 15, 2010, at 10:45 AM, Jonatã Bolzan wrote:
They only accept files using CMYK colorsystem. Usually we send in CDR (CorelDRAW) format for film (photolith). When it is a CTP service we send in PDF format. When I use Inkscape to draw the art, I need to use the extension "Export TIFF CMYK". Then I generate a TIFF of all the work, put in Scribus and generate a PDF in CMYK. Never got problem with that. When I need to generate PDF with CMYK values for vector graphics (text for example) I have 2 options: from Scribus import SVG and convert the RGB values to CMYK using the plugin "rgb2cmyk" or in Inkscape using the extension "Export PDF CMYK".
But the *HUGE* problem is that there is no such thing as "the CMYK colorsystem". If a print shop is going to produce the same color from one week to the next, they need to be working in a *specific* CMYK colorspace.
In my case, I need to get the exact value of CMYK that I put in Inkscape into the off set plate. Could some ICC profile help me in it? My experience says "no".
I think what you really *need* is to get consistent visual output, not consistent ink saturation. There is a very subtle difference, but one that means if you do a reprint on a job a month later the newer copies will match the original ones.
On Wednesday 15 September 2010 22:56:07 Jon Cruz wrote:
On Sep 15, 2010, at 10:45 AM, Jonatã Bolzan wrote:
They only accept files using CMYK colorsystem. Usually we send in CDR (CorelDRAW) format for film (photolith). When it is a CTP service we send in PDF format. When I use Inkscape to draw the art, I need to use the extension "Export TIFF CMYK". Then I generate a TIFF of all the work, put in Scribus and generate a PDF in CMYK. Never got problem with that. When I need to generate PDF with CMYK values for vector graphics (text for example) I have 2 options: from Scribus import SVG and convert the RGB values to CMYK using the plugin "rgb2cmyk" or in Inkscape using the extension "Export PDF CMYK".
But the *HUGE* problem is that there is no such thing as "the CMYK colorsystem". If a print shop is going to produce the same color from one week to the next, they need to be working in a *specific* CMYK colorspace.
In my case, I need to get the exact value of CMYK that I put in Inkscape into the off set plate. Could some ICC profile help me in it? My experience says "no".
I think what you really *need* is to get consistent visual output, not consistent ink saturation. There is a very subtle difference, but one that means if you do a reprint on a job a month later the newer copies will match the original ones.
I don't find the extension "Export TIFF CMYK" on Inkscape 48. Is that a download somewhere? Does it convert to bitmap?
Ink saturation is however important. "Rich Black" on some palettes has a total saturation of 260% but LSI, always being difficult, insists on no more than 240% for any color including of course Rich Black. I use a special ICC profile that someone cobbled up for me on the icc_users list and based on SWOP Coated that limits total ink to 240%. In turn in Scribus and using the Scribus Open Office Palette I create a Rich Black of C=60,M=40,Y=40,K=100.
All the presses I use are digital, including of course LSI.
On 9/16/10, John Culleton wrote:
I don't find the extension "Export TIFF CMYK" on Inkscape 48. Is that a download somewhere? Does it convert to bitmap?
http://www.inkscapeforum.com/viewtopic.php?f=11&t=5943
Alexandre Prokoudine http://libregraphicsworld.org
On Sep 15, 2010, at 9:29 AM, John Culleton wrote:
The physical printing press will either use spot colors or the process colors of CMYK. That is the target. That is how modern printing presses work. They mix those four colors and not Red Green and Blue. So I suggest:
Well, not really. There is a fair bit more than four colors going on, *especially* if any spot (e.g. Pantone) colors come into play. In fact, the classic Pantone use *precludes* four-color press output.
However, the main point to take is that there is no such thing as "the" process colors of CMYK. CMYK is a very fuzzy term that describes a *type* of colorspace. Keep in mind that there is no such thing as "the CMYK colorspace".
- Use CMYK from the beginning to develop a print document. This gets
around the smaller gamut problem.
Very close. One should probably use a *specific* CMYK from the beginning. SWOP is one of the more common ones in the US (but depending on the use, others might be preferred such as SNAP). Most of Europe uses a *different* 'generic' CMYK color set that some call 'Europe ISO Coated FOGRA27'
Using the right CMYK colorspace for the right application in the right country is important.
- For exact colors don't depend on a monitor representation,
calibrated or no. Take the CMYK values and look them up on e.g. Galaxy Color Gauge Color Pro. This still won't be "exact exact" but it will be the closest you can get without having the printer produce a proof copy.
But *if* you provide values in a standard CMYK colorspace, *and* the print house follows good practices you will get very very close. You provide things in a specified industry standard CMYK colorspace and then the print house takes on the burden of making their printers with their inks combined with things such as the current shop temperature and humidity and end up with a nice print.
As my father used say, don't fight the problem. Printing presses use process colors AKA CMYK. Work backwards from that.
*Some* presses do. Often you get plates run with spot colors, some with hex (aka six) colors, etc.
The software products Photoshop, Scribus, Krita, InDesign, TeX, Open Office etc. all can work in and produce a pdf file with CMYK generated colors. So they solve the problem insofar as it can be solved. Inkscape needs to be added to that group IMO.
We need to tighten up our CMYK support a bit. Inkscape SVG files can be produced that are fully compliant with all pertinent specs, but most ways of getting things to the print shop end up doing lossy conversions. PDF is the main target of modern printing, though.
From the small number of commercial print jobs I've done, I'd like spot color support. It wouldn't even need to look exactly like the final product, on screen color wise, it would just useful to be able to manage colors as "shades of black", and "shades of some green I'll pick when I go to the printer", and to be able to produce the required separations.
Cheers -Terry
participants (14)
-
unknown＠example.com -
Alexandre Prokoudine -
bulia byak -
Chris Mohler -
heathenx -
John Culleton -
Jon Cruz -
Jonatã Bolzan -
Joshua A. Andler -
Krzysztof Kosiński -
Mark T -
Michal Suchanek -
Terry Brown -
the Adib