Re: Using/requiring Cairo

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sat, Jun 24, 2017 at 5:54 PM, David Kastrup <address@hidden> wrote:
>> Han-Wen Nienhuys <address@hidden> writes:
>>
>>> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup <address@hidden> wrote:
>>>>
>>>> The first step would likely just involve moving to Cairo data
>>>> structures while keeping most of the current code except where the
>>>> code would duplicate Cairo API calls in a reasonably
>>>> straightforward way.
>>>
>>> I would suggest trying make a GUILE binding of sorts for Cairo,
>>> adding that in parallel to existing GS support, and hacking untili
>>> you have feature parity. Then drop the GS support, and migrate the
>>> cairo data structures more towards the core of the program as
>>> needed.
>>
>> The cost of the Cairo dependency is significant, so it would
>> certainly help if the payback was significant as well.
>
> Another approach could be to integrate it, and use it to replace all
> bounding box computations, but continue to use Scheme expression =>
> string => PS => PDF approach for the evaluation. That would let you
> get rid of some of the crummy code you quoted.

That's the "The first step" bit above, though "Scheme expression" would
likely not be a naked list but a smob containing a Cairo data structure
at its core.  But the output generation would be mostly the same.

But that's not the ultimate end state of course since it makes
generating output via Cairo comparatively low-hanging fruit (mostly
meaning that we have to get the font handling right).

Of course, we want to avoid packing and unpacking Cairo data structures
all the time as well: the basic processing flow should try to stick to
working with one representation.

> In addition, you could create a cross-test mode, where you compare the
> Cairo bounding boxes with the traditional ones, to find bugs.

When the internal data structures change, keeping the previous code
operative might be a whole lot of pain.  I suspect that comparing
results of different compilations/branches might be more feasible even
if the comparison gets less detailed.  But at least memory/performance
comparisons would likely be more representative.

-- 
David Kastrup