Uses of <p:identity>

About this use of <p:identity> to clarify pipeline structure see also
Erik's book, pp. 201–02.

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...
>