Nabble - w3.org - public-svg-print

Re: Response to XSL WG comments on (the color parts of) SVG Print

2009-07-02T15:12:56Z

On Thu, Jun 11, 2009 at 09:03:10PM +0000, Chris Lilley wrote:
> Hello w3c-xsl-fo-sg,
>
> Some time ago you gave some feedback on SVG print
> http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0005.html
>
> and Anthony Grasso briefly responded at the time
> http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0006.html

The XSL-FO subgroup is happy with your responses.

We would also be happy for you (Chris and/or others)
to meet with us in Bologna in September.

Liam, pp. XSL-FO WG

--
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/

Re: Response to XSL WG comments on (the color parts of) SVG Print

2009-06-25T08:20:58Z

The XSL-FO Subgroup considered the SVG responses today; we
are satisfied with them.

Thank you!

Liam (pp. XSL FO SG)

--
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/

Re: Feedback on SVG Print 1.2 WD 2007-12-21

2009-06-14T04:19:19Z

Hi Chris

Thanks for the feedback. I'm happy with the responses and that SVG Print
and Color Management have been separated. This gives the color aspects
more weight. I'll continue to follow the developments here and I hope
I'll have time at some point to do some implementation work to verify
the spec. No promises. ;-)

On 11.06.2009 19:19:13 Chris Lilley wrote:

> Hello Jeremias,
>
> Some time ago you gave some feedback on SVG print
> http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0000.html
>
> and I briefly responded at the time
> http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0001.html
>
> since then the SVG WG was primarily occupied with spec writing and test suites for other specifications. More recently work has restared on these SVG modules. SVG Print has been split into two specifications, one for the multipage functionality and one for color management. It is in connection with the latter of these that I am contacting you now.
>
> Your comment is listed in a draft disposition of comments
> http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-003
>
> and our response (to the color-related portions of your comment, only) is broad agreement that there is a need for greater dialog between XSL FO and SVG on these issues. Given the different constraints on syntax for each spec, such alignment is likely to be at the functional rather than the syntactic level, but that is the level which most affects implementations in terms of shared code and concepts anyway.
>
> The XSL WG has in fact indicated that it wishes to re-use the SVG WG work in this area for icc-based CMYK color and for device color.
> http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-009
>
> Several open-source implementation which generate of consume SVG have also indicated an interest in the SVG color work; in particular Inkscape would like to generate SVG with calibrated, ICC-based CMYK and Scribus would like to consume these to produce PDFs. It is therefore likely that the XSL+SVG combination would also start seeing SVG which uses calibrated CMYK.
>
> For icc-named-color, the SVG WG is aware of ongoing work on swatches on the create mailing list and on the open-icc mailing list, which may provide practical, authoring-implementation-supported help for this issue in the future. In other words the relevant tools are likely to start producing these profiles, and there are likely to be named color profiles available that people can pick up and use.
>
> For the device-color element, we were initially inclined to disagree; but have been thinking about this more recently, and at this weeks face to face meeting decided to change the syntax to one which is simpler and directly maps to the PDF DeviceGray, DeviceRGB and DeviceCMYK constructs (and also to a multichannel option). This part is not fully specc'ed out yet, but there is an early editors draft of SVG color at
> http://dev.w3.org/SVG/modules/color/master/SVGColor.html
> that spec is changing, but we are starting to edit in an alternative that is very close to your suggestion.
>
> Please let us know if these responses correctly address your comments. Sorry again for the delay between your comments and our substantive response.
>
>
> --
> Chris Lilley mailto:chris@...
> Technical Director, Interaction Domain
> W3C Graphics Activity Lead
> Co-Chair, W3C Hypertext CG

Jeremias Maerki

Response to XSL WG comments on (the color parts of) SVG Print

2009-06-11T14:02:59Z

Hello w3c-xsl-fo-sg,

Some time ago you gave some feedback on SVG print
http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0005.html

and Anthony Grasso briefly responded at the time
http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0006.html

since then the SVG WG was primarily occupied with spec writing and test suites for other specifications. More recently work has restared on these SVG modules. SVG Print has been split into two specifications, one for the multipage functionality and one for color management. It is in connection with the latter of these that I am contacting you now.

Your comments are listed in a draft disposition of comments
http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-009

http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-010

http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-011

In regards to comment 009, the SVG WG is pleased that you find the color specifications appropriate and would like to further discuss hpw these might concretely be incorporated in XSL 2.0. Given the different constraints on syntax for each specification, we would expect alignment at the functional rather than the syntactic level,XSL continuing to use its functional notation.

Perhaps we could meet up at TPAC, if XSL will be there; or I could perhaps attend the Bologna XSL FO meeting, as its relatively close to where I live in Nice. Coordination via email would also work of course. Or perhaps a contribution document as a starting point. Please advise what would work best for you.

Regarding comment 010 about some properties being marked as animatable, even though SVG print does not support animation. We agree this could be confusing, it was done like that to allow reuse of the color material in other profiles besides print. This was an inadvertent consequence of the SVG Print spec attempting to address printers, other paged media such as print preview, and general SVG all in one specification.

SVG Color provides a general color upgrade for SVG, and so indicates which properties are animatable. Naturally, the animatability only applies to dynamic profiles which support animation. So, while we still say which properties are animatable, we hope that this no longer causes an apparent conflict. Specifically, it would not require XSL processors to animate them. Rather, this indicates, for dynamic SVG processors which perform animation, which properties may *not* be animated.

For comment 011 about language for rendering intents, your suggested language is much better, more up to date, and precise that what we had and we have completely adopted your wording.
http://dev.w3.org/SVG/modules/color/master/SVGColor.html#ColorProfileElementRenderingIntentAttribute

Please note: for the device-color element, we agree that the previous text was underspecified, vague, and hard to implement in an interoperable manner. At this weeks face to face meeting the SVG WG decided to change the syntax to one which is simpler and directly maps to the PDF DeviceGray, DeviceRGB and DeviceCMYK constructs (and also to a multichannel option). This part is not fully specc'ed out yet, but there is an early editors draft of SVG color at
http://dev.w3.org/SVG/modules/color/master/SVGColor.html
that portion of the spec is changing, but we are starting to edit in an alternative that may well be suitable for XSL FO as well.

Please let us know if these responses correctly address your comments. Sorry again for the delay between your comments and our substantive response. We look forward to working with you to enable a consistent calibrated color capability across SVG and XSL.

Followup is set to public-svg-print@..., which is a public list.

--
Chris Lilley mailto:chris@...
Technical Director, Interaction Domain
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG

Re: Feedback on SVG Print 1.2 WD 2007-12-21

2009-06-11T10:19:13Z

Hello Jeremias,

Some time ago you gave some feedback on SVG print
http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0000.html

and I briefly responded at the time
http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0001.html

since then the SVG WG was primarily occupied with spec writing and test suites for other specifications. More recently work has restared on these SVG modules. SVG Print has been split into two specifications, one for the multipage functionality and one for color management. It is in connection with the latter of these that I am contacting you now.

Your comment is listed in a draft disposition of comments
http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-003

and our response (to the color-related portions of your comment, only) is broad agreement that there is a need for greater dialog between XSL FO and SVG on these issues. Given the different constraints on syntax for each spec, such alignment is likely to be at the functional rather than the syntactic level, but that is the level which most affects implementations in terms of shared code and concepts anyway.

The XSL WG has in fact indicated that it wishes to re-use the SVG WG work in this area for icc-based CMYK color and for device color.
http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-009

Several open-source implementation which generate of consume SVG have also indicated an interest in the SVG color work; in particular Inkscape would like to generate SVG with calibrated, ICC-based CMYK and Scribus would like to consume these to produce PDFs. It is therefore likely that the XSL+SVG combination would also start seeing SVG which uses calibrated CMYK.

For icc-named-color, the SVG WG is aware of ongoing work on swatches on the create mailing list and on the open-icc mailing list, which may provide practical, authoring-implementation-supported help for this issue in the future. In other words the relevant tools are likely to start producing these profiles, and there are likely to be named color profiles available that people can pick up and use.

For the device-color element, we were initially inclined to disagree; but have been thinking about this more recently, and at this weeks face to face meeting decided to change the syntax to one which is simpler and directly maps to the PDF DeviceGray, DeviceRGB and DeviceCMYK constructs (and also to a multichannel option). This part is not fully specc'ed out yet, but there is an early editors draft of SVG color at
http://dev.w3.org/SVG/modules/color/master/SVGColor.html
that spec is changing, but we are starting to edit in an alternative that is very close to your suggestion.

Please let us know if these responses correctly address your comments. Sorry again for the delay between your comments and our substantive response.

--
Chris Lilley mailto:chris@...
Technical Director, Interaction Domain
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG

Re: Print-dizplay

2008-06-13T07:19:14Z

On Thu, 2008-06-12 at 11:47 -0700, Wilbur, Keith R wrote:
> Hi. My name is Keith Wilbur.
>
> For SVG Print 1.2 http://www.w3.org/TR/SVGPrint/#print-display-attr ,
>

[snip]

> So, I would like to see something like a 'displayOnly' value for the
> 'print-display' attribute to indicate that it is for display only, and
> not to be shown for print.
>

print-display="noPrint" is that option.

While it's been brought up though, I'd like to vote for simply using
media style sheets to do this with "display: none;". While slightly more
verbose if applying it directly in a style attribute, it has the
advantage of being common across most other XML formats being rendered
for display.

http://www.w3.org/TR/SVG/painting.html#DisplayProperty

Print-dizplay

2008-06-12T11:47:52Z

Hi. My name is Keith Wilbur.

For SVG Print 1.2 http://www.w3.org/TR/SVGPrint/#print-display-attr ,

I would like to see an option for the 'print-display' attribute to have
something like "displayOnly" as a choice/value, for the following
reason:

In our SVG graphics, we create an xlink in an "a" element, using a small
'square box' on the graphic to visually indicate for display that there
is a link at this spot to another location. However, currently, that
small square box also prints, but has no value to the user in a print
copy.

So, I would like to see something like a 'displayOnly' value for the
'print-display' attribute to indicate that it is for display only, and
not to be shown for print.

Thank you.

Keith Wilbur

Re: Fwd: XSL comments on SVG Print

2008-02-28T12:24:08Z

Hi Sharon,

Thank you for excellent feedback you and the XSL-FO Group have provided
on the SVG Print specification! :)

The SVG Working Group will be discussing the feedback in the upcoming
weeks and provide responses on each of the comments.

Kind Regards,

Anthony Grasso

Software Engineer

Canon Information Systems Research Australia
Email: anthony.grasso@...

---

The information contained in this email message and any attachments may
be confidential and may also be subject to legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorised and prohibited.

If you have received this email in error, please immediately advise the
sender by return email and delete the information from your system.

Erik Dahlström wrote:

>
> Part 1: Primer
> ==============
>
> 2. User Agent
> -------------
> As we're using Adobe Reader reading PDF, there are some specific
> features, and/or properties can be added in the PDF to improve the
> interactivity between user and the computer. E.g. the default zoom
> rate, bookmark trees, etc. I'm wondering SVG print will incorporate
> some of the good features of Adobe Reader or not.
>
> ;;;
>
> As for a SVG print preview agent's implementation, it ought to respond
> quickly for a request of displaying a svg print document, e.g. in a
> internet based environment, it needs to display the content as it's
> still loading from the server as soon as it's possible to do so. PDF
> has such feature to allow user to read first page of the doc as it's
> still loading. I'm wondering if SVG print can add such requirement or
> spec or not.
>
>
> 3.1 The pageSet and page elements
> ---------------------------------
>
> The pageSet is the outmost wrapper of the pages and defines the overall
> content to be printed. Unfortunately only 1 pageSet is allowed which
> limits a possible mapping to the fo:page-sequence.
> Having a concept of pages that belong to the same "document" or "record"
> is important in imposition. A smart imposition engine could
> automatically generate the appropriate imposition in variable length jobs.
>
> ;;;
>
> For clarity, I would add that the id attribute has been added solely for
> the purpose of referencing the element in the text.
>
> 3.2 The scope of a page
> -----------------------
>
> The page element wraps the content belonging to a page. A page element
> doesn't have any positioning or size attributes, these are expressed
> only in the main SVG element. This could be a serious limitation when in
> fo we have page-masters with different sizes and not only orientation.
> The output will need to be on separate files potentially loosing the
> correct printing sequence.
>
> ;;;
>
> Editorial: I think it would be clearer if element names would have a
> slightly different style in paragraphs.
>
>
> 3.3 Master Page - 3.5 Selecting a Master Page...
> ------------------------------------------------
>
> The masterPage concept is used to enable re-usability within a printing
> workflow. The masterPage can have a background or foreground scope,
> which enables it to be either positioned below or above the content
> enclosed in the page element. The masterPages scope is always global,
> but it can be re-defined at any time and it will substitute any
> previously existing background or foreground masterPage (independently
> from their id).
>
> In my personal opinion the lack of correspondence between the masterPage
> id and the use-master-page reference is really confusing.
> It could be very interesting to place all the re-usable parts in these
> constructs to reduce the ripping time.
> In order to take advantage of this feature an fo rendering engine needs
> to have access to the full xslt+fo template, there is no explicit fo way
> of tagging re-usable or non-variable content.
> MasterPage also is a misleading name, since it doesn't really have
> anything to do with a page master. Maybe a more appropriate name is
> reusableFrame.
>
> ;;;
>
> I agree this is too complex. If you refer to a specific part of an
> external file, the other elements of that external file should not have
> any influence in my opinion.
>
>
> 3.9 Relationship between XSF(L)-FO pages and SVG Print pages
> ------------------------------------------------------------
>
> The presented workflow doesn't have a clear representation of how
> imposition is handled. From the picture the resulting SVG Print out of
> the FO Formatter presents two pages that are imposed in a sheet (these
> can be single or double sided, not clear). Since SVG Print can only
> express pages and not sheets it means that one page will contain all the
> two pages and the surrounding marking elements.
> If this is the case the imposition is directly done inside the rendering
> engine, something we are definitely not considering or envisaging.
> The workflow should be extended adding an explicit imposition step
> (probably driven by JDF) which takes SVG-Print as simple sequence of
> pages and produces the SVG Print document in the picture.
> In my opinion it would be really good if SVG Print had a concept of
> sheet which in addition to multiple pageSets could properly express a
> pre-imposed variable data/variable length format and a post-imposed rip
> ready format.
>
> ;;;
>
> Contains a typo (XSF-FO instead of XSL-FO) Editorial: I rewrote the
> section a little bit to use terminology I think is more common.
>
> -------
> XSL-FO has a concept of pages. SVG Print also has pages. Many XSL
> formatters are also capable of handling SVG graphics. How do the
> concepts interact, and do they overlap?
>
> SVG graphics which are used as diagrams in an XML document should not
> use the SVG Print page element. Although it is possible to imagine
> interactive page flipping (Q: Would this use the SVG page element for
> that reason? If not, don?t mention it here) in a diagram presented
> online, this would not be visible when the document was printed.
> A typical conceptual workflow would start with an XML document (such as
> DocBook or DITA) and some SVG illustrations. An XSLT stylesheet acts on
> the XML to produce an XSL-FO result. The XSL-FO is then formatted, which
> may produce multiple pages of laid-out text and graphics using the XSL
> page mechanism. The formatted results then need to be rendered to an
> output format such as for example PDF, PostScript or SVG Print. Thus,
> the SVG used as input at the start of the workflow, as illustrations,
> and the
> SVG used as output at the end of the workflow, to express the formatted
> result, have different roles.
> ------
>
>
> 3.10 Animation and Scripting
> ----------------------------
>
> This section mentioned about not running any script or starting any
> animation in any page being displayed, but it doesn't mentioned what
> the page will look like, does it show the first frame of the animation
> or the last frame? In some cases, last frame is what the user wants to
> show.
>
>
> 4.3 Relationship to existing job control standards
> --------------------------------------------------
>
> In XSL-FO 2.0 RD document (hereinafter FO2.0 RD), section 8.3 "Print
> specific properties", we mentioned that some of the properties will
> probably be done with a Job Control specification such as JDF, I'm
> wondering if SVG Print can also incorporate some of these properties
> into their spec or not, because in the SVG Print 1.2 spec's part 1
> primer doc (hereinafter Print1.2 Primer) section 4.3, it mentioned about
> the interleaving of SVG print doc and the job control commands, but not
> getting into details about how the interaction works between each other.
>
> 4.3.1 JDF
> ---------
>
> One specific remark I have is similar to one of Fabio: JDF is referred
> in SVG print, but there is no example of how to handle JDF. I have tried
> in the past to combine JDF and XSL, but haven't succeeded to make it
> just do basic printer tasks like duplex printing and input/output tray
> handling. For that reason we created our own extension attributions (not
> based on JDF) to do duplex and tray handling. I would suggest to SVG to
> either include some properties for duplex and tray handling, or even
> better make a simple example how to achieve this with JDF. I have spoken
> to Anthony Grasso from Canon about this (the editor of the SVG Print
> Spec) and he said he had a colleague next door that could do this, so I
> really think that would make SVG Print better.
>
>
> 4.4 Examples of SVG bundled jobs
> --------------------------------
>
> I would consider adding an example or reference to the data:// URI
> scheme to embed images as well. This allows us to have a valid XML file
> with embedded image data. This may be easier to create and modify in
> some use cases.
>
>
> 5. Color specification
> ----------------------
>
> These seems to be appropriate and I would like to see the deviceColor
> being adopted by fo as well.
>
> ;;;
>
> SVG has very advanced support in color, we ought to incorporate that
> into FO spec. Besides that SVG has already supported font embedding, in
> order to generate SVG print doc from xsl-fo formatter in a high-fidelity
> manner, we also need to think about how we can incorporate font
> embedding in the FO specification.
>
>
>
> Part 2: Language
> ================
>
> 5.1 Color interpolation
> -----------------------
>
> Even the doc clearly mentioned that animation is not supported in SVG
> print (primer section 3.10), some of the attributes' specification
> mentioned in the doc are still listed as "animatable", e.g. section 5.1
> 'color-interpolation', section 5.3.5 'color-profile', I'm wondering if
> this is confusing or not.
>
>
> 5.3 Color profile descriptions
> ------------------------------
>
> I consult with some colleagues at HP about Rendering Intent for SVG Print.
> It seems that the definitions are not so accurate.
> These are the definitions and comments I collected:
>
> Media-relative colorimetric (a.k.a. relative colorimetric) This method
> is required to leave source colors that fall inside the destination
> medium gamut unchanged relative to the respective media white points.
> Source colors that are out of the destination medium gamut are mapped to
> colors on the gamut boundary using a variety of different methods.
>
> NOTE The media-relative colorimetric rendering intent is often used with
> black point compensation, where the source medium black point is mapped
> to the destination medium black point as well.
>
> ICC-absolute colorimetric (a.k.a. absolute colorimetric) This method is
> required to leave source colors that fall inside the destination medium
> gamut unchanged relative to the adopted white (a perfect reflecting
> diffuser). Source colors that are out of the destination medium gamut
> are mapped to colors on the gamut boundary using a variety of different
> methods. This method produces the most accurate color matching of
> in-gamut colors, but will result in highlight clipping if the
> destination medium white point is lower than the source medium white
> point. For this reason it is recommended for use only in applications
> that need exact color matching and where highlight clipping is not a
> concern.
>
> Perceptual
> This method is often the preferred choice for images, especially when
> there are substantial differences between the source and destination
> (such as a CRT display image reproduced on a reflection print). It takes
> the colors of the source image and re-optimizes the appearance for the
> destination medium using proprietary methods. This re-optimization may
> result in colors within both the source and destination gamuts being
> changed, although perceptual transforms are supposed to maintain the
> basic artistic intent of the original in the reproduction. They will not
> attempt to correct errors in the source image.
>
> NOTE With v2 ICC profiles there is no specified perceptual reference
> medium, which can cause interoperability problems. When v2 ICC profiles
> are used it may be safer to use the media-relative colorimetric
> rendering intent with black point compensation instead of the perceptual
> rendering intent, unless the specific source and destination profiles to
> be used have been checked to ensure the combination produces the desired
> result.
>
> Saturation
> This option was created to preserve the relative saturation (chroma) of
> the original, and to keep solid colors pure. However, it experienced
> interoperability problems like the perceptual intent, and as solid color
> preservation is not amenable to a reference medium solution using v4
> profiles does not solve the problem. Use of this rendering intent is not
> recommended unless the specific source and destination profiles to be
> used have been checked to ensure the combination produces the desired
> result.
>
>
>
>
>
> Sharon C. Adler
> Senior Manager, Extensible Technologies
> IBM Research
> PO Box 704, Yorktown Heights, NY 10598
> tel: 914-784-6411 t/l 863
> fax: 914-784-6324
>
>
>

Fwd: XSL comments on SVG Print

2008-02-28T00:52:03Z

------- Forwarded message -------
From: "Sharon Adler" <sca@...>
To: "Erik Dahlström" <ed@...>
Cc: w3c-xsl-fo-sg@...
Subject: XSL comments on SVG Print
Date: Thu, 28 Feb 2008 01:01:44 +0100

Erik,

I have attacted the comments from the XSL FO subgroup on SVG Print. The
comments have been written for a while but I did not get them sent to your
WG - mea culpa.

Here is the full text of the combined comments: The comments may also be
found at:
http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2008Feb/0021.html

I deeply apologize for the lateness and hope that you all will be able to
process them.

Part 1: Primer
==============

2. User Agent
-------------
As we're using Adobe Reader reading PDF, there are some specific
features, and/or properties can be added in the PDF to improve the
interactivity between user and the computer. E.g. the default zoom
rate, bookmark trees, etc. I'm wondering SVG print will incorporate
some of the good features of Adobe Reader or not.

;;;

As for a SVG print preview agent's implementation, it ought to respond
quickly for a request of displaying a svg print document, e.g. in a
internet based environment, it needs to display the content as it's
still loading from the server as soon as it's possible to do so. PDF
has such feature to allow user to read first page of the doc as it's
still loading. I'm wondering if SVG print can add such requirement or
spec or not.

3.1 The pageSet and page elements
---------------------------------

The pageSet is the outmost wrapper of the pages and defines the overall
content to be printed. Unfortunately only 1 pageSet is allowed which
limits a possible mapping to the fo:page-sequence.
Having a concept of pages that belong to the same "document" or "record"
is important in imposition. A smart imposition engine could
automatically generate the appropriate imposition in variable length jobs.

;;;

For clarity, I would add that the id attribute has been added solely for
the purpose of referencing the element in the text.

3.2 The scope of a page
-----------------------

The page element wraps the content belonging to a page. A page element
doesn't have any positioning or size attributes, these are expressed
only in the main SVG element. This could be a serious limitation when in
fo we have page-masters with different sizes and not only orientation.
The output will need to be on separate files potentially loosing the
correct printing sequence.

;;;

Editorial: I think it would be clearer if element names would have a
slightly different style in paragraphs.

3.3 Master Page - 3.5 Selecting a Master Page...
------------------------------------------------

The masterPage concept is used to enable re-usability within a printing
workflow. The masterPage can have a background or foreground scope,
which enables it to be either positioned below or above the content
enclosed in the page element. The masterPages scope is always global,
but it can be re-defined at any time and it will substitute any
previously existing background or foreground masterPage (independently
from their id).

In my personal opinion the lack of correspondence between the masterPage
id and the use-master-page reference is really confusing.
It could be very interesting to place all the re-usable parts in these
constructs to reduce the ripping time.
In order to take advantage of this feature an fo rendering engine needs
to have access to the full xslt+fo template, there is no explicit fo way
of tagging re-usable or non-variable content.
MasterPage also is a misleading name, since it doesn't really have
anything to do with a page master. Maybe a more appropriate name is
reusableFrame.

;;;

I agree this is too complex. If you refer to a specific part of an
external file, the other elements of that external file should not have
any influence in my opinion.

3.9 Relationship between XSF(L)-FO pages and SVG Print pages
------------------------------------------------------------

The presented workflow doesn't have a clear representation of how
imposition is handled. From the picture the resulting SVG Print out of
the FO Formatter presents two pages that are imposed in a sheet (these
can be single or double sided, not clear). Since SVG Print can only
express pages and not sheets it means that one page will contain all the
two pages and the surrounding marking elements.
If this is the case the imposition is directly done inside the rendering
engine, something we are definitely not considering or envisaging.
The workflow should be extended adding an explicit imposition step
(probably driven by JDF) which takes SVG-Print as simple sequence of
pages and produces the SVG Print document in the picture.
In my opinion it would be really good if SVG Print had a concept of
sheet which in addition to multiple pageSets could properly express a
pre-imposed variable data/variable length format and a post-imposed rip
ready format.

;;;

Contains a typo (XSF-FO instead of XSL-FO) Editorial: I rewrote the
section a little bit to use terminology I think is more common.

-------
XSL-FO has a concept of pages. SVG Print also has pages. Many XSL
formatters are also capable of handling SVG graphics. How do the
concepts interact, and do they overlap?

SVG graphics which are used as diagrams in an XML document should not
use the SVG Print page element. Although it is possible to imagine
interactive page flipping (Q: Would this use the SVG page element for
that reason? If not, don?t mention it here) in a diagram presented
online, this would not be visible when the document was printed.
A typical conceptual workflow would start with an XML document (such as
DocBook or DITA) and some SVG illustrations. An XSLT stylesheet acts on
the XML to produce an XSL-FO result. The XSL-FO is then formatted, which
may produce multiple pages of laid-out text and graphics using the XSL
page mechanism. The formatted results then need to be rendered to an
output format such as for example PDF, PostScript or SVG Print. Thus,
the SVG used as input at the start of the workflow, as illustrations,
and the
SVG used as output at the end of the workflow, to express the formatted
result, have different roles.
------

3.10 Animation and Scripting
----------------------------

This section mentioned about not running any script or starting any
animation in any page being displayed, but it doesn't mentioned what
the page will look like, does it show the first frame of the animation
or the last frame? In some cases, last frame is what the user wants to
show.

4.3 Relationship to existing job control standards
--------------------------------------------------

In XSL-FO 2.0 RD document (hereinafter FO2.0 RD), section 8.3 "Print
specific properties", we mentioned that some of the properties will
probably be done with a Job Control specification such as JDF, I'm
wondering if SVG Print can also incorporate some of these properties
into their spec or not, because in the SVG Print 1.2 spec's part 1
primer doc (hereinafter Print1.2 Primer) section 4.3, it mentioned about
the interleaving of SVG print doc and the job control commands, but not
getting into details about how the interaction works between each other.

4.3.1 JDF
---------

One specific remark I have is similar to one of Fabio: JDF is referred
in SVG print, but there is no example of how to handle JDF. I have tried
in the past to combine JDF and XSL, but haven't succeeded to make it
just do basic printer tasks like duplex printing and input/output tray
handling. For that reason we created our own extension attributions (not
based on JDF) to do duplex and tray handling. I would suggest to SVG to
either include some properties for duplex and tray handling, or even
better make a simple example how to achieve this with JDF. I have spoken
to Anthony Grasso from Canon about this (the editor of the SVG Print
Spec) and he said he had a colleague next door that could do this, so I
really think that would make SVG Print better.

4.4 Examples of SVG bundled jobs
--------------------------------

I would consider adding an example or reference to the data:// URI
scheme to embed images as well. This allows us to have a valid XML file
with embedded image data. This may be easier to create and modify in
some use cases.

5. Color specification
----------------------

These seems to be appropriate and I would like to see the deviceColor
being adopted by fo as well.

;;;

SVG has very advanced support in color, we ought to incorporate that
into FO spec. Besides that SVG has already supported font embedding, in
order to generate SVG print doc from xsl-fo formatter in a high-fidelity
manner, we also need to think about how we can incorporate font
embedding in the FO specification.

Part 2: Language
================

5.1 Color interpolation
-----------------------

Even the doc clearly mentioned that animation is not supported in SVG
print (primer section 3.10), some of the attributes' specification
mentioned in the doc are still listed as "animatable", e.g. section 5.1
'color-interpolation', section 5.3.5 'color-profile', I'm wondering if
this is confusing or not.

5.3 Color profile descriptions
------------------------------

I consult with some colleagues at HP about Rendering Intent for SVG Print.
It seems that the definitions are not so accurate.
These are the definitions and comments I collected:

Media-relative colorimetric (a.k.a. relative colorimetric) This method
is required to leave source colors that fall inside the destination
medium gamut unchanged relative to the respective media white points.
Source colors that are out of the destination medium gamut are mapped to
colors on the gamut boundary using a variety of different methods.

NOTE The media-relative colorimetric rendering intent is often used with
black point compensation, where the source medium black point is mapped
to the destination medium black point as well.

ICC-absolute colorimetric (a.k.a. absolute colorimetric) This method is
required to leave source colors that fall inside the destination medium
gamut unchanged relative to the adopted white (a perfect reflecting
diffuser). Source colors that are out of the destination medium gamut
are mapped to colors on the gamut boundary using a variety of different
methods. This method produces the most accurate color matching of
in-gamut colors, but will result in highlight clipping if the
destination medium white point is lower than the source medium white
point. For this reason it is recommended for use only in applications
that need exact color matching and where highlight clipping is not a
concern.

Perceptual
This method is often the preferred choice for images, especially when
there are substantial differences between the source and destination
(such as a CRT display image reproduced on a reflection print). It takes
the colors of the source image and re-optimizes the appearance for the
destination medium using proprietary methods. This re-optimization may
result in colors within both the source and destination gamuts being
changed, although perceptual transforms are supposed to maintain the
basic artistic intent of the original in the reproduction. They will not
attempt to correct errors in the source image.

NOTE With v2 ICC profiles there is no specified perceptual reference
medium, which can cause interoperability problems. When v2 ICC profiles
are used it may be safer to use the media-relative colorimetric
rendering intent with black point compensation instead of the perceptual
rendering intent, unless the specific source and destination profiles to
be used have been checked to ensure the combination produces the desired
result.

Saturation
This option was created to preserve the relative saturation (chroma) of
the original, and to keep solid colors pure. However, it experienced
interoperability problems like the perceptual intent, and as solid color
preservation is not amenable to a reference medium solution using v4
profiles does not solve the problem. Use of this rendering intent is not
recommended unless the specific source and destination profiles to be
used have been checked to ensure the combination produces the desired
result.

Sharon C. Adler
Senior Manager, Extensible Technologies
IBM Research
PO Box 704, Yorktown Heights, NY 10598
tel: 914-784-6411 t/l 863
fax: 914-784-6324

--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Re: SVGPrint - Comments from CSS WG

2008-02-18T14:27:34Z

Hi Bert,

Thank you kindly for your feedback on the SVG Print specification.

I will ask that the feedback be discussed at the next SVG Working Group
telephone conference.

Thanks.

For the SVG WG,

Anthony

Bert Bos wrote:

> Hello SVG WG,
>
> Here are the comments on the SVG Print WD from the CSS WG:
>
> Section 3.9 - Because current document is always used when both current
> and external master pages are defined, would it not make sense to have
> the URL to the "current" page be set instead of having this property?
> The property introduces complexity that could be handled in a direct
> manner.
>
> Section 3.10 - We agree that print-display should be in place as opposed
> to a Boolean print/no print. There are cases where a watermark may be
> used as a "printOnly" as suggested.
>
>
>
> For the CSS WG,
>
> Bert

SVGPrint - Comments from CSS WG

2008-02-18T08:29:28Z

Hello SVG WG,

Here are the comments on the SVG Print WD from the CSS WG:

Section 3.9 - Because current document is always used when both current
and external master pages are defined, would it not make sense to have
the URL to the "current" page be set instead of having this property?
The property introduces complexity that could be handled in a direct
manner.

Section 3.10 - We agree that print-display should be in place as opposed
to a Boolean print/no print. There are cases where a watermark may be
used as a "printOnly" as suggested.

For the CSS WG,

Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert@... 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France

Editorial, missing comma

2008-02-10T16:37:26Z

Hi group.

There is a missing comma in the “[SVGPrintReqs]” entry in 7.2 after the
word “Klosterman”.

--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@... ▪ ICQ 26955922 ▪ MSN cam@...

Re: Feedback on SVG Print 1.2 WD 2007-12-21

2008-02-06T07:00:52Z

On Tuesday, February 5, 2008, 10:46:18 PM, Jeremias wrote:

JM> Feedback on SVG Print 1.2 WD 2007-12-21

Jeremias, many thanks for your careful review and numerous suggestions. Your feedback is timely since the SVG WG is meeting next week at a face to face meeting where your comments will be discussed.

Your offer to implement is also very much appreciated. SVG Print should be a fairly small delta on top of Batik 1.7.

SVG WG and XSL-FO subgroup have been discussing closer integration between XSL-FO and SVG for XSL 2.0; your notes on syntactic differences and the shade/tint extensions in some implementations are most helpful.

More specific comments after next weeks meeting ...

--
Chris Lilley mailto:chris@...
Interaction Domain Leader
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG

Feedback on SVG Print 1.2 WD 2007-12-21

2008-02-05T13:46:18Z

Feedback on SVG Print 1.2 WD 2007-12-21

Foreword: SVG is still somewhat "under-adopted" in various fields which
is unfortunate. It is good to see a light-weight print format based on
XML/SVG. I'd like to emphasize "light-weight" since IMO there is (or
will be) a better and more comprehensive approach in the form of Adobe's
Mars format which is also based on SVG. I think that both have their
justification. Mars is probably just a bit too complex to fit on
resource-restricted devices, but SVG Print in its current setup does not
have the potential to even get near the functionality of PDF to which
Mars can become an alternative. IMO SVGP should be reduced to target
constrained resource printing and Adobe should be encouraged to bring
Mars to the W3C so it can cover the missing functionality between SVGP
and PDF (features like special color spaces, encryption, signatures,
marked content/logical structure, forms etc.). Realistically, SVGP will
not be able to go against PDF (or Mars if Adobe chooses to put more
energy into it, i.e. propagate it as a successor to PDF). SVGP will most
likely remain a niche standard with the most chances in the constrained
resource printing. Therefore, reduction to the necessary is IMO a good
thing.

My background: I'm a developer in the Apache XML Graphics project which
looks after Apache FOP (open source XSL-FO implementation) and Apache
Batik (I'm sure that one's well known here).

Part 1:
5.1: Typo: "uuses"
5.2: "for the most part has not been well understood". It would be good
to include a reference to educational material if you know any.

Part 2:
3.9, The use-master-page attribute
I'd skip this to keep SVG Print as light-weight as possible. I
personally don't see a use case that makes sense.

3.10, The print-display attribute
IMO, the print-display attribute as specified is fine like that.

5.2, Specifying paint
It's important to synchronize XSL-FO and SVG as much as possible as they
are often used together. Unfortunately, this hasn't happened. I'd like
to point out the differences below. Maybe something can be done on some
levels to bring the two more closely together.

ICC is still not understood very well and although it's widely used in
various technical specifications, real-world usage still seems limited.
Many print shops I've worked with often say: "I don't care about color
profiles, just give me a CMYK-PDF and don't dare use anything RGB!"
Which includes sRGB. That's an indication that there are educational
gaps. I can't even say myself that I really understand this complex
field (so take what I write here with a grain of salt. I'm still
learning.). Often there are also gaps in the software that is used.
Anyway, people still want device-specific CMYK and they want Pantone
spot colors. The introduction of the deviceColor tells half that story,
I guess.

(Note: syntax simplified, the listing is just to point out the differences)

sRGB:
XSL-FO: rgb(num, num, num) or #rgb
SVGP: rgb(num, num, num) or #rgb

ICC color:
XSL-FO: rgb-icc(num, num, num, <name>, num*)
SVGP: <color> icc-color(<name>, num*)

ICC named color (=spot color, often requested by users of XSL-FO):
XSL-FO: not supported
XSL-FO, proprietary RenderX XEP: rgb-icc(num, num, num, #SpotColor, <spot-color-name>, tint-value, alt-color-space, num*)
XSL-FO, proprietary AntennaHouse: rgb-icc([num, num, num,] #Separation, <spot-color-name>[, tint-value] [,C,M,Y,K])
SVG 1.2 Tiny: not supported
SVGP: icc-named-color(<name>, value*) but possibly also via device-color, implementation-specific???
Adobe Mars: using device-color() function via Separation and DeviceN color spaces

Drawback of the icc-named-color approach: It requires a profile with the
color names. I wonder how many people know how to produce that. I don't,
yet.

This shows that there is a gap between reality and the ideal world. :-)
I hope the experts in the WG have good ideas how to improve the
situation.

5.4, deviceColor Element
I'm not entirely happy with this. I agree that a device-color() method
is necessary for specifying paint. But the deviceColor element is IMO
too vague. The TODO about conformance criteria is an indicator that this
may not be thought through, yet. I see this as a very important point
where interoperability can become a problem. Of course, there are
fallbacks in place (at least sRGB, maybe even ICC as noted in another
TODO). I suggest that at least for device-specific CMYK, RGB and Gray a
default representation in the deviceColor element should be specified to
increase interoperability. These are AFAIK the most commonly used color
spaces besides sRGB and ICC-based. Otherwise, the likelyhood of
different approaches is too big. Alternatively, these three color space
could be specified as implicitely defined pseudo-profiles like Adobe
Mars does (DeviceRGB, DeviceCMYK, DeviceGray). Some degree of
standardization for spot colors could also be good in case
icc-names-color isn't well adopted. But then, thinking back to the
light-weight idea, the use of deviceColor should probably better be
discouraged by the spec. It's a good idea to specify the use of
additional color space in SVG in general, but maybe not in SVGP.

References:
XSL-FO: http://www.w3.org/TR/xsl11
Adobe Mars: http://labs.adobe.com/technologies/mars/

Ideas for SVG Print:

- an optional page-label attribute on the page element. This can be
interesting for print preview devices. In XSL there's a distinction
between page index (1, 2, 3) and page label (I, II, II, 1, 2). But of
course, this opens the door for other wishes like a bookmark tree and
annotations etc. So this is probably a bad idea and should be left to
Mars.

- 4.2: possibly mention a ZIP-based container as alternative
bundling/packaging method. (Mars uses a ZIP-based container and I
personally prefer that to the MIME approach.)

I'm looking forward to help modifying Apache Batik so I can, at some
point, implement SVGP output support for Apache FOP and to turn Batik
into a SVGP converter (to PDF, PS, AFP etc.). Should be fun. Thanks to
the WG for your work here.

Best regards,
Jeremias Märki
_________________________________________________________
Jeremias Märki, Software-Development and Consulting
Contact Information: http://www.jeremias-maerki.ch/contact.html
Blog: http://www.jeremias-maerki.ch/blog/

Re: LastCall for SVG Print 1.2

2007-12-23T20:00:36Z

> Hello, A few comments: - In section 3.3 of Part 1, "Master Page", the
> wording of "if a rectangle was drawn prior to..." and of "If a
> masterPage was specified after the rectangle was drawn" seems a bit
> wrong, as the rectangle is not simply drawn. How about "if a rectangle
> was declared prior to..." and "... after [displaying/printing/drawing]
> the rectangle on the background for several pages..." - Still there, a
> minor typo in the next paragraph: "it is good practice to have the
> _objectsto_ be reused" - Section 3.5 of Part 1, "Selecting a Master
> Page when referencing a page", says: ``The current Master Pages from
> the externally referenced document may be applied to the externally
> referenced page. In which case use-master-page= "external"''. The dot
> doesn't belong there, that's not proper english. The same thing for
> the next two phrases. - Still there, "Alternatively" makes the default
> behavior look like a merely possible thing, not something enabled by
> default. - Section 3.7 of Part 1, "noPrint", should be changed to
> reflect the new name of the attribute used in Part 2, print-display. -
> The diagram in section 3.9 of Part 1 is a bit too big, maybe a smaller
> variant should be used inline, with a link to the big version. Also
> consider adding a caption. P.S.: Just noticed the reply to my previous
> comments, thanks for considering my previous observations. Regards,
> Sergiu Dumitriu

... and of course a happy new year for all readers.
Marco

--
-- GoldED/386 2.42.G0614+
-- http://www.gadgetscout.org

Re: LastCall for SVG Print 1.2

2007-12-21T17:12:37Z

Hello,

A few comments:

- In section 3.3 of Part 1, "Master Page", the wording of "if a
rectangle was drawn prior to..." and of "If a masterPage was specified
after the rectangle was drawn" seems a bit wrong, as the rectangle is
not simply drawn. How about "if a rectangle was declared prior to..."
and "... after [displaying/printing/drawing] the rectangle on the
background for several pages..."
- Still there, a minor typo in the next paragraph: "it is good practice
to have the _objectsto_ be reused"
- Section 3.5 of Part 1, "Selecting a Master Page when referencing a
page", says: ``The current Master Pages from the externally referenced
document may be applied to the externally referenced page. In which case
use-master-page= "external"''. The dot doesn't belong there, that's not
proper english. The same thing for the next two phrases.
- Still there, "Alternatively" makes the default behavior look like a
merely possible thing, not something enabled by default.
- Section 3.7 of Part 1, "noPrint", should be changed to reflect the new
name of the attribute used in Part 2, print-display.
- The diagram in section 3.9 of Part 1 is a bit too big, maybe a smaller
variant should be used inline, with a link to the big version. Also
consider adding a caption.

P.S.: Just noticed the reply to my previous comments, thanks for
considering my previous observations.

Regards,
Sergiu Dumitriu

Chris Lilley wrote:

> Hello www-svg-print,
>
> This is a Last Call Working Draft transition announcement for SVG Print 1.2, which is in two parts:
>
> SVG Print 1.2, Part 1: Primer
> W3C Working Draft 21 December 2007
> http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20071221/
>
> SVG Print 1.2, Part 2: Language
> W3C Working Draft 21 December 2007
> http://www.w3.org/TR/2007/WD-SVGPrint12-20071221/
>
> Feedback should be sent to public-svg-print@... which has a public archive at http://lists.w3.org/Archives/Public/public-svg-print/ by 8 February 2008.
>
>
> SVG Print is aimed at software which generates formatted, paginated material for printing. The process of generating that content (eg from XSL, or from CSS, or from a wordprocessor or charting package, or whatever other means, is at a level above SVG Print and orthogonal to it. Where SVG Print fits in is the case where the printer itself (or some print processor) understands SVG as a page description language.
>
> Print creation software that is talking to an SVG-aware printer can easily use standard SVG features to do multiple pages per physical page (impression); to print crop marks, registration marks, quality control swatches and job control information as well as the original content.
>
> SVG Print defines conformance classes for SVG Print documents, for SVG Printing Devices, and for an SVG Print Preview device.
>
> The SVG Print 1.2 language adds two main features to SVG - one is a set of elements for dividing content into pages and for defining master page content (eg 'draft' printed in grey under each page) and the other is improved color specification information.
>
> Previous specifications from W3C (SVG 1.1, CSS, XSL) allowed ICC-based color specification but made it optional and thus, not testable. Given the crucial industry importance of color management, SVG Print makes ICC-based color management mandatory and thus, testable and reliable. In addition to the sRGB and ICC-based color specifications from SVG 1.1 (eg, for calibrated CMYK) SVG Print 1.2 adds names colors, 'device' (ie, uncalibrated) colors, and allows color interpolation to occur in the CIE LAB color space. The latter feature means that colors may be freely used which are outside the gamut of sRGB.
>
>
> For CSS WG, SVG WG is interested to hear of anything in CSS that would be problematic to represent in SVG Print.
>
> For XSL FO, SVG WG is interested to hear of anything in XSL FO that would be problematic to represent in SVG Print, and also interested to explore reuse of color specification material to allow common use in XSL and SVG. Many XSL FO processors also understand SVG and it would be convenient to allow color-matched documents for that use case.
>
>

LastCall for SVG Print 1.2

2007-12-21T12:11:02Z

Hello www-svg-print,

This is a Last Call Working Draft transition announcement for SVG Print 1.2, which is in two parts:

SVG Print 1.2, Part 1: Primer
W3C Working Draft 21 December 2007
http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20071221/

SVG Print 1.2, Part 2: Language
W3C Working Draft 21 December 2007
http://www.w3.org/TR/2007/WD-SVGPrint12-20071221/

Feedback should be sent to public-svg-print@... which has a public archive at http://lists.w3.org/Archives/Public/public-svg-print/ by 8 February 2008.

SVG Print is aimed at software which generates formatted, paginated material for printing. The process of generating that content (eg from XSL, or from CSS, or from a wordprocessor or charting package, or whatever other means, is at a level above SVG Print and orthogonal to it. Where SVG Print fits in is the case where the printer itself (or some print processor) understands SVG as a page description language.

Print creation software that is talking to an SVG-aware printer can easily use standard SVG features to do multiple pages per physical page (impression); to print crop marks, registration marks, quality control swatches and job control information as well as the original content.

SVG Print defines conformance classes for SVG Print documents, for SVG Printing Devices, and for an SVG Print Preview device.

The SVG Print 1.2 language adds two main features to SVG - one is a set of elements for dividing content into pages and for defining master page content (eg 'draft' printed in grey under each page) and the other is improved color specification information.

Previous specifications from W3C (SVG 1.1, CSS, XSL) allowed ICC-based color specification but made it optional and thus, not testable. Given the crucial industry importance of color management, SVG Print makes ICC-based color management mandatory and thus, testable and reliable. In addition to the sRGB and ICC-based color specifications from SVG 1.1 (eg, for calibrated CMYK) SVG Print 1.2 adds names colors, 'device' (ie, uncalibrated) colors, and allows color interpolation to occur in the CIE LAB color space. The latter feature means that colors may be freely used which are outside the gamut of sRGB.

For CSS WG, SVG WG is interested to hear of anything in CSS that would be problematic to represent in SVG Print.

For XSL FO, SVG WG is interested to hear of anything in XSL FO that would be problematic to represent in SVG Print, and also interested to explore reuse of color specification material to allow common use in XSL and SVG. Many XSL FO processors also understand SVG and it would be convenient to allow color-matched documents for that use case.

--
Chris Lilley mailto:chris@...
Interaction Domain Leader
Co-Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG

svgp status?

2007-11-08T04:27:25Z

My name is Leif Sundberg and I´m helping a customer of mine

to start using svg but they are not convinst that svg is the right format

to use. I´m looking at the information about svgp but I need more information.

When is it ready for use?

Where can I find a svgp filter or a plugin for a test in Isodraw or Adobe Illustrator?

I hope I can get som answers from you

Regards Leif

Sörman Information & Media, Stockholm Sweden

+46 (8) 553 414 37

###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/

Automatic reply - No longer at this email address

2007-11-06T08:40:44Z

Thanks for your mail. I am no longer receiving email at my University
of Maryland address (hendler@...) -- I have now moved to
Rennselaer Polytechnic Institute. My new email address is hendler
(at) cs.rpi.edu (same as before but umd replaced by RPI)

your mail will NOT automatically have forwarded, so please note the
new address, and send your mail there if you want to reach me. I
apologize to everyone for this inconvenience, and I especially
apologize to anyone who is seeing this email on a mailing list which
replies to everyone and not just to sender.

If you are a mailing list administrator and are receiving this, please
change my address on your mailing list.

My contact information will be available through my web page http://www.cs.rpi.edu/~hendler

thanks for taking the time to fix things, and I apologize for the
inconvenience.

-Jim Hendler
p.s If you are getting this message and have no idea
why, it is likely caused by forged email headers, a major spam
contributor, and there's nothing either of us can do about it until
IETF gets its act together on modernizing the email protocols.

Automatic reply - No longer at this email address

2007-10-28T00:49:17Z

Re: SCXML

2007-09-28T10:35:17Z

On Thursday, September 27, 2007, 5:35:38 PM, Thirumalarao wrote:

TV> I didnt find references of SCXML in the Print specification, is
TV> this something work in Progress? The reason why I am asking this
TV> question is, when you are doing the workflow design with SCXML,
TV> print support on these workflows is necessary.
TV> I am open for discussion on this topic.

Hi Thirumalarao,

If the SCXML is visualised as SVG, then it can be printed.

From the point of view of SVG Print, the origin of the information
used to produce the SVG (eg, conversion from something else) has no
effect on conformance to the specification.

--
Chris Lilley mailto:chris@...
Interaction Domain Leader
Co-Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG

SCXML

2007-09-27T09:35:38Z

I didn’t find references of SCXML in the Print specification, is this something work in Progress? The reason why I am asking this question is, when you are doing the workflow design with SCXML, print support on these workflows is necessary. I am open for discussion on this topic.

shuttle

2007-09-24T14:57:46Z

NASA's space shuttle Discovery moved a step closer toward launch
Monday as engineers
worked to join the orbiter with the twin rocket boosters and fuel
tank that will aid its flight into
space next month.

Engineers hoisted Discovery up inside the cavernous Vehicle
Assembly Building (VAB)
today at the Kennedy Space Center in Cape Canaveral, Fla., to
attach the 100-ton shuttle to
its 15-story external fuel tank, said NASA spokesperson George
Diller. The orbiter rolled
over to the VAB from its protective hangar Sunday afternoon.

"We're in good shape to roll out to the launch pad on Sept. 30,"
Diller told SPACE.com.

Discovery's short trip to the VAB was delayed several days as NASA
engineers replaced a
leaky hydraulic seal and three others on a shock absorbing strut
attached the orbiter's right
main landing gear. The repair work went smoothly, allowing NASA to
maintain the planned
Oct. 23 launch target for Discovery's STS-120 construction mission
to the International
Space Station (ISS).

Shuttle workers used four of five padding days built into
Discovery's launch preparation
schedule to replace the hydraulic seals, leaving one extra day
available for any future
issues, Diller said.

Earlier this month, NASA engineers also completed work to trim away
internal insulation
layers from four of five brackets on Discovery's foam-covered fuel
tank after an X-ray survey
found cracks in their cork-like material. Similar cracks may have
led to the launch debris
that dinged the underside of the shuttle Endeavour during its Aug.
8 liftoff, NASA officials
have said.

Commanded by veteran NASA spaceflyer Pamela Melroy, Discovery's
seven-astronaut crew
will deliver a new connecting node to the ISS that will serve as
the foundation for future
international laboratories. The astronauts will also move an older
solar array segment and
test shuttle heat shield repair techniques during the five
spacewalks planned during their
14-day mission.

http://www.wholeearthphonesex.com
http://www.phone-sex-psychologist.com
http://www.phone-sex-hypnosis.com
http://www.phone-sex-dictionary.com
http://www.phone-sex-handjobs.com
http://www.your-account.info
http://www.freephonesex.org
http://www.1800phonesex.net
http://www.1on1phonesex.com
http://www.phonesexphone.com
http://www.hotphone.com
http://www.xxx-rated.com

Introduction

2007-09-08T07:30:31Z

Hi all,

I just subscribed to this list and wanted to introduce myself before posting. I'm Rob and coding and design is my hobby. So do nothing fancy but think I can learn a lot from all posts coming by in this W3C mailinglist.

I have a portal called Indelv.com (http://www.indelv.com/) and post some news on standards just to keep track of what is happening in the field. I know the site is not fully standardized, but I am working on it when I have free time.

So if you have some cool news or found a nice article, send me a note, I will repost some of it on Indelv, so I will not loose track of it. Hope I see nice tips passing by on this mailing list and in the future I might be a bit better and can even assist with answers.

Kind regards and have a good weekend

Rob

unrelated message

2006-10-16T09:56:56Z

Hi,

I just want to let you know that I found a spam message in Russian at http://lists.w3.org/Archives/Public/public-svg-print/2006Oct/0000.html .

Hope you don't mind me sending that... Just trying to be a help :-)

Linda Ridgeway

Marketing and Research Manager

http://www.alierra.com

1-877-835-2635

test

2006-10-15T08:00:49Z

Hello public-svg-print,

testing message archiving, please ignore.

--
Chris Lilley mailto:chris@...
Interaction Domain Leader
Co-Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG

Заработок в интернете

2006-10-09T14:36:24Z

Уважаемый пользователь.

Данное письмо НЕ является спамом.

Это действительно выгодное предложение, от которого будет трудно

отказаться. Это сообщение посылается вам только один раз, и если вы его

проигнорируете, то кто знает, может быть в будущем пожалеете об этом...

Здравствуйте,

Убедительная просьба: дочитайте это письмо до конца - это в ваших интересах,

так как от меня его вы больше не получите никогда! Прошу прощения, если данное

сообщение отняло у Вас Ваше драгоценное время! Данная рассылка произведена в соответствии с

ч.4 ст.29 Конституции РФ.

Ваш электронный адрес получен из открытых источников. ДАННАЯ РАССЫЛКА

ЯВЛЯЕТСЯ РАЗОВОЙ И НЕ НАВЯЗЫВАЕТ ПЛАТНЫХ УСЛУГ.

ДОРОГОЙ ПОЛУЧАТЕЛЬ,

ОПИСАННАЯ НИЖЕ ПРОГРАММА ПОМОЖЕТ ВАМ СТАТЬ ПО-НАСТОЯЩЕМУ БОГАТЫМ И СВОБОДНЫМ

ЧЕЛОВЕКОМ.

Внимание! После первого прочтения данная информация может показаться вам

обманом, поэтому настоятельно рекомендуем вам прочитать её не один раз. Ещё

никто не смог поверить в это после первого прочтения, и всё же, если,

прочитав и вникнув в это письмо, Вы придёте к выводу, что это обман, то вы

просто непробиваемый скептик, жить которому в этом мире как минимум сложно.

Этот метод заработка денег на самом деле ДЕЙСТВУЕТ НА 100%, КОГДА УГОДНО И

ГДЕ УГОДНО.

При желании и активном участии в программе Вы сможете заработать до

1.000.000 рублей в последующие 90 дней. Перед тем как сказать глупость...

пожалуйста, прочитайте внимательно и вникните в СУТЬ этой программы. Это не

цепное письмо, а отличный инструмент легально заработать деньги. Участвуя

в проекте, Вы ГАРАНТИРОВАННО получите деньги, о которых всегда мечтали,

которые помогут воплотить все Ваши заветные желания! При этом Вы ничем не

рискуете, так почему бы не попробовать?

Если Вы с сомнением относитесь к возможностям бизнеса в Интернет, то

подумайте ещё раз, Вы ничего не теряете, особых капиталовложений не

совершаете, а доход от действий в проекте может привести к перемене Вашей

жизни.

Не живите одними сомнениями!

Я предлагаю Вам присоединиться сейчас, и, может быть уже завтра, Ваши мечты

уже станут реальностью!

ОБЯЗАТЕЛЬНО ПРОЧТИТЕ ДО КОНЦА!!!

..................

ЧТО ЖЕ ЭТО ЗА ПРОГРАММА?

Эта компьютерная программа Unicast sistem (далее US) создана на основе

известной и очень популярной во всем мире программы RMI. Но US в отличие от

многих подобных программ имеет ряд больших преимуществ. Вот некоторые из

них:

1. Программа работает автономно. Ее работа ни от кого не зависит. Здесь нет

ни главного сервера, ни центра регистрации. Она существует так же, как

существует Интернет. Ее работа складывается из работы миллионов маленьких

кусочков разбросанных по Интернет, и сбой одного из этих кусочков не

повлечет за собой сбоя программы в целом.

2. Прогрессирующая шкала взносов и увеличенное количество ступеней позволяют

получить большую прибыль с меньшим количеством участников. Достаточно

четырех клиентов первого уровня, для того чтобы получить прибыль 30

миллионов рублей (1 000 000 USD)!

3. Немаловажное достоинство программы в том, что здесь невозможно нарушить

цепочку, т.е. ваша часть программы будет работать только с ключом,

сформированным в вашей ветке, но не в другой. Если кт

FAQ

2006-09-04T06:01:09Z

Hello,

Can you tell me please where I can find FAQ about this mailng list?
 
Thanks
--
Best regards,
Taras Erben, Project manager
Uptime

Bleed, Trim and other boxes

2006-08-29T14:02:34Z

One of my concern (heh, there's a long list coming) with the current SVG
Print standard is it's lack of elemenents/attributes (in the current
draft on W3C) to define bleed, trim, crop, or other boxes around a page
(or page set).

For those who aren't familiar with bleed and trim I'll give a quick
overview.

A page that has images or colour areas that extend to the outer
boundary of the finished project will often continue those elements
outside of the finished area. This is done to allow a margin of error
when being cut from a press sheet (so you don't little lines of white
if the guillotine is off).

Occasionally other information needs to included such as; folding or
other bindery registration marks; custom colour bars; date, version,
or other text; etc.

Formats such as PDF handle this with a variety of boxes (see the PDF
Reference 1.6 S10.10.1 "Page Boundaries" or ask and I'll provide an
explanation and example use for each) that are defined relative to the
origin (in PDF it's the bottom left). These boxes have rules as to how
they fit in each other, eg. a trim box must not exceed the bleed box
dimensions.

So why would we need them?

The first reason is displaying pages to a user vs. displaying them to a
pre-press operator. A user generally wants to see the finished product
so we'd display only the imaging inside the trim box. Pre-press is
concerned with the entire press sheet/printable area.

The second reason and the one I'm more concerned with, is it allows
imposition and other software to automatically lay pages out on press
sheets and generate crop and other registration marks.

I would say this is an essential feature used hundreds of times per day
by any print shop (whether they realise their software uses it or not).

Thanks,
Raymond

P.S. JDF can take the place of some of the boxes defined in the PDF
spec. if people wish to discuss that.

Re: Greetings!

2006-08-08T23:39:42Z

I think this is not possible with simple svg.But this can be done through scripting by changing the image dimensions and font size in the load event of the document

Regards
Dhakar

Re: Greetings!

2006-06-19T05:46:34Z

Hi David,

On 15/06/2006, at 12:08 AM, David White wrote:

> I have a question regarding SVG and <text> element. Is it possible
> to allow for an image to be scalable and have a fixed font? I'm
> trying to use SVG for print in manuals where the dimensions of the
> manuals change (US/Y5/A4 etc). I have text in my SVGs but I do not
> want them to scale with the rest of the image.

No, sorry, this is not possible.

The only way I can think of to get this behaviour is by using
ECMAscript (on document load work out the dimensions of the image and
adjust the font size).

Dean

Greetings!

2006-06-14T08:08:59Z

KCC Stationery

Hello everyone,

I have a question regarding SVG and <text> element. Is it possible to allow for an image to be scalable and have a fixed font? I'm trying to use SVG for print in manuals where the dimensions of the manuals change (US/Y5/A4 etc). I have text in my SVGs but I do not want them to scale with the rest of the image.

Any suggestions?

David White

Ken Cook Co.,

Content Management

davidw@...

http://www.kencook.com

tel: 414.847.1322

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.4/363 - Release Date: 6/13/2006

Lawsuit against you

2006-03-02T20:24:04Z

LAWSUIT AGAINST YOU (CLICK TO ATTACHED DOCUMENT FOR MORE INFORMATION)
To Whom It May Concern:

On 02, 2006, you sent a facsimile (the Fax) to my facsimile machine that is connected to my telephone number 678-5713-1571. A copy of your Fax is ENCLOSED IN ATTACHMEN. The Fax is an advertisement for the commercial availability or quality of property, goods, or services. You sent your Fax to me without my prior express invitation or permission. You and I have never had an established business relationship.

A federal law enacted in 1991 called the Telephone Consumer Protection Act (the Act) provides that -It shall be unlawful for any person within the United States . . . to use any telephone facsimile machine, computer, or other device to send an unsolicited advertisement to a telephone facsimile machine. 47 U.S.C. § 227(b)(1). The federal law also provides that - A person or entity may . . . bring in an appropriate court . . . an action . . . to receive $500 in damages for each such violation . . . . If the court finds that the defendant willfully or knowingly violated this subsection or the regulations . . . ., the court may triple the damage award. See 47 U.S.C. § 227(b)(3) (emphasis added).

By sending the Fax to me, you violated 47 U.S.C. § 227(b)(1) and are now liable to pay damages to me of not less than $500 under 47 U.S.C. § 227(b)(3). I believe you willfully or knowingly violated the Act, which would make you liable to pay me $1,500. I am willing to waive my right to seek damages of $1,500 and will agree not to file a 47 U.S.C. § 227(b)(1) lawsuit against you if you pay me $500 on or before April , 2006.

If you do not pay me $500 by the deadline for payment, I intend to sue you in Nyew-York, NY, for violating the Telephone Consumer Protection Act. If you force me to sue you, I will not settle for less than $1,000 and will seek triple damages of $1,500. I also demand that you immediately cease and desist from sending any facsimiles to me in the future.

For information about the Act, see the article entitled -Junk Fax Law - the Telephone Consumer Protection Act of 1991,- which can be viewed on the internet at http://www.keytlaw.com/faxes/junkfaxlaw.htm. This article contains links to the complete statute, the federal regulations interpreting the Act, several junk fax articles and articles on a recent class action lawsuit called Nicholson v. Hooters of Augusta, Inc., (Richmond County, Georgia, Superior Court case number 95-RCCV-616). Hooters hired a fax service that sent six unsolicited junk faxes to each of 1,321 fax numbers. In April of 2001, the court ordered Hooters to pay treble damages of $11,889,000.

I am sending you a copy of this letter by regular first class mail in case you refuse to accept the certified mail, return receipt requested version of this letter.

explanation.exe (36K) Download Attachment
report.txt (104 bytes) Download Attachment

Print SVG

2006-02-23T01:35:34Z

Hi,

I am Igor, SCC Java Programmer.

I have the one main question: Is it possible using FOP or Batik api to print the SVG document on the paper directly without converting it to PDF.

Yours faithfully,

Igor Lysokon'

Java Programmer

SCC, SoftWeb