Re: Missing items to make Cairo ready
>> What exactly is your argument for *not* going to version 3.x in >> that case? > > [...] Since this doesn't break backward compatibility, I don't > think we need a major version bump. IMHO, a major version bump should also be used if something changes fundamentally, 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 – a new major version number is kind of an advertisement. At the current maturity level of LilyPond I don't see that we are ever going to change the syntax in such a radical way that it would deserve a major version change. Additionally, my gut feeling says that the minor version number is already uncomfortably high. The alternative is to drop the major number completely, as was done for Emacs, Firefox, or the Linux kernel, to name some well-known projects. However, then the major version number gets uncomfortably high... But maybe it's only me who thinks that :-) Werner
PATCHES - Countdown to January 9th
Here is the current countdown report. The next countdown will begin on January 9th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1799 Slur_score_state: remove programming_error - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1799 !1796 alternativeNumberingStyle #f same as default - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1796 !1795 binaries: Include text fonts with Ghostscript - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/1795 !1794 Make `default-global-scale` a per-session variable - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/1794 !1790 Cairo: support PDF outlines - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1790 Countdown: !1804 open-type-font-scheme: Mark local variables when needed - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1804 !1803 Grand-replace follow-ups - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1803 !1802 Refactor colors - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1802 !1801 Fix doc build with Cairo backend - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1801 !1800 Slur_score_state: find extremal NoteHead w/o Stem - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1800 !1798 Add `ly:note-scale?` predicate for Scale smobs - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/1798 Review: !1806 binaries: Minor fixes - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1806 !1805 Draft: release: Enable Unicode for PCRE - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1805 !1787 Draft: Add PNG image support - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1787 New: No patches in New at this time. Waiting: No patches in Waiting at this time. Cheers, Colin
Re: Missing items to make Cairo ready
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 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 introduced in 2.4, and > > direct to PostScript only became default in 2.6; both changes are much > > more invasive than what we are discussing here. > > 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. We know some are used > in existing libraries and scores, so this constitutes a breaking > change. What exactly is your argument for *not* going to version 3.x in > that case? I don't think there is value in removing markup commands. When we drop the PS backend, folks that use \postscript or \epsfile can do lilypond --ps foo.ly && ps2pdf foo.ps rather than lilypond foo.ly and have their scores mostly work. We don't need to remove support for this, ever. Since this doesn't break backward compatibility, I don't think we need a major version bump. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Missing items to make Cairo ready
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 website that weren’t there when I last checked. I’m looking forward to trying them out! > >> >> Thank you, >> Jean >> >> Best, > -- > Marnen Laibow-Koser > mar...@marnen.org > http://www.marnen.org > > Sent from Gmail Mobile > -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile
Re: Missing items to make Cairo ready
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 macOS? > >> I'd like to check it also works there before potentially starting > >> a discussion on requiring librsvg. > > I'd love to create you an account on the MacStadium node (or any > > developer that is interested), but sadly I have no permission to do so > > and only have an unprivileged account myself. We can try contacting > > Marnen Laibow-Koser and see if he is willing to create one for you. > > > > Hi Marnen, > > We are discussing a possible dependency addition to LilyPond, > and I would like to experiment with building this new dependency > on macOS. Would it be possible for me to have access to the > MacStadium node for this? Of course. I’ll set up an account for you (I’ll send you login info separately as soon as I do so). 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. > > Thank you, > Jean > > Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile
Re: Missing items to make Cairo ready
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 ready On Sun, Jan 1, 2023 at 12:36 PM Jean Abou Samra <[5]j...@abou-samra.fr> wrote: > 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. 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. Yes. However, you don’t get a transparent color without having explicitly asked for it. On the other hand, if we have this discrepancy that the PS backend draws PNG images on a white background while the Cairo backend makes the transparent parts really transparent, we have one more incompatibility that people will need to pay attention to when switching to Cairo. That’s why I prefer making all backends default to a white background. References 1. mailto:hanw...@gmail.com 2. mailto:j...@abou-samra.fr 3. mailto:hah...@hahnjo.de 4. mailto:lilypond-devel@gnu.org 5. mailto:j...@abou-samra.fr
Re: Missing items to make Cairo ready
On Sun, Jan 1, 2023 at 12:36 PM Jean Abou Samra wrote: > > 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. 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
Re: Ghostscript and new PDF interpreter
> Let me add a combination here: Ghostscript 10.01.0 built from > current git (commit 462efa959) yields 28MB with extractpdfmark and > working links (AFAICT), without changes to LilyPond. The reason is > likely > http://git.ghostscript.com/?p=ghostpdl.git;h=073c1adebeef38317ae0e6cb0f6d366ddaadb38a > (the linked bug number is wrong, the correct one is > https://bugs.ghostscript.com/show_bug.cgi?id=705996 ). This is good news, thanks! > Which proves that extractpdfmark works with the new PDF interpreter > (modulo bugs), and the size issue is unrelated (and still unfixed). > QED. Good to know that it is a different problem. I'll soon file a bug report for GS regarding the size issue. Werner
Re: Ghostscript and new PDF interpreter
On Fri, 2023-01-06 at 09:39 +, Werner LEMBERG wrote: > > LilyPond extract GS size > backend pdfmark GS option of NR comments > -- > standard no 9.56.1 -- 44MB ok > > standard yes 9.56.1 -- 6MB many links missing > standard yes 9.56.1 [1] NEWPDF= 8MB ok > false > standard yes 10.1 [2] Preserve 29MB ok > Marked > Content > > cairo no 9.56.1 -- 17MB ok > cairo yes 9.56.1 -- 16MB many links missing > cairo yes 9.56.1 NEWPDF= 21MB ok > false > cairo yes 10.1 Preserve 21MB ok > Marked > Content Let me add a combination here: Ghostscript 10.01.0 built from current git (commit 462efa959) yields 28MB with extractpdfmark and working links (AFAICT), without changes to LilyPond. The reason is likely http://git.ghostscript.com/?p=ghostpdl.git;h=073c1adebeef38317ae0e6cb0f6d366ddaadb38a (the linked bug number is wrong, the correct one is https://bugs.ghostscript.com/show_bug.cgi?id=705996 ). Which proves that extractpdfmark works with the new PDF interpreter (modulo bugs), and the size issue is unrelated (and still unfixed). QED. Jonas signature.asc Description: This is a digitally signed message part
Re: Missing items to make Cairo ready
On Fri, 2023-01-06 at 14:41 +0100, Thomas Morley wrote: > Am Fr., 6. Jan. 2023 um 14:26 Uhr schrieb Jonas Hahnfeld via > Discussions on LilyPond development : > > > > On Fri, 2023-01-06 at 14:21 +0100, Jean Abou Samra wrote: > > > Le 06/01/2023 à 10:19, Jonas Hahnfeld 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 can be fixed by convert-ly or even > > manually because there is no (general) equivalent. > > 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, though. > > Anyway, I'd offer to modify said snippets during the 2.25. circle. > Maybe it helps deprecating \postscript ? Yes, this has been my proposal all along: Deprecate it for one stable release, and then we can remove it with the major version 3.0 along with Cairo becoming the default. signature.asc Description: This is a digitally signed message part
Re: Missing items to make Cairo ready
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, though. Hm, I have to think how easy it is to add proper support for color gradients... Anyway, I'd offer to modify said snippets during the 2.25. circle. Yes, thank you for proposing, that would help a lot! Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Missing items to make Cairo ready
Am Fr., 6. Jan. 2023 um 14:26 Uhr schrieb Jonas Hahnfeld via Discussions on LilyPond development : > > On Fri, 2023-01-06 at 14:21 +0100, Jean Abou Samra wrote: > > Le 06/01/2023 à 10:19, Jonas Hahnfeld 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 can be fixed by convert-ly or even > manually because there is no (general) equivalent. 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, though. Anyway, I'd offer to modify said snippets during the 2.25. circle. Maybe it helps deprecating \postscript ? Only one lsr-file uses \epsfile. Cheers, Harm
Re: Missing items to make Cairo ready
Le 06/01/2023 à 14:26, Jonas Hahnfeld a écrit : On Fri, 2023-01-06 at 14:21 +0100, Jean Abou Samra wrote: 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 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. Oh, I was not trying to comment on whether we should bump the major version (I have no opinion on that), just on which deprecations actually have to be made. The situation for these is that they are only partially supported, they only work for PS/EPS output. I see no point in removing them entirely, we can just deprecate calling them for non-PS/EPS output. I don't understand the desire to keep something half-working... No strong opinion here, but it gives an escape hatch to obtain PDFs with embedded EPSes, by generating PS output and converting to PDF yourself, which may ease the transition for some people. OpenPGP_signature Description: OpenPGP digital signature
Re: Missing items to make Cairo ready
On Fri, 2023-01-06 at 14:21 +0100, Jean Abou Samra wrote: > 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 > 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. > The situation for these is that they are only partially > supported, they only work for PS/EPS output. I see no > point in removing them entirely, we can just deprecate > calling them for non-PS/EPS output. I don't understand the desire to keep something half-working... > However, I think > the time to discuss this is not right now, but at least > when we have taken a decision on if/when we want to > support SVG images via librsvg. Ok. signature.asc Description: This is a digitally signed message part
Re: Missing items to make Cairo ready
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 a discussion on requiring librsvg. I'd love to create you an account on the MacStadium node (or any developer that is interested), but sadly I have no permission to do so and only have an unprivileged account myself. We can try contacting Marnen Laibow-Koser and see if he is willing to create one for you. Hi Marnen, We are discussing a possible dependency addition to LilyPond, and I would like to experiment with building this new dependency on macOS. Would it be possible for me to have access to the MacStadium node for this? Thank you, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Missing items to make Cairo ready
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 and \epsfile that we cannot fully support in Cairo. The situation for these is that they are only partially supported, they only work for PS/EPS output. I see no point in removing them entirely, we can just deprecate calling them for non-PS/EPS output. However, I think the time to discuss this is not right now, but at least when we have taken a decision on if/when we want to support SVG images via librsvg. OpenPGP_signature Description: OpenPGP digital signature
Re: Ghostscript and new PDF interpreter
> [...] I don't see an immediate connection between the new PDF > interpreter and file size increase (this is what "perfectly fine" > was referring to). Too much info is floating around, so here is a table that shows the various possibilities we are currently investigating. * Everything is based on commit 056784fcb9. * All eight compilations were started from scratch using LuaTeX; `notation.pdf` was produced by `make bytecode; make doc`. * To produce Cairo output I used `make doc ... LOCAL_LILYPOND_FLAGS="-dbackend=cairo"`. * For the `-dNEWPDF=false` and `-dPreserveMarkedContent` builds I used the attached patches, which are mutually exclusive. LilyPond extract GSsize backend pdfmark GS optionof NR comments -- standard no 9.56.1 --44MB ok standard yes 9.56.1 -- 6MB many links missing standard yes 9.56.1 [1] NEWPDF=8MB ok false standard yes 10.1 [2] Preserve 29MB ok Marked Content cairo no 9.56.1 --17MB ok cairo yes 9.56.1 --16MB many links missing cairo yes 9.56.1 NEWPDF= 21MB ok false cairo yes 10.1Preserve 21MB ok Marked Content Werner [1] The next GS version (appearing in March 2023) will no longer contain the old PDF engine. [2] This is a self-compiled version 10.0.0 with a very small patch (already in the GS repository) that enables `-dPreserveMarkedContent`. diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile index 3670e82546..c1f994480a 100644 --- a/Documentation/GNUmakefile +++ b/Documentation/GNUmakefile @@ -488,6 +488,7 @@ ifeq ($(USE_EXTRACTPDFMARK),yes) -sDEVICE=pdfwrite \ -dAutoRotatePages=/None \ -dPrinted=false \ + -dNEWPDF=false \ -dColorConversionStrategy=/LeaveColorUnchanged \ -dDownsampleMonoImages=false \ -dDownsampleGrayImages=false \ @@ -794,6 +795,7 @@ $(outdir)/%.png: %.eps mkdir -p $(dir $@) gs -dAutoRotatePages=/None \ -dPrinted=false \ + -dNEWPDF=false \ -dTextAlphaBits=4 \ -dGraphicsAlphaBits=4 \ -q \ @@ -809,6 +811,7 @@ $(outdir)/%.pdf: %.eps mkdir -p $(dir $@) gs -dAutoRotatePages=/None \ -dPrinted=false \ + -dNEWPDF=false \ -q \ -sDEVICE=pdfwrite \ -dNOPAUSE \ diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile index 3670e82546..53d5f15277 100644 --- a/Documentation/GNUmakefile +++ b/Documentation/GNUmakefile @@ -488,6 +488,7 @@ ifeq ($(USE_EXTRACTPDFMARK),yes) -sDEVICE=pdfwrite \ -dAutoRotatePages=/None \ -dPrinted=false \ + -dPreserveMarkedContent=true \ -dColorConversionStrategy=/LeaveColorUnchanged \ -dDownsampleMonoImages=false \ -dDownsampleGrayImages=false \ @@ -792,8 +793,10 @@ $(outdir)/%.jpg: %.jpg $(outdir)/%.png: %.eps $(call ly_progress,Making,$@,< eps) mkdir -p $(dir $@) - gs -dAutoRotatePages=/None \ + $(GHOSTSCRIPT) \ + -dAutoRotatePages=/None \ -dPrinted=false \ + -dPreserveMarkedContent=true \ -dTextAlphaBits=4 \ -dGraphicsAlphaBits=4 \ -q \ @@ -807,8 +810,10 @@ $(outdir)/%.png: %.eps $(outdir)/%.pdf: %.eps $(call ly_progress,Making,$@,< eps) mkdir -p $(dir $@) - gs -dAutoRotatePages=/None \ + $(GHOSTSCRIPT) \ + -dAutoRotatePages=/None \ -dPrinted=false \ + -dPreserveMarkedContent=true \ -q \ -sDEVICE=pdfwrite \ -dNOPAUSE \ diff --git a/config.make.in b/config.make.in index 346df53ebe..39e9844409 100644 --- a/config.make.in +++ b/config.make.in @@ -34,6 +34,7 @@ FONTCONFIG_LIBS = @FONTCONFIG_LIBS@ FONTFORGE = @FONTFORGE@ FONTFORGE_QUIET_OPTION = @FONTFORGE_QUIET_OPTION@ FREETYPE2_LIBS = @FREETYPE2_LIBS@ +GHOSTSCRIPT = @GHOSTSCRIPT@ GLIB_LIBS = @GLIB_LIBS@ @GOBJECT_LIBS@ GS_API = @GS_API@ GS920 = @GS920@
Re: Missing items to make Cairo ready
On Thu, 2023-01-05 at 23:30 +0100, Jonas Hahnfeld via Discussions on LilyPond development wrote: > On Thu, 2023-01-05 at 13:24 +, Werner LEMBERG wrote: > > > > > > IMO, working with a 35mb user manual isn't materially different > > > from working with a 10mb user manual. Both take a while to > > > download. > > > > Indeed, but the manuals as a whole, in all languages, get also > > distributed, and there it *does* make a significant difference IMHO: > > Right now, the PDFs in `lilypond-2.24.0-documentation.tar.xz` (which > > has a size of 170MByte) need 144MByte in total (uncompressed). > > Multiply the latter by four... > > Let's look at some concrete 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 are 6.3MB and 4.9MB. With the Cairo backend > (admittedly post-processed with gs-10.0.0; will have to re-run with the > older gs version tomorrow), this increases to 14MB and 17MB - a factor > 2.2x and 3.5x. > For the totality of the (uncompressed) out-www/offline-root, this means > an increase from 825MB to 898MB; when tar'ing only this directory with > xz, the size grows from 130MB to 179MB. (Please keep in mind that our > documentation tarball contains more than that, and is also built in a > different environment, so numbers may and will vary). Using cairo with gs-9.55.0 for post-processing (and with working links), the sizes increased some more: notation.pdf is now 19M (a factor 3x) and collated-files.pdf is 25M (a factor 5x). The size of the uncompressed out-www/offline-root jumps to 952MB and tar'ed with xz it is now 194MB - almost a factor 1.5x. signature.asc Description: This is a digitally signed message part
Re: Missing items to make Cairo ready
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 .ly files, I think we can continue the 2.x version > number. As a practical example, page layout was introduced in 2.4, and > direct to PostScript only became default in 2.6; both changes are much > more invasive than what we are discussing here. 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. We know some are used in existing libraries and scores, so this constitutes a breaking change. What exactly is your argument for *not* going to version 3.x in that case? signature.asc Description: This is a digitally signed message part
Re: Missing items to make Cairo ready
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 binaries > > > on all platforms. > > > > To my surprise, I was able to get librsvg to build in > > release/binaries/ this evening, with the three dependencies it pulls in > > (libxml, libjpeg and gdk-pixbuf). I'll try cross-compilation next, we'll > > see how far that goes ... > > I have to say this went pretty smoothly. Took some work, but I was > expecting far worse. After a few hours, I got Windows binaries that > run just fine under Wine. > > 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 > a discussion on requiring librsvg. I'd love to create you an account on the MacStadium node (or any developer that is interested), but sadly I have no permission to do so and only have an unprivileged account myself. We can try contacting Marnen Laibow-Koser and see if he is willing to create one for you. signature.asc Description: This is a digitally signed message part
Re: Missing items to make Cairo ready
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 strong words, without the willingness to look into it (as far > > as I understand; or have there been concrete attempts before I raised > > the point only yesterday?). In my humble opinion, this is not a good > > attitude for planning and proposing large-scale changes as we are > > discussing them... > > No, I had not looked into this before yesterday or thought about it, > and I am not ashamed about it, because the exact purpose of this > thread in the first place was to ask what the potential blockers > were, you brought up one, and that is the kind of answer I expected. In my personal opinion, this stage is even less of a place to make statements like "Quite frankly, I think it's not going to happen until the 12th of Never." and "I strongly disagree that PDFs of the same size as today is a requirement [...]". > Again, I am not proposing anything. I'm just trying to figure out > a minimum amount of work that needs to be done before a concrete > proposal for a switch can even meaningfully be made (before the thread > largely derailed on the actual details of this not-yet-made proposal, > which was not really the intent, but anyway). The original post had this: > I ask this because we are at an early point in the 2.26 release > cycle, which could potentially be ideal to get testing for "Cairo by > default" if it were ready, but it isn't yet. "early point in the 2.26 release cycle" is basically now, not several months from now. I'm sorry, but I see no other interpretation than your intent to make a proposal into that direction very, very soon. > I tend to shrug about size issues because I view them as the least > of my worries compared to PDF / SVG features, which everybody agrees > are critical to get Cairo ready for being a default, and I don't have > high hopes of doing anything about them anyway. Can you please stop making such statements? Complex problems aren't solved within one day. Even if it's not obvious now, I am confident that there are enough people around here that somebody will find a solution eventually. If we try, that is, and not just shrug about it. signature.asc Description: This is a digitally signed message part
