en't tried it and don't want to (this topic is too emotional for me
> right now), but if anyone is interested in reducing the size of doc PDFs when
> generated with the Cairo backend, this tool could be worth exploring.
See
https://lists.gnu.org/archive/html/lilypond-devel/2023-01/m
(moving to the devel list from the user list)
Le samedi 18 mars 2023 à 05:08 +, Werner LEMBERG a écrit :
> ```
>
> > I can see that the size of the Cairo-generated PDF is around 3 times
> > bigger compared to the same document generated with Ghostscript? Is
> >
On Sun, 2023-01-08 at 12:11 +0100, Han-Wen Nienhuys wrote:
> On Sat, Jan 7, 2023 at 10:16 PM Jonas Hahnfeld 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
On Sat, Jan 7, 2023 at 10:16 PM Jonas Hahnfeld 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.
> >
Le 07/01/2023 à 22:58, Jonas Hahnfeld a écrit :
That's only the EPS file; but for all the rest, is Cairo -> PS ->
ps2pdf -> PDF identical to Cairo -> PDF?
Hm, ok, true, there is one difference: you will not get
a PDF outline for a TOC or PDF metadata.
OpenPGP_signature
Descript
On Sat, Jan 7, 2023 at 11:23 PM Jean Abou Samra wrote:
> All I said in the quote is that it does not take a lot of code in
> LilyPond to support embedding EPS files into PS/EPS output in the
> Cairo backend.
>
Forgive me Jean, I thought you were talking about the Cairo
Le 07/01/2023 à 23:04, Luca Fascione a écrit :
On Sat, Jan 7, 2023 at 10:06 PM Jean Abou Samra
wrote:
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
On Sat, Jan 7, 2023 at 10:06 PM Jean Abou Samra wrote:
> 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
>
Hang on. I don't think
he 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...
>
> I don't see an obvious reason for the PDF output to differ noticeably from
&
Le 07/01/2023 à 22:16, Jonas Hahnfeld a écrit :
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
On Sat, 2023-01-07 at 22:05 +0100, Jean Abou Samra wrote:
> Le 07/01/2023 à 21:53, Jonas Hahnfeld a écrit :
> > 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, re
Le 07/01/2023 à 21:53, Jonas Hahnfeld a écrit :
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
> > radical syntax changes that necessitated converting and 'manually'
> > > verifying the .ly files. Since Cairo vs. Ghostscript doesn't affect
> > > the semantics of .ly files, I think we can continue the 2.x version
> > > number. As a practical example, page layout was i
y, regardless whether it is backward compatible of not.
The introduction of the Cairo backend as the default is such an event.
LilyPond is not a library, we are thus not bound to reflect the DLL
version number in some way. Also, many other software products do the
same, including other GNU projects
On Fri, Jan 6, 2023 at 10:19 AM Jonas Hahnfeld wrote:
>
> On Wed, 2023-01-04 at 12:52 +0100, Han-Wen Nienhuys wrote:
> > Regarding versioning: the 1.x to 2.x transition was motivated by
> > radical syntax changes that necessitated converting and 'manually'
> > verifying th
On Fri, Jan 6, 2023 at 4:34 PM Marnen Laibow-Koser
wrote:
[…]
> BTW, what is the current status of Mac .app builds of LilyPond? I haven’t
> seen any new builds available since the last one that I created, but maybe
> I’m looking in the wrong place.
>
I see there are builds available on the
On Fri, Jan 6, 2023 at 8:23 AM Jean Abou Samra wrote:
> Le 06/01/2023 à 10:13, Jonas Hahnfeld a écrit :
> > On Fri, 2023-01-06 at 08:48 +0100, Jean Abou Samra wrote:
> >> Jonas, is there a possibility to have access to the MacStadium
> >> node, or do you have other advice on testing this on
De : Han-Wen Nienhuys <[1]hanw...@gmail.com>
À : Jean Abou Samra <[2]j...@abou-samra.fr>
CC : Jonas Hahnfeld <[3]hah...@hahnjo.de>, lilypond-devel
<[4]lilypond-devel@gnu.org>
Date : 06/01/2023 18:53 CET
Sujet : Re: Missing items to make Cairo rea
, alpha transparency is not going
> to work.
transparency doesn't work today either in the PS backend, the
stencil-expressions.ly regtest looks different in Cairo and the
classic backend. See commit 103ca4c38061754f612880bcc7c29b4fd5acb8f6.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
a écrit :
>
> > > I don't see any markup commands other than \postscript
> > > and \epsfile that we cannot fully support in Cairo.
> >
> > Any number bigger than zero represents a "breaking change" for me, and
> > it's not the sort of change that
Le 06/01/2023 à 14:41, Thomas Morley a écrit :
Imho, a good point to look at what users do with \postscript is the LSR.
Currently 20 snippets mention 'postscript'. I'm pretty sure most of
them can be modified to use \path etc.
Apart from https://lsr.di.unimi.it/LSR/Item?id=1060
This one is nice,
gt; and \epsfile that we cannot fully support in Cairo.
>
> Any number bigger than zero represents a "breaking change" for me, and
> it's not the sort of change that can be fixed by convert-ly or even
> manually because there is no (general) equivalent.
Imho, a good p
that
we cannot or do not want to support with Cairo.
I don't see any markup commands other than \postscript
and \epsfile that we cannot fully support in Cairo.
Any number bigger than zero represents a "breaking change" for me, and
it's not the sort of change that can be fixed by convert-
o not want to support with Cairo.
>
> I don't see any markup commands other than \postscript
> and \epsfile that we cannot fully support in Cairo.
Any number bigger than zero represents a "breaking change" for me, and
it's not the sort of change that can be fixe
Le 06/01/2023 à 10:13, Jonas Hahnfeld a écrit :
On Fri, 2023-01-06 at 08:48 +0100, Jean Abou Samra wrote:
Jonas, is there a possibility to have access to the MacStadium
node, or do you have other advice on testing this on macOS?
I'd like to check it also works there before potentially starting
Le 06/01/2023 à 10:19, Jonas Hahnfeld a écrit :
Regardless of what has been done in prior versions, it seems to me the
cleanest solution still is to remove a number of markup commands that
we cannot or do not want to support with Cairo.
I don't see any markup commands other than \postscript
nd of the worst case scenario for the inclusion
> of many tiny PDFs and font subsetting.
>
> When building with gs-9.55.0 and extractpdfmark, notation.pdf and
> collated-files.pdf are 6.3MB and 4.9MB. With the Cairo backend
> (admittedly post-processed with gs-10.0.0; will have to re
On Wed, 2023-01-04 at 12:52 +0100, Han-Wen Nienhuys wrote:
> Regarding versioning: the 1.x to 2.x transition was motivated by
> radical syntax changes that necessitated converting and 'manually'
> verifying the .ly files. Since Cairo vs. Ghostscript doesn't affect
> the semantics of
On Fri, 2023-01-06 at 08:48 +0100, Jean Abou Samra wrote:
> Le 06/01/2023 à 03:19, Jean Abou Samra a écrit :
> > Le 04/01/2023 à 15:50, Jonas Hahnfeld a écrit :
> > > On the other hand, librsvg is written in Rust where I have no
> > > experience how practical it actually is to integrate into our
On Thu, 2023-01-05 at 23:55 +0100, Jean Abou Samra wrote:
> Le 05/01/2023 à 23:30, Jonas Hahnfeld a écrit :
> > What I find worrying in this discussion is that proponents of having
> > Cairo sooner than later keep dismissing the size argument, in parts
> > with very
Le 06/01/2023 à 03:19, Jean Abou Samra a écrit :
Le 04/01/2023 à 15:50, Jonas Hahnfeld a écrit :
On the other hand, librsvg is written in Rust where I have no
experience how practical it actually is to integrate into our binaries
on all platforms.
To my surprise, I was able to get librsvg
Le 04/01/2023 à 15:50, Jonas Hahnfeld a écrit :
On the other hand, librsvg is written in Rust where I have no
experience how practical it actually is to integrate into our binaries
on all platforms.
To my surprise, I was able to get librsvg to build in release/binaries/ this
evening, with
Le 05/01/2023 à 23:30, Jonas Hahnfeld a écrit :
What I find worrying in this discussion is that proponents of having
Cairo sooner than later keep dismissing the size argument, in parts
with very strong words, without the willingness to look into it (as far
as I understand; or have there been
On 1/5/2023 4:30 PM, Jonas Hahnfeld wrote:
What I find worrying in this discussion is that proponents of having
Cairo sooner than later keep dismissing the size argument
Concern granted. I do appreciate optimal PDFs.
How much effort should be expended for what level of optimization,
Cairo's
On Thu, Jan 5, 2023 at 2:24 PM Werner LEMBERG wrote:
>
>
> >> The only thing I would like to convince the Cairo people is to add
> >> a mode to produce PDFs with font references instead of embedding –
> >> and subsetting – fonts. My Cairo knowledge is zero; ma
and objective numbers here instead of just
extrapolating - notation.pdf and also collated-files.pdf with all
regression tests are kind of the worst case scenario for the inclusion
of many tiny PDFs and font subsetting.
When building with gs-9.55.0 and extractpdfmark, notation.pdf and
collated-files.pdf a
[ replying on the topic of the new PDF interpreter alone because it
really bothers me that you keep making wrong claims in that regard ]
On Wed, 2023-01-04 at 15:13 +, Werner LEMBERG wrote:
> > With extractpdfmark
> > ===
> >
> > PS backend:
> >
> > 4,8M
Le 05/01/2023 à 16:14, Werner LEMBERG a écrit :
This is apparently a generation thing: I still can remember using
modems that transferred 4kByte/s...
Over here
$ wget
https://gitlab.com/lilypond/lilypond/-/releases/v2.24.0/downloads/lilypond-2.24.0-documentation.tar.xz
[...]
n an issue regarding PDF font embedding/subsetting in
Cairo.
https://gitlab.freedesktop.org/cairo/cairo/-/issues/618
Werner
ery beneficial.
Here is something we will be able to improve eventually thanks to Cairo, by
embedding SVGs instead of PNGs. The current SVG backend is not good enough for
that (slow, doesn’t embed fonts).
>> The only thing I would like to convince the Cairo people is to add
>> a mode to produce PDFs with font references instead of embedding –
>> and subsetting – fonts. My Cairo knowledge is zero; maybe this is
>> already possible?
>
> This makes no sense to m
Le 05/01/2023 à 13:23, Karlin High a écrit :
On Thu, Jan 5, 2023, 6:07 AM Han-Wen Nienhuys wrote:
If we do custom post processing, we might as well postprocess the
final PDF directly to make all snippets point to a single music
font object?
I would like to hear more about what
On Thu, Jan 5, 2023, 6:07 AM Han-Wen Nienhuys wrote:
> If we do custom post processing, we might as well postprocess the final
> PDF directly to make all snippets point to a single music font object?
>
I would like to hear more about what that could look like. There were
numerous mentions of
On Thu, Jan 5, 2023 at 7:16 AM Werner LEMBERG wrote:
> The only thing I would like to convince the Cairo people is to add a
> mode to produce PDFs with font references instead of embedding – and
> subsetting – fonts. My Cairo knowledge is zero; maybe this is already
> possible?
to figure out what need to be ready by then is *now*.
It will take a lot of time to get each of the features we need in Cairo
written, reviewed, merged, released and to wait for that release to be
reasonably current for Linux distros to pick it up.
I strongly disagree that PDFs of the same size
ry
carefully. Hopefully, we are first marking the old backend as
deprecated in the next major release before removing it completely in
the release after next.
The only thing I would like to convince the Cairo people is to add a
mode to produce PDFs with font references instead of embedding – and
subset
the cost of maintaining the PS backend.
Cairo's primary focus is not on PDF features. If I were a Cairo
maintainer vetting a patch to add an option to disable font embedding
because "we have this niche use case for it, and the developers
of the main tool to work with PDFs don't want to suppor
Jean Abou Samra writes:
> Le 04/01/2023 à 22:42, David Kastrup a écrit :
>> There is a difference between a score that is downloaded and copied and
>> transferred thousands of times indefinitely, and a finalized print
>> journal that is sent from a publisher to a printer once.
>
>
>
> I think
Le 04/01/2023 à 22:49, Werner LEMBERG a écrit :
Well, in this case it's the Cairo people we would have to convince.
We could then get rid of Ghostscript completely.
So, to be clear, in your opinion, solving this is a requirement
before we drop the old PS backend? Waiting for a potentially
> And again, it's not like the NR PDF was unusable when it was
> ~35 MB in LilyPond 2.18.
>
> What alternative would you propose?
In the next days I will investigate how to get small PDFs with the new
PDF engine of Ghostscript, reporting problems to the maintainers.
Let's see what this will
n over file sizes in the few megabytes seems a bit
> picky."
>
> <https://lists.gnu.org/archive/html/lilypond-devel/2017-09/msg00131.html>
Well, in this case it's the Cairo people we would have to convince.
We could then get rid of Ghostscript completely.
Werner
Le 04/01/2023 à 22:42, David Kastrup a écrit :
There is a difference between a score that is downloaded and copied and
transferred thousands of times indefinitely, and a finalized print
journal that is sent from a publisher to a printer once.
I think there is a misunderstanding. We are
Jean Abou Samra writes:
> Le 04/01/2023 à 22:22, Werner LEMBERG a écrit :
>> Honestly, a fourfold size increase is not something that I would call
>> 'acceptable'.
>
>
>
> It's a question of absolute values, not relative ones. A fourfold
> increase from an acceptable value to an acceptable value
Le 04/01/2023 à 22:22, Werner LEMBERG a écrit :
Honestly, a fourfold size increase is not something that I would call
'acceptable'.
It's a question of absolute values, not relative ones. A fourfold
increase from an acceptable value to an acceptable value is
acceptable.
Due to browser
On 1/4/2023 3:22 PM, Werner LEMBERG wrote:
Honestly, a fourfold size increase is not something that I would call
'acceptable'.
Upstream might need some convincing.
Ghostscript's Ken Sharp in 2017:
"When we have customers wanting to send us 125GB files I have to say
that a concern over file
instead of about
>> 4500.
>
> OK, this sounds like it will be tough to do in the Cairo
> backend.
Actually, it would be *great* if such a feature could be incorporated
into Cairo itself. I guess LilyPond is not the only application of
this library that would love to include other
Tangential to the ongoing Cairo discussions: does anybody
mind adding a ~Cairo label for Cairo-related issues?
OpenPGP_signature
Description: OpenPGP digital signature
) fonts instead of about
4500.
OK, this sounds like it will be tough to do in the Cairo backend. Given
that the size still looks acceptable (I mean, with browser caching,
you don't actually download doc PDFs often, and it's still more than
twice smaller than before extractpfmark was introduced
e what exactly yields the smaller size of PS backend +
> extractpdfmark or how we could get it in Cairo.
The idea is that you compile all snippets with references to fonts
only but not with actual fonts. This allows Ghostscript to analyze
and squeeze the fonts of all included PDFs globall
On Wed, 2023-01-04 at 15:00 +0100, Jean Abou Samra wrote:
> I was initially scared by Poppler's dependencies, but now that I look at
> its CMakeLists.txt file, it seems that most of them are optional, which
> makes it more palatable. I'm still not sure what you lose if you don't
> compile with
Le 04/01/2023 à 14:32, Jonas Hahnfeld a écrit :
Right: as far as I understand, these are also crucial for our own
documentation build to end up with reasonably sized PDFs. Did you check
what the situation is if we used snippets compiled with Cairo?
Without extractpdfmark
Le 04/01/2023 à 14:29, Jonas Hahnfeld a écrit :
On Wed, 2023-01-04 at 13:39 +0100, Jean Abou Samra wrote:
Le 04/01/2023 à 12:52, Han-Wen Nienhuys a écrit :
PNG images will always be clunky for embedding line art, so it can't
be the recommended solution. What makes most sense for users? Other
On Wed, 2023-01-04 at 14:00 +0100, Jean Abou Samra wrote:
> Le 29/12/2022 à 01:53, Jean Abou Samra a écrit :
> > Hi,
> >
> > I have just opened issues for the missing features of
> > the Cairo backend that I am aware of.
> >
> > https://gitlab.com/li
On Wed, 2023-01-04 at 13:39 +0100, Jean Abou Samra wrote:
> Le 04/01/2023 à 12:52, Han-Wen Nienhuys a écrit :
> > PNG images will always be clunky for embedding line art, so it can't
> > be the recommended solution. What makes most sense for users? Other
> > illustration programs also can't
Le 29/12/2022 à 01:53, Jean Abou Samra a écrit :
Hi,
I have just opened issues for the missing features of
the Cairo backend that I am aware of.
https://gitlab.com/lilypond/lilypond/-/issues/6500
https://gitlab.com/lilypond/lilypond/-/issues/6501
https://gitlab.com/lilypond/lilypond/-/issues
Le 04/01/2023 à 12:52, Han-Wen Nienhuys a écrit :
On Thu, Dec 29, 2022 at 1:53 AM Jean Abou Samra wrote:
Hi,
I have just opened issues for the missing features of
the Cairo backend that I am aware of.
https://gitlab.com/lilypond/lilypond/-/issues/6500
https://gitlab.com/lilypond/lilypond
On Thu, Dec 29, 2022 at 1:53 AM Jean Abou Samra wrote:
>
> Hi,
>
> I have just opened issues for the missing features of
> the Cairo backend that I am aware of.
>
> https://gitlab.com/lilypond/lilypond/-/issues/6500
> https://gitlab.com/lilypond/lilypond/-/issues/6
.
In !1787, I am adding a command \image, which can embed PNG files in
addition to EPS files. Unlike the state of the MR when this thread
began, this command now works in all ouput backends: PS, SVG, Cairo.
In the Cairo backend, the implementation lets Cairo read the pixels from
the PNG file
On Sun, Jan 1, 2023 at 11:16 PM Jean Abou Samra wrote:
> Its image operator doesn't have
> support for transparency on some pixels and not others.
>
So you're worried about PS with embedded pixels coming from maybe a PNG not
roundtripping correctly back to PNG when transparency is involved?
Le 01/01/2023 à 12:36, Jean Abou Samra a écrit :
Le 30/12/2022 à 13:08, Jean Abou Samra a écrit :
which means figuring out how to do PNGs via the default PS
backend and GS.
I looked a bit at this.
It's not insurmountable, *but*, alpha transparency is not going
to work. PNG images with an
Le 01/01/2023 à 23:10, Luca Fascione a écrit :
Sorry I'm confused: my imagemagick point was that it seems to
support EPS -> PNG with alpha, see for example
https://legacy.imagemagick.org/discourse-server/viewtopic.php?t=15985
(it seems that if the input EPS is CMYK, one needs to convert to
Sorry I'm confused: my imagemagick point was that it seems to support EPS
-> PNG with alpha, see for example
https://legacy.imagemagick.org/discourse-server/viewtopic.php?t=15985
(it seems that if the input EPS is CMYK, one needs to convert to RGB first,
and then alpha flows through fine, I have
Le 01/01/2023 à 19:30, Luca Fascione a écrit :
What if you use GS to do PS to PDF instead and embed that? Would Cairo
let you?
(For the PDF backend I mean)
Cf. the remark above about Poppler.
(It would work for all output formats.)
Also, how does ImageMagick implement PS to PNG
What if you use GS to do PS to PDF instead and embed that? Would Cairo let
you?
(For the PDF backend I mean)
Also, how does ImageMagick implement PS to PNG conversion? I wonder if
their approach might inspire us, or whether having an optional dependency
would be an idea to consider (if you have
Le 30/12/2022 à 13:08, Jean Abou Samra a écrit :
which means figuring out how to do PNGs via the default PS
backend and GS.
I looked a bit at this.
It's not insurmountable, *but*, alpha transparency is not going
to work. PNG images with an alpha channel will need to be
converted to plain RGB
colors can give you unique
> identifiers for the map I've described to you, and this makes the
> mechanism safe
Well, it's pretty hacky.
I know but I would not underestimate it. I found the following merge
request, where I see your participation:
https://gitlab.freedesktop.org
; identifiers for the map I've described to you, and this makes the
> > mechanism safe
>
>
> Well, it's pretty hacky.
>
>
I know but I would not underestimate it. I found the following merge
request, where I see your participation:
https://gitlab.freedesktop.org/cairo/cairo/-/merge_
Le 31/12/2022 à 01:39, Jean Abou Samra a écrit :
I think we'd better figure out how to patch Cairo to support this.
(To clarify: I mean "write a patch to submit upstream", not "apply a
patch in the release infrastructure").
OpenPGP_signature
Description: OpenPGP digital signature
.
I think we'd better figure out how to patch Cairo to support this. The
source of the SVG backend is here:
https://gitlab.freedesktop.org/cairo/cairo/-/blob/master/src/cairo-svg-surface.c
I don't think it's hard to add a function for inserting output
attributes to this. It just takes time
Yeah, I also thought about overlying multiple surfaces.
But don't exclude my tip: after all, the colors can give you unique
identifiers for the map I've described to you, and this makes the mechanism
safe
On Sat, Dec 31, 2022 at 1:23 AM Jean Abou Samra wrote:
> Le 31/12/2022 à 01:13, Paolo
Le 31/12/2022 à 01:13, Paolo Prete a écrit :
I'll examine it, thanks.
Meanwhile, I don't know if it is the right case, but it comes to my
mind a hack, which I applied on some similar code:
Before the SVG bytestream is emitted by the write_func, I would set a
temporary, special and different
googled a bit but could not find
> > anything useful for it.
>
>
> Fortunately, my deleted branch for this was still around in my Git
> repository. I ressuscitated it and uploaded it to my fork, so you should
> be able to check it out with
>
> git fetch "g...@gitlab.c
. I ressuscitated it and uploaded it to my fork, so you should
be able to check it out with
git fetch "g...@gitlab.com:jeanas/lilypond.git" cairo-output-attributes
git checkout -b cairo-output-attributes FETCH_HEAD
You can see that the tags are properly output, but before all
> > Hello,
> >
> > I'm probably saying something unfeasible and a dirty mix; nevertheless
> > I wonder: could there be a way to use the cairo backend as a base,
> > along with SVG backend snippets limited to the grobs for which the
> > output-attributes proper
Le 30/12/2022 à 18:12, Paolo Prete a écrit :
Hello,
I'm probably saying something unfeasible and a dirty mix; nevertheless
I wonder: could there be a way to use the cairo backend as a base,
along with SVG backend snippets limited to the grobs for which the
output-attributes property has
On Fri, Dec 30, 2022 at 1:55 PM Jonas Hahnfeld via Discussions on LilyPond
development wrote:
>
> Ok, this is SVG which we can probably agree that the backend is in a
> bad state. At some point, there was a discussion on making Cairo the
> default for producing SVGs but IIRC
A logo will occupy a small fraction of the page. Do you really need
to have it in such high resolution that the file size becomes a
problem?
In practice, probably. (Although there are also things like
page-sized watermarks.)
Given "but" below, did you miss a "not" in this sentence?
Yes,
Le 30/12/2022 à 17:39, Lukas-Fabian Moser a écrit :
Am 30.12.22 um 17:34 schrieb Jean Abou Samra:
Le 30/12/2022 à 17:20, Lukas-Fabian Moser a écrit :
I agree with Jonas that it would be a considerable loss not to be
able to import vector graphics. I don't concur with Jean's argument
that one
Le 30/12/2022 à 17:41, David Kastrup a écrit :
So? ps2pdf exists. It's not like it isn't already part of our toolkit,
so I don't see the problem with using it for creating a vector format.
pdftocairo can create an SVG from that, for example.
Read the question again. It was about outputting
Jean Abou Samra writes:
> Le 30/12/2022 à 16:59, Karlin High a écrit :
>> What are the chances of having a conversion tool that produces
>> LilyPond markup commands for the vectors in formats such as EPS?
>> Perhaps as an eps2ly or something.
>
>
> Zero. PostScript is a full-fledged programming
would be that with Cairo etc.,
it might be more natural/easy to import vector graphics in SVG format
than in EPS?
Yes, I think. Basically, we could support embedding PDFs via Poppler,
or SVGs via librsvg.
It would be nice to have both, but I really think at least one of them
should work before
be including a publisher's logo, for
instance.
A logo will occupy a small fraction of the page. Do you really need to
have it in such high resolution that the file size becomes a problem?
That being said: My uneducated guess would be that with Cairo etc., it
might be more natural/easy to import
On Fri, Dec 30, 2022 at 10:20 AM Lukas-Fabian Moser wrote:
> That being said: My uneducated guess would be that with Cairo etc., it
> might be more natural/easy to import vector graphics in SVG format than
> in EPS?
And apparently tools such as Inkscape offer EPS to SVG conversion
Le 30/12/2022 à 16:59, Karlin High a écrit :
What are the chances of having a conversion tool that produces
LilyPond markup commands for the vectors in formats such as EPS?
Perhaps as an eps2ly or something.
Zero. PostScript is a full-fledged programming language. See the
size of
be including a publisher's logo, for instance.
That being said: My uneducated guess would be that with Cairo etc., it
might be more natural/easy to import vector graphics in SVG format than
in EPS?
Lukas
On Fri, Dec 30, 2022 at 6:55 AM Jonas Hahnfeld via Discussions on
LilyPond development wrote:
>
> On Fri, 2022-12-30 at 13:08 +0100, Jean Abou Samra wrote:
> > As I said, I don't see obvious use cases for \epsfile where you
> > really need vector graphics. LilyPond provides markup commands
> >
On Fri, 2022-12-30 at 13:08 +0100, Jean Abou Samra wrote:
> > 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).
&g
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).
\postscript can be deprecated on other grounds, but we cannot
really deprecate \epsfile
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
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
1 - 100 of 231 matches
Mail list logo
