[Scribus] Comment about object tag names and xml file format

[Craig Ringer]

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