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: Sun, 08 Jan 2023 13:16:38 +0100
User-agent: Evolution 3.46.2

On Sun, 2023-01-08 at 12:11 +0100, Han-Wen Nienhuys wrote:
> On Sat, Jan 7, 2023 at 10:16 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> > > > Furthermore, I'm not a fan of recommending two different ways of
> > > > creating PDFs to users (once directly via Cairo and once with ps2pdf),
> > > > unless we really, really have to.
> > > 
> > > We don't really, really have to, but the advantage of dropping \epsfile
> > > and \postscript isn't big either, as their Cairo implementation is not
> > > complicated and can largely share code with the implementation of
> > > other image formats. It may also be useful for people who still use
> > > the PS/EPS output directly and not PDF output (there probably aren't
> > > many for PS, but EPS might be a bit more common?).
> > 
> > That's not really my point; if we keep markup commands that only work
> > via this very specific ps2pdf conversion, we have to guarantee that
> > users get the same visual output as direct PDF output. Do we want to
> > support this? Does Cairo guarantee this for all possible cases that we
> > run into? I highly doubt this is a good rabbit hole to go into...
> > 
> > If we don't do that the error text of \epsfile and \postscript in the
> > default PDF mode has to be "please use this ps2pdf conversion (which we
> > don't even ship with our binaries), and by the way, your PDF will look
> > different". That sounds horrible.
> 
> The discussion was about deprecating \postscript and/or \eps-file.
> There are 2 different ways to understand "deprecate"
> 
> 1. "We are going to remove this command shortly; use the following
> instructions to migrate to the supported XYZ command"
> 
> 2. "We recommend against using this command in new material; use XYZ instead."
> 
> I am arguing against definition 1. If we remove a command, especially
> an open-ended one like \postscript, we are adding a new roadblock to
> users that want to use the latest version of LilyPond, either because
> they want better typography or because they need support for newer
> platforms (eg. windows 64-bit, Apple silicon). The cost of adding this
> roadblock is high for users, while its benefit (not having an ugly
> error message in our code base) is small.

Yes, and I want definition 1: deprecate in 2.26, remove in 3.0 (in
acknowledging the cost). Because from my point of view, the "cost" is
not just the error message, but the entire approach of recommending to
export PS from Cairo and then use Ghostscript to get an inferior PDF.
Which I would argue is entire roadblock itself, as you call it.

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


reply via email to

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