Re: Missing items to make Cairo ready

[Han-Wen Nienhuys]

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.

The \postscript command is already a rabbit hole, because

* it offers access to undocumented postscript commands
(staff-line-thickness, draw_round_box, etc.).
* it doesn't work with SVG output.
* it's also a "specialist" command as writing postscript isn't for the
faint of heart.

However removing the rabbit-hole doesn't actually help users that have
already used it in their .ly files.

I am arguing that we should do what is in definition 2  (but I usually
don't call this deprecate)

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen