- From: Wendell Piez <wapiez@wendellpiez.com>
- Date: Fri, 7 Mar 2025 16:38:22 -0500
- To: XProc Dev <xproc-dev@w3.org>
- Message-ID: <CAAO_-xx0+s-NAWDQtumt54SSmNba+2dt88_7oCShR4Znfx4OAg@mail.gmail.com>
Hello with a followup,
So while FOP does support PNG and TIFF as outputs, there is still a bit
missing.
According to
https://spec.xproc.org/master/head/paged-media/diff.html#c.xsl-formatter it
appears my processor would have to support an "image/png" content type on
the p:xsl-formatter step. The 'parameters' option also offers nothing, or
nothing obvious. While FOP provides runtime switches, in other words, it is
not altogether clear how (in this case) it would or should be configured to
do its thing.
I am able to make PDFs though, which look just as expected. (Probably much
smaller than the raster would be, too.)
And I can probably get oXygen to work for me even if not XProc. (Following
that old thread.) Good enough for one at a time.
Any further insights would be welcome -- regards,
Wendell
On Fri, Mar 7, 2025 at 3:29 PM Wendell Piez <wapiez@wendellpiez.com> wrote:
> Sorry, in usual fashion I just sent this only to Norm:
>
>
> ---------- Forwarded message ---------
> From: Wendell Piez <wapiez@wendellpiez.com>
> Date: Fri, Mar 7, 2025 at 3:28 PM
> Subject: Re: XProc-based rasterizer
> To: Norm Tovey-Walsh <ndw@nwalsh.com>
>
>
> Hi again,
>
> Recently I was asked what are uses of p:identity. Here is one. As an
> alternative to what I just posted:
>
> <p:identity name="svg-file"/>
>
> <p:insert
> match="/descendant::fo:instream-foreign-object[@id='svg-placement']"
> position="first-child">
> <p:with-input port="insertion" pipe="@svg-file"/>
> <p:with-input port="source">
> <fo:root> ...
>
> Since the SVG is on the main input, the identity allows us to capture that
> without having to reference the source port of the pipeline directly.
>
> Question: which one is easier to understand?
>
> Regards, Wendell
>
>
> On Fri, Mar 7, 2025 at 3:21 PM Wendell Piez <wapiez@wendellpiez.com>
> wrote:
>
>> Hi,
>>
>> Thanks Norm and John for comments so far. After reflection, I don't
>> actually regard this as a casting problem but a rendering problem, at least
>> when inputs are SVG. :-)
>>
>> In any case since the same host of questions asked by Norm arises also in
>> the XSL-FO context, I am exploring that option.
>>
>> Apparently FOP can be made to do this (i.e., produce PNG), perhaps I can
>> get that written to the file system somehow.
>> I am looking at prior art as documented here:
>> https://www.oxygenxml.com/pipermail/oxygen-user/2011-June/003664.html
>>
>> This is what I have so far, with an SVG document on the input port:
>>
>> <p:insert
>> match="/descendant::fo:instream-foreign-object[@id='svg-placement']"
>> position="first-child">
>> <p:with-input port="insertion" pipe="source@make-png-from-svg"/>
>> <p:with-input port="source">
>> <fo:root>
>> <fo:layout-master-set>
>> <fo:simple-page-master master-name="svg"
>> page-height="{$height}" page-width="{$width}">
>> <fo:region-body/>
>> </fo:simple-page-master>
>> </fo:layout-master-set>
>> <fo:page-sequence master-reference="svg">
>> <fo:flow flow-name="xsl-region-body">
>> <fo:block>
>> <fo:instream-foreign-object id="svg-placement"/>
>> </fo:block>
>> </fo:flow>
>> </fo:page-sequence>
>> </fo:root>
>> </p:with-input>
>> </p:insert>
>>
>>
>> The question will be how to invoke the formatter to do the right thing.
>>
>> Since I also have some animal bones on the fire (er, beef short ribs in a
>> braise), this is as far as I have made it so far today.
>>
>> If you know already this won't work (even producing a PNG file as a side
>> effect), I'll be interested in more details.
>>
>> Thanks! Wendell
>>
>>
>>
>>
>>
>> On Fri, Mar 7, 2025 at 12:39 PM Norm Tovey-Walsh <ndw@nwalsh.com> wrote:
>>
>>> John Dziurlaj <john@turnout.rocks> writes:
>>> > I'm not sure casting content types would be enough to fully effectuate
>>> a cast that is inherently lossy. When casting from a vector to raster
>>> image, resolution, color spaces, bit depths, aliasing among other things
>>> need to be considered. Such nuances could be handled via option parameters,
>>> but those are implementation-defined.
>>>
>>> I fear even in a rasterize step, some of those are going to be
>>> implementation-defined parameters. Different raster formats support
>>> different color spaces, may support limited resolutions or bit depths, etc.
>>>
>>> What would the “general” parameters be, I wonder?
>>>
>>> - Size
>>> - If width and height are provided, does that change the aspect ratio?
>>> - Resolution
>>> - Color
>>> - Bit depth? Color space? I’m not even sure what the options are
>>>
>>> > There is also the question of which set of casts are supported by a
>>> given XProc processor. Built for purpose steps on the other hand give a
>>> clear contract as to which functionalities are available and which aren't.
>>>
>>> I agree. I think a step is the better answer here.
>>>
>>> Be seeing you,
>>> norm
>>>
>>> --
>>> Norm Tovey-Walsh <ndw@nwalsh.com>
>>> https://norm.tovey-walsh.com/
>>>
>>> > The one serious conviction that a man should have is that nothing is to
>>> > be taken too seriously.--Nicholas Butler
>>>
>>
>>
>> --
>> ...Wendell Piez... ...wendell -at- nist -dot- gov...
>> ...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
>> ...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...
>>
>
>
> --
> ...Wendell Piez... ...wendell -at- nist -dot- gov...
> ...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
> ...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...
>
>
> --
> ...Wendell Piez... ...wendell -at- nist -dot- gov...
> ...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
> ...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...
>
--
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...
Received on Friday, 7 March 2025 21:38:40 UTC