lilypond-devel
[Top][All Lists]
Advanced

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

Re: Missing items to make Cairo ready


From: Jonas Hahnfeld
Subject: Re: Missing items to make Cairo ready
Date: Fri, 30 Dec 2022 12:50:14 +0100
User-agent: Evolution 3.46.2

On Thu, 2022-12-29 at 22:55 +0100, Jean Abou Samra wrote:
> Le 29/12/2022 à 12:19, Jonas Hahnfeld a écrit :
> > (FWIW I don't think it is a good idea to add features that will only
> > work with Cairo. That sounds like a recipe for confusion to me, but I
> > haven't yet had the time to properly look into the merge request...)
> 
> 
> I don't really see what the problem is.
> 
> If you try to use a PNG image in the default PS backend, you
> get a user-friendly warning explaining that you need to run with
> -dbackend=cairo (OK, makes me think I should add this to the default
> SVG backend as well).
> 
> It's not much different from \epsfile being supported in the
> default PS backend but not in the default SVG backend.

It is: \epsfile works with the default PS backend producing PDFs and
PNGs aka what probably 90% of the users care about; the new \image with
PNGs *only* works with the non-default Cairo backend. That is a huge
difference for me.


> PNG embedding should be feasible for the default PS and SVG
> backends too, but I'm not willing to spend time on it.
> 
> 
> > > So, to support \epsfile
> > > and \postscript, we can convert and embed as PNG.
> > > Of course, this means we cannot drop Ghostscript,
> > > but we're not going to do it anytime soon anyway.
> > PNG is a pixel-format, so depending on what users embed images for,
> > this may result in very inferior quality or huge files (if you render
> > at insane dimensions).
> 
> 
> Well, if GS is still around, there is the other route too: create
> PS output via Cairo, and convert to PDF with GS like we're already
> doing. That way, you can have vector graphics into PDF from EPS.

Would we want to go the Cairo -> GS route by default? Then we lose one
big advantage that we wanted to gain from Cairo, keeping everything in-
process. If we don't, we have different output paths depending on
whether the user has \epsfile in the input file, which sounds like a
nightmare to support.

I am not at all convinced by these workarounds just to get Cairo a bit
earlier and avoid walking the proper road to the clean solution (ie
properly deprecating what we don't want to or cannot support).


> That said, for this to be a problem, you need to have an EPS file
> that actually contains vector graphics. My impression is that in
> most cases, users pass files that contain embedded raster graphics,
> probably converted from PNG, JPEG or TIFF in the first place.
> 
> > Which raises another question: How do you embed
> > vector graphics into Cairo?
> 
> Cairo itself doesn't understand PS or PDF (it can just
> embed the EPS content into EPS/PS without actually parsing
> it). For that, I think you would have to use Poppler,
> which has a Cairo backend.

I think this is a bad limitation, and adding more dependencies into the
mix doesn't make it more appealing.


> > I don't agree here. It is hard to sell any migration without some level
> > of parity. We had this with Python 3 and Guile 2, and I think it is
> > even more important for the output backend.
> 
> Sorry, I don't understand what you mean by this. Can
> you elaborate?

The two big transitions that I have been part of tried to cause as
little problems to users as possible: For Python 3, it was hopefully
transparent. All I am aware of were problems found in some support
scripts long after the transition, and those were easily fixed.

For Guile 2.2, all user scores should continue to work and performance
should be comparable. It is true that Scheme library developers had to
migrate code, but in exchange they get proper Unicode support. Overall
the transition finally brought 64-bit binaries on macOS and Windows,
which is significant incentive for users to upgrade.

With Cairo, I am not aware of benefits for our users, it is more
motivated by internal maintenance considerations - please correct me if
I'm wrong. In order to "sell" this to users, we must at the very least
not make their experience worse in any regard. Otherwise I fear that
part of the community will stick with an older version because it is
superior in their eyes. IMHO we must avoid this situation as hard as we
can. (From my point of view we had a similar issue, at least until very
recently, with 2.18.2 simply because it was around for "too long".)

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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