[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using/requiring Cairo

From: David Kastrup
Subject: Re: Using/requiring Cairo
Date: Sun, 25 Jun 2017 13:13:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

address@hidden writes:

> David
>> address@hidden writes:

> My point was:
>> > Though, my conclusion was that pdf is not better than ps regarding
>> > postprocessing, and yes I know that pdf (depending on pdf version) has
>> > some features that ps don't have.
>> But nobody is talking about PDF.
> You seem to have a short memory, from your initial message:
>   last time I looked at Cairo, its PDF generation was not really suitable
>   ...
>   We might also be able to forego creating PostScript as an intermediate
>   stage to creating PDF and create bitmap formats without using PostScript
>   as well (again, this should really speed up things).

So where do you read _anything_ concerning PDF that has _anything_ to do
with how LilyPond creates PostScript?  You changed the topic to
PostScript output, and PDF just does not factor into it.  Neither did
you state that you wanted to process LilyPond's PostScript output and
_then_ convert to a bitmap or PDF.

>> The difference in question is Cairo-generated PostScript vs the
>> PostScript generated by Scheme programming and LilyPond's
>> and .
> The Cairo-generated ps is much less readable than lilyponds.
> If you wanted to get rid of the lilyponds own generation of PS, I 
> offered my help to get it up to speed instead, but you didn't
> understand that since:
>> >> "taking care of PostScript" is not related to converting LilyPond's
>> >> graphics internals to Cairo since LilyPond's graphics internals are
>> >> not written in PostScript.
> You are obviously not understanding my offer and your mind is set on 
> using cairo instead.

I rather get the impression that you are not understanding your offer.

The architectural problems with LilyPond's graphics processing have
nothing to do with PostScript generation.  It would make sense to
delegate a lot of them to Cairo.  When doing that, there is no point in
_not_ using Cairo also for creating output, in particular since it will
provide a number of efficient well-supported targets without extra
effort and will write PDF and bitmap targets (and vector targets and X
and GL targets, very useful for integrated surfaces like Frescobaldi)
without needing to go through Ghostscript.

I don't expect that the Cairo backend for PostScript and even PDF will
start out competitive with what LilyPond has already: I expect a period
where it will be used in parallel with the existing backends, just like
the TeX backend existed for a while when LilyPond produced direct
PostScript output.

Now in particular font handling is a full-blown nuisance occupying
several LilyPond developers.  This will not likely change but move to
the Cairo backend since the payoff for that work is quite higher (for
example, we currently have defective font handling for the separate SVG
backend).  If you want to maintain a separate PostScript backend, this
will include maintaining its font handling.

Can you imagine how much work it would have been separately maintaining
a TeX backend instead of removing it from LilyPond all those years of
LilyPond 2?  Basically you are stating that you want to do exactly that
with the PostScript backend, and I am telling you that it will be more
work than you likely realize.

So you tell me I have no idea what I am talking about but don't bother
to point out _any_ particulars where you consider my analysis faulty.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]