[Scribus] Comment about object tag names and xml file format
Craig Ringer
craig
Wed Feb 27 05:49:55 CET 2008
Tim Boyden wrote:
>> Yes, but can you specify:
>>
>> CMYK(18,4,11,25) ?
>>
>
> Yep, Hex value is: A6B1B0
>
>
Do you mean "A naieve unmanaged conversion from CMYK to RGB of the CMYK
value specified above would result in an RGB colour with the hex value
0xA6B1B0 ?"
How did you convert the colour?
What colour spaces (device profiles, you might say) did you assume for
the source and destination colour spaces? What rendering intent did you use?
How do you inform the SVG client about which colour space that RGB value
is in?
How do you tell the SVG renderer, when printing, how much black should
be generated when converting back to CMYK? (UCR/GCR) ?
My point is that Scribus, like any DTP app, must be able to store
colours in several different ways. It must be able to do this because
users require this. Simply using 8-bit RGB in an assumed sRGB space for
all colours is NOT ACCEPTABLE. There are colours that many printers can
reproduce that cannot be represented in the sRGB gamut. Some people need
explicit control of black generation in CMYK. Some people need to
include pre-converted CMYK images from other sources, and these must
retain their original CMYK values throughout the process. Some people
need to use wide-gamut RGB spaces like Adobe RGB. Many printers have
legacy unmanaged workflows that require untagged CMYK values.
SVG, without the SVG 1.2 Print extensions, cannot satisfy even the most
basic of these requirements.
It sounds to me like for your particular needs you do not require
accurate, wide gamut, or flexible colour, and would be happy with 8-bit
unmanaged RGB. In this case, for your particular needs, basic SVG 1.1 is
OK. This, however, does not make it an appropriate format for Scribus
documents, as many other people do in fact require support for managed &
profiled colour, alternate colour spaces, etc. SVG 1.2 Print is closer,
but there are other limitations too, and I do not know enough about the
details of things like the SVG text model to explain those to you in
detail. If you will be patient somebody who has worked on Scribus's svg
support might be able to explain.
What WOULD be valid is to provide an SVG export option for Scribus that
converted all colours from their internal representations (be they
L*A*B, managed CMYK, sRGB, another managed RGB space, etc) to sRGB for
SVG 1.1 export, and include SVG 1.2 Print extensions for supporting user
agents. That's entirely practical as far as I know, though there might
be issues with other features (transparency and composition model
differences, layer blending mode support, etc) that make it harder. In
any case, that just needs somebody to step up and volunteer to write the
code.
>> How about ICC based colour spaces? Say the colour AdobeRGB(13,13,13) ?
>>
>
> Yep, Hex value is: 0D0D0D
>
And how does the SVG rendering client know that the colour is in the
AdobeRGB space so that it can convert it to the monitor space
appropriately? You've just converted the value to 8-bit R/G/B hex
without considering colour spaces, which is incorrect, thus illustrating
my point.
The correct value would be 0x141414 , which is sRGB(20,20,20), and the
correct conversion to sRGB of AdobeRGB(13,13,13) if an absolute
colorimetric rendering intent is used. The user agent, however, has no
way to know that, since it has no way to know that without use of the
SVG 1.2 Print extensions. If it assumes the colour is sRGB it'll come
out excessively dark compared to how it should.
One might therefore ask what the conversion of AdobeRGB(220,0,0) to sRGB
is ? Well, again with the absolute coloirmetric rendering intent, the
answer is sRGB(255,0,0). What about AdobeRGB(240,0,0) then? It's a
different colour, but it still converts to sRGB(255,0,0) because of
gamut clipping.
If we decide to use the relative coloirmetric or perceptual rendering
intents to work around the gamut clipping from the absolute coloirmetric
rendering intent conversion we'll get a smooth gradient like we should,
but all colours will be proportionally desaturated.
SVG 1.2 Print is the only way around these issues, but at least it does
handle them.
> Now that being said, will it look the same on screen as on print? Only
> if your screen is calibrated using special applications.
That's maybe 10% of the answer.
Say I've calibrated my display with i1Match and an i1Display from XRite
(I have, as it happens). Nice. OK, colour-aware applications now have an
ICC profile for my display that they can use in colour conversions.
For that to be ANY USE AT ALL they must ALSO know the SOURCE profile.
"RGB #0D0D0D" means ABSOLUTELY NOTHING by its self in a managed colour
context. If there is no way to obtain, from the input file, the colour
space that is used for colours in the document, the rendering agent must
assume one. It will usually assume sRGB, and I think that's what the SVG
standard requires. If your colour is not in fact an sRGB colour value,
but rather a colour in a different RGB space, the conversion to monitor
RGB will be made using the wrong input profile, resulting in the wrong
output value, and the colour will appear wrong. In other words, if you
cannot specify which colour space a colour is in SVG, you must convert
them all to sRGB as part of producing the SVG document.
Unfortunately, sRGB is incapable of describing a great many real-world
colours. Very saturated cyan and magenta, for example, can not be
represented in sRGB. Consequently, if I'm converting from Adobe RGB
colour to sRGB I must either use gamut compression (in this case
desaturating all colours proportionally) or accept that some colours
will be clipped and will not display correctly. In either case, my
colour changes, and I cannot represent my original design in sRGB as
used in SVG.
SVG 1.2 Print solves these issues, but isn't supported by most (any)
user agents yet. In any case, my point is that it's just not as simple
as "converting the colour to hex".
> That's why
> printers rely on color charts and not on screen colors for their final
> output.
Actually, good printers produce colour swatch sheets from their
press/printer, sample the swatch sheets with a spectrometer that can
measure the absolute "real" colour independent of human perception
variation, and produce a colour profile based on those measurements that
can be used to convert colours to and from the printer's device-specific
values.
That profile then allows conversion of monitor colour (on a calibrated
and profiled monitor) or any of the "standard" colour spaces like
AdobeRGB, sRGB, and the IEC CMYK printer spaces to the particular
printer/press's colour values for printing. It's not that simple (look
up ICC colour, L*A*B, the XYZ space, and device-independent colour to
learn more) but for undemanding jobs its surprisingly close to that
simple in practice.
Relying on precalculated CMYK charts and tables (which I think was what
you were describing) is clumsy, but it does work. Of course, you can't
do that with SVG 1.1, since it only supports sRGB, so you have no way to
specify your CMYK colour values.
Managed colour workflows as described above work a great deal better,
but require support for alternate colour spaces and colour profiles in
the document format to be useful.
> Different RIPs will also output colors differently, so the only
> way to be sure is to do a color corrected hardcopy for proofing. SVG
> Print 1.2 is an extension of SVG to add printing industry vocabulary to
> the standard SVG spec. The W3C gives this example as a way to use color
> profiles with the current SVG spec:
>
> <svg width="210mm" height="297mm"
> xmlns="http://www.w3.org/2000/svg" version="1.2" referenceDirection="backwards">
> <pageSet>
> <page>
> <color-profile name="MyColors"
> xlink:href="CompanyColors.icm"/>
> <text x="50mm" y="85mm"
> font-family="MyCompanyLogoFont" font-size="12"
> color="rgb(255,12,13) icc-named-color(MyColors, logo_color)">
> MyCompany logo.
> </text>
> </page>
> </pageSet>
> </svg>
>
That's right. A fallback colour in an assumed 8-bit sRGB space is
provided for user-agents that don't understand the ICC-profiled colour
value. Most existing user-agents will render it as if it were in the
monitor colour space rather than sRGB anyway.
I did say that SVG 1.2 Print helps address these issues, but IS NOT YET
SUPPORTED IN ANY WIDELY USED USER AGENTS. At this point, however, it can
be safely assumed that anybody using SVG does not care about accurate
colour, and that will only change with the wide adoption of SVG 1.2 Print.
I'm sure expressions of interest in adding SVG 1.2 Print support to the
SVG exporter would be welcomed. Feel like having a go? It's probably not
that tricky, at least for the colour space stuff.
> Hence any color from any color library can be used provided the profile is available to the SVG document.
>
Yes, in user agents supporting SVG 1.2 Print. As I said in my first email.
> As far as glyph positioning, goes, as the link I included demonstrates,
> you would use a <tspan> element to apply a character specific styling or
> positioning to get it in the right place. No need to break a line into
> multiple elements.
>
OK, let's wait for a response from Riku and the others who've worked on
Scribus's SVG support and see if that's a practical option or if there's
something going on that we're not aware of.
> While Inkscape may provide good SVG support, that's not what I'm
> suggesting. I'm suggesting incorporating SVG like features into Scribus.
>
Yes, that I can agree with. Scribus already supports most SVG features
as far as I know, but it's import and export are not up to the quality
where it can translate its internal graphics objects into good quality
SVG reliably.
> While I feel using the SVG syntax and file format would make this easier
> and would make use of an existing standard and talent pool, I can
> understand that it's not as simple as that and that it may be best to
> just extend the current file format to incorporate as many of those
> features as possible and where appropriate.
>
Pretty much. If we wanted to use the SVG format, we'd be better off
starting again based on Inkscape, which is designed for exactly that.
I suspect that Inkscape's text handling features will improve as SVG 1.2
Print and related standards become more mature and accepted, but it
still won't meet DTP needs very well. Scribus is better off focusing on
DTP, and unless an open standard format that's well suited to DTP comes
about we're going to have to forge ahead.
That's not to say the existing format can't be improved. That's VERY far
from the truth. I just don't think that focusing on SVG is a useful way
to go about trying to improve it. In some cases, though, there are valid
parallels - for example, I agree that it'd be good to have an easily
accessible and standard way to look up Scribus document elements by the
name provided in the user interface.
--
Craig Ringer
More information about the scribus
mailing list