[cairo] question about a conversion between XML and CairoScript

[Bryce Harrington]

On Mon, Dec 17, 2018 at 03:06:03PM +0000, suzuki toshiya wrote:
> Hi,
> 
> Recently I'm interested in whether the output of XML surface
> could be converted to that of Script surface (CairoScript),
> because the implementation of the parser for XML output looks
> easier than that of CairoScript.
> 
> There are xml-to-trace and trace-to-xml in util/ subdirectly.
> During a play with them, I found that: trace-to-xml seems
> to be preserving all, but xml-to-trace seems to drop many info.
> 
> --
> 
> Also, I found sometimes the significant difference (between
> XML and Script output) may happen.
> 
> In XML surface, _cairo_xml_emit_surface() tries to dump a
> rasterized image, by using _cairo_surface_acquire_source_image()
> (then _cairo_xml_emit_image() is called).
> 
> On the other hand, in Script surface, _emit_surface() does not
> invoke _cairo_surface_acquire_source_image().
> 
> Considering such difference, I'm afraid that a round-trip
> conversion between the outputs of XML and Script surfaces are
> hard.
> 
> Am I misunderstanding?
> 
> If I understand correctly, for easy-to-parse format of replayable
> data (I think, CairoScript is already proven to be replayable, but
> XML is not), working with current XML surface is not the way to go?
> Should I try to make an XML expression of CairoScript?

These are very good questions, and interesting analysis so far.

The XML backend's original commit has this message from Chris regarding
its original purpose:

2009:
    Add xml surface

    A very simple surface that produces a hierarchical DAG in a simple XML
    format. It is intended to be used whilst debugging, for example with the
    automatic regression finding tools of cairo-sphinx, and with test suites
    that just want to verify that their code made a particular Cairo call.

The CairoScript backend has this commit message:

2008:

    Add CairoScript backend.

    A new meta-surface backend for serialising drawing operations to a
    CairoScript file. The principal use (as currently envisaged) is to provide
    a round-trip testing mechanism for CairoScript - i.e. we can generate
    script files for every test in the suite and check that we can replay them
    with perfect fidelity. (Obviously this does not provide complete coverage
    of CairoScript's syntax, but should give reasonable coverage over the
    operators.)


So, the use cases seem a bit similar - i.e. validation testing - however
their purposes are distinct.  CairoScript intends to be replayable,
while XML is more geared as a (dummy) final output format.  So, given
that, it can be expected that CairoScript -> XML should work but be
lossy, so I don't think we could expect roundtrip's to viably work.

I also suspect there are no worthwhile use cases for the XML backend
beyond testing/debugging.

CairoScript seems to be a bit more powerful/flexible and I recall seeing
a few ideas on other use cases for it beyond testing.  While it may be
harder to parse, it is a more contextually rich data format.

So, I think that other than perhaps adding tags for any missing features
to the XML backend, I don't think it is worth effort to make it
correspond more closely to CairoScript, functionally.  That said, I'd
defer to Chris if he has comments, as both of these backends are his
work.

Bryce