Re: RFC: require librsvg to implement SVG image support
Le vendredi 20 janvier 2023 à 18:32 +0100, Jean Abou Samra a écrit : > [In case people are wondering why I’m not replying: I want to actually see > what it takes to cross-compile Poppler, this takes time, and I don’t have a > lot of it ATM, hence the delay.] I tried this, and it consumed a lot of my time without much progress. If there is no agreement on librsvg, I will just abandon this topic for now. signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support
[In case people are wondering why I’m not replying: I want to actually see what it takes to cross-compile Poppler, this takes time, and I don’t have a lot of it ATM, hence the delay.]
Re: RFC: require librsvg to implement SVG image support
Sorry for piping up: Personally I don't see any problem with Jean's poll: It clearly was not intended as a way to reach a democratic decision, but as a means of obtaining a data point. (which is surprising and my interpretation is that the question was phrased wrongly: Currently, the only format for the inclusion of vector graphics is EPS. I just tested this with the Debian logo, and conversion to SVG with Imagemagick produces a black-and-white image. Conversion to PDF on the other hand is as easy as "ps2pdf -dEPSCrop" and hugely battle-tested with Ghostscript. Conversion to SVG actually seems to work with Inkscape, but requires the use of a graphical interface (or I haven't found the full batch options yet), and internally seems to use Ghostscript, so it's actually two conversions instead of one. My conclusion is that PDF is the more "logical" successor to the inclusion of EPS.) I think (and I hope that my judgement is not being clouded by my own private preference for SVG) that there's one flaw in your logic: Namely, you seem to assume that the current situation allowing only EPS as import format is good/convenient for most users. For example, in a hypothetical situation where users have resorted to converting their SVGs to EPS in order to being able to import them into LilyPond scores, it would not be surprising that a poll on PDF vs. SVG resulted in a preference for SVG. But of course it's of value in itself to be as backwards-compatible as possible (which would lead to favouring PDF, as has been detailed by you), and since I can't contribute to the technical matters at hand, I'll shut up again. :-) Lukas
Re: RFC: require librsvg to implement SVG image support
On Sun, 2023-01-15 at 14:09 +0100, Jean Abou Samra wrote: > Le 15/01/2023 à 12:24, Jonas Hahnfeld a écrit : > > (which is surprising and my interpretation is that the question was > > phrased wrongly: > > Could you elaborate on how the question should have been > phrased in your opinion? I don't understand this from the > following sentences. I think it was asked too generically, without catering for users that already have EPS files. > I think the easiest route is "ps2pdf -dEPSCrop" then > "pdftocairo -svg" (i.e., GS, then Poppler). Sure, there is always a way. But as I said, PDF is the more "natural" successor. > PDF may be closer to EPS, but EPS is uncommon today, so I > don't think this adds much value. It is what users (have to) use today, and I see EPS and PDF used more often for logos than SVG. signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support
Le 15/01/2023 à 12:24, Jonas Hahnfeld a écrit : (which is surprising and my interpretation is that the question was phrased wrongly: Could you elaborate on how the question should have been phrased in your opinion? I don't understand this from the following sentences. (For what it's worth, it was not a surprise to me, as it confirms my own experience.) Currently, the only format for the inclusion of vector graphics is EPS. I just tested this with the Debian logo, and conversion to SVG with Imagemagick produces a black-and-white image. Conversion to PDF on the other hand is as easy as "ps2pdf -dEPSCrop" and hugely battle-tested with Ghostscript. Conversion to SVG actually seems to work with Inkscape, but requires the use of a graphical interface (or I haven't found the full batch options yet), and internally seems to use Ghostscript, so it's actually two conversions instead of one. My conclusion is that PDF is the more "logical" successor to the inclusion of EPS.) The Inkscape problem looks quite silly, https://gitlab.com/inkscape/inkscape/-/issues/3524 I think the easiest route is "ps2pdf -dEPSCrop" then "pdftocairo -svg" (i.e., GS, then Poppler). PDF may be closer to EPS, but EPS is uncommon today, so I don't think this adds much value. OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
On Sun, 2023-01-15 at 13:40 +0100, Jean Abou Samra wrote: > - Since Poppler's build system is CMake, we have to write a different > class inheriting from Package alongside ConfigurePackage and > MesonPackage, and figure out how CMake needs to be invoked and > with what environment variables. From my point of view, this is > more complex. Maybe, hard to tell without actually trying. In any case, this is a one-time, short-term complexity that needs to be solved; I still don't understand why this is "more burdensome on the long-term", whereas current Rust projects tend to require very recent versions of the language (see below), so this will potentially cause problems on every version update. > > > By the way, I checked the version of CMake in CentOS 7. According > > > to https://pkgs.org/search/?q=cmake, it's 2.8.12, while the minimum > > > required CMake version for building current versions of Poppler > > > (I checked the latest release, Poppler 23.01.0, as well as master) > > > is 3.16.0. Thus, either way, we'll -- unfortunately -- have to accept > > > that some tools needed to run a build need to be installed outside > > > of the distribution. > > That's not true, we can use the version from el7 (which we use for > > something else already, I forgot which package). This offers us CMake > > 3.17.5 from the "official" repos (for some definition of "official"). > > Now, that is interesting. I didn't know about EPEL. According to > https://packages.fedoraproject.org/pkgs/rust/rust/ > EPEL 7 has Rust 1.66, which is enough for librsvg (Rust 1.63+). > So that should work, right? I also saw this, for CentOS 7 probably. However, even the latest Ubuntu 22.04 LTS and 22.10 provide "only" Rust 1.61, the next release 23.04 *may* have Rust 1.63 and that's not even the latest version... signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support
Le 14/01/2023 à 22:09, Jonas Hahnfeld a écrit : On Sat, 2023-01-14 at 18:11 +0100, Jean Abou Samra wrote: I would have to test how difficult it actually is to cross-compile Poppler, but my own assessment is that keeping MinGW cross-compilation of a C++ project working is potentially more burdensome on the long-term than with a Rust one, so to me, both aspects speak in favor of librsvg. I recognize that, having some (but not a lot of) experience with Rust may make me biased. I don't really understand this argument: We are cross-compiling some tens of C++ projects already, whereas adding Rust is a first here. From my point of view, this is certainly the bigger "burden" here, as long as we make CMake behave. Sorry, that was bad wording from my part: change "C++ project" to "CMake-based C++ project". To be more precise: - librsvg's build system is an Autotools wrapper around Cargo, so we don't have to change the way we are invoking it, the Librsvg class just inherits from the already existing ConfigurePackage class. Apart from one setting of RUSTFLAGS to make the compiler find libintl, like we already have to do for the C++ compiler with LDFLAGS, and one setting of RUST_TARGET (I have to investigate if that one is actually needed), it's similar to what already exists. Behind this, Cargo effortelessly cross-compiles all Rust dependencies of librsvg [there are actually quite a few of them, but this is normal in the Rust world because there is a culture of making very small crates]. - Since Poppler's build system is CMake, we have to write a different class inheriting from Package alongside ConfigurePackage and MesonPackage, and figure out how CMake needs to be invoked and with what environment variables. From my point of view, this is more complex. By the way, I checked the version of CMake in CentOS 7. According to https://pkgs.org/search/?q=cmake, it's 2.8.12, while the minimum required CMake version for building current versions of Poppler (I checked the latest release, Poppler 23.01.0, as well as master) is 3.16.0. Thus, either way, we'll -- unfortunately -- have to accept that some tools needed to run a build need to be installed outside of the distribution. That's not true, we can use the version from el7 (which we use for something else already, I forgot which package). This offers us CMake 3.17.5 from the "official" repos (for some definition of "official"). Now, that is interesting. I didn't know about EPEL. According to https://packages.fedoraproject.org/pkgs/rust/rust/ EPEL 7 has Rust 1.66, which is enough for librsvg (Rust 1.63+). So that should work, right? OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
> My conclusion is that PDF is the more "logical" > successor to the inclusion of EPS.) I'm not on the user list anymore so I didn't see the poll. Personally I mostly work with EPS (for at least one publisher that I worked with it was the only acceptable vector format), but I'm glad that we polled users and I think it was the right thing to do. It's better to work backwards from the user experience to the technical decisions than the other way around. If you decide that svg is too much burden/debt/work then that is fine and we should communicate it like that, and not choose PDF because it's easier for us and then tell users it's what they *should* want anyway. > And this is exactly what scares me: I don't think we should go to all > lengths here in order to fulfill a user poll. I agree. But it's still good to know. The more demand there is for something, the more it will be worth a little effort. Re the RFC: my opinion on the inclusion of librsvg is that it's a good idea if users want it. I haven't done cross compilation with rust, but I have had some interaction with the tooling and I found it convenient/easy to use. I don't think it will add a significant burden. I'm not particularly knowledgeable about rust, but I'm happy to help with it. Kevin
Re: RFC: require librsvg to implement SVG image support
On 2023-01-15 3:24 am, Jonas Hahnfeld wrote: My conclusion is that PDF is the more "logical" successor to the inclusion of EPS.) There is a philosophical issue: EPS (and SVG) are intended to be used as embedded vector graphics. PDF is a document format. EPS/SVG are the diagrams and illustrations; PDF is the whole book. That said, there could very well be use cases for embedding one PDF into another, so perhaps I am thinking too narrow here. It then falls to the development team to make this request a reality within the limits of their abilities and time and factoring in any technical roadblocks. And this is exactly what scares me: I don't think we should go to all lengths here in order to fulfill a user poll. No one is (or should be) suggesting "all lengths". I do not want to rathole on this point, as I do not want to take up more of your time than necessary. But perhaps it is worth taking a moment to examine why you believe this work is pushing your limits of comfort. At least, I cannot see how actionable user feedback driving features is anything to be scared of. But I would readily concede that view, if your natural instincts are onto something I am overlooking. Again, I feel like maybe I am making things worse joining this discussion, so I have no problems just sitting back if I am being a disruption. At best, I am a very minor contributor to the LSR, not a developer. I really do value all the hard work you all put into this project and would never want to overstep boundaries and make unreasonable demands. -- Aaron Hill
Re: RFC: require librsvg to implement SVG image support
On Sun, 15 Jan 2023, 12:25 Jonas Hahnfeld via Discussions on LilyPond development, wrote: > PDF is the more "logical" > successor to the inclusion of EPS. > It never occured to me we wouldn't support PDF. I always heard the discussion as "do we actually really need SVG inclusion when emitting PDF?" kinda question L >
Re: RFC: require librsvg to implement SVG image support
On Sun, 2023-01-15 at 00:45 -0800, Aaron Hill wrote: > On 2023-01-14 7:45 am, Jonas Hahnfeld via Discussions on LilyPond > development wrote: > > I strongly believe that we must figure this out *now*, before deciding > > to go that route. Relatedly, I also think it was a mistake to ask the > > users at this stage - they cannot assess the technical difficulties of > > making either solution happen. > > Yes and no. My apologies for posting disagreement here. > > It is not really relevant whether users can or cannot assess technical > difficulties. Some of us who use LilyPond do have software engineering > experience, so we might be well-equipped (albeit perhaps not > well-motivated) to consider technical matters. > > But the important thing is that users *are* able to express what they > need from LilyPond. Jean's post on the list was merely an ask for what > vector format(s) could be useful. (I think SVG "won", if it matters.) (which is surprising and my interpretation is that the question was phrased wrongly: Currently, the only format for the inclusion of vector graphics is EPS. I just tested this with the Debian logo, and conversion to SVG with Imagemagick produces a black-and-white image. Conversion to PDF on the other hand is as easy as "ps2pdf -dEPSCrop" and hugely battle-tested with Ghostscript. Conversion to SVG actually seems to work with Inkscape, but requires the use of a graphical interface (or I haven't found the full batch options yet), and internally seems to use Ghostscript, so it's actually two conversions instead of one. My conclusion is that PDF is the more "logical" successor to the inclusion of EPS.) > It then falls to the development team to make this request a reality > within the limits of their abilities and time and factoring in any > technical roadblocks. And this is exactly what scares me: I don't think we should go to all lengths here in order to fulfill a user poll. Jonas signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support
On 2023-01-14 7:45 am, Jonas Hahnfeld via Discussions on LilyPond development wrote: I strongly believe that we must figure this out *now*, before deciding to go that route. Relatedly, I also think it was a mistake to ask the users at this stage - they cannot assess the technical difficulties of making either solution happen. Yes and no. My apologies for posting disagreement here. It is not really relevant whether users can or cannot assess technical difficulties. Some of us who use LilyPond do have software engineering experience, so we might be well-equipped (albeit perhaps not well-motivated) to consider technical matters. But the important thing is that users *are* able to express what they need from LilyPond. Jean's post on the list was merely an ask for what vector format(s) could be useful. (I think SVG "won", if it matters.) It then falls to the development team to make this request a reality within the limits of their abilities and time and factoring in any technical roadblocks. Sure, if it was not even remotely possible to support, say, SVG as an image format, one could argue it would have been inappropriate to offer it as an option in a poll. You don't ask the customer if they like chocolate or vanilla ice cream if you know full well that you only have strawberry in the kitchen. But both SVG and PDF were superficially plausible formats. Yes, this discussion around Rust and CMake and what not shows that things are perhaps more complicated than one would like; but I would hardly say Jean overstepped any responsibility for the poll. And even more so clearly stated, we are all humans and we all make mistakes. Let's say that SVG is not a possible image format, for whatever reason, yet it was the format that people seemed to want. If we cannot make that a reality, we just ask for forgiveness. A direct "mea culpa" to let folks know that we have hit a wall that cannot be surmounted, and we will have to wait to support the format at a later time if it would ever be possible. -- Aaron Hill
Re: RFC: require librsvg to implement SVG image support
On Sat, 2023-01-14 at 18:11 +0100, Jean Abou Samra wrote: > I would have to test how difficult it actually is to cross-compile > Poppler, but my own assessment is that keeping MinGW cross-compilation > of a C++ project working is potentially more burdensome on the long-term > than with a Rust one, so to me, both aspects speak in favor of librsvg. > I recognize that, having some (but not a lot of) experience with Rust > may make me biased. I don't really understand this argument: We are cross-compiling some tens of C++ projects already, whereas adding Rust is a first here. From my point of view, this is certainly the bigger "burden" here, as long as we make CMake behave. > By the way, I checked the version of CMake in CentOS 7. According > to https://pkgs.org/search/?q=cmake, it's 2.8.12, while the minimum > required CMake version for building current versions of Poppler > (I checked the latest release, Poppler 23.01.0, as well as master) > is 3.16.0. Thus, either way, we'll -- unfortunately -- have to accept > that some tools needed to run a build need to be installed outside > of the distribution. That's not true, we can use the version from el7 (which we use for something else already, I forgot which package). This offers us CMake 3.17.5 from the "official" repos (for some definition of "official"). signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support
Le 14/01/2023 à 16:45, Jonas Hahnfeld a écrit : On Wed, 2023-01-11 at 23:13 +0100, Han-Wen Nienhuys wrote: Regarding rsvg and rust: maybe we could try with an older version of librsvg first? Rust was only introduced in 2.41, so if we go with 2.40, we can postpone the worry about compiling Rust. librsvg 2.41 was released in 2017, the last bugfix release for version 2.40(.21) is from February 2020, while the one before (2.40.20) is from December 2017. Going for an ancient version like this without a plan for upgrading was exactly one of the pain points in the later days of GUB, and I take offense in even discussing to consciously get into that situation again. I strongly believe that we must figure this out *now*, before deciding to go that route. I'm not taking offense, but I agree that we shouldn't lock ourselves into old versions without a long-term plan. Relatedly, I also think it was a mistake to ask the users at this stage - they cannot assess the technical difficulties of making either solution happen. No, they can't -- and I didn't ask them to. Not sure if I was clear enough in my post to -user -- sorry if I wasn't --, but it was absolutely not meant as any sort of "referendum". We make decisions, not users. If technical reasons of maintainability weigh sufficiently for one solution, we should take it. It does help to compare the solutions. It's one factor in the equation (but not the only one). Had everyone wanted PDF, I would have reconsidered this proposal. I would have to test how difficult it actually is to cross-compile Poppler, but my own assessment is that keeping MinGW cross-compilation of a C++ project working is potentially more burdensome on the long-term than with a Rust one, so to me, both aspects speak in favor of librsvg. I recognize that, having some (but not a lot of) experience with Rust may make me biased. By the way, I checked the version of CMake in CentOS 7. According to https://pkgs.org/search/?q=cmake, it's 2.8.12, while the minimum required CMake version for building current versions of Poppler (I checked the latest release, Poppler 23.01.0, as well as master) is 3.16.0. Thus, either way, we'll -- unfortunately -- have to accept that some tools needed to run a build need to be installed outside of the distribution. OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
On Wed, 2023-01-11 at 23:13 +0100, Han-Wen Nienhuys wrote: > Regarding rsvg and rust: maybe we could try with an older version of > librsvg first? Rust was only introduced in 2.41, so if we go with > 2.40, we can postpone the worry about compiling Rust. librsvg 2.41 was released in 2017, the last bugfix release for version 2.40(.21) is from February 2020, while the one before (2.40.20) is from December 2017. Going for an ancient version like this without a plan for upgrading was exactly one of the pain points in the later days of GUB, and I take offense in even discussing to consciously get into that situation again. I strongly believe that we must figure this out *now*, before deciding to go that route. Relatedly, I also think it was a mistake to ask the users at this stage - they cannot assess the technical difficulties of making either solution happen. Jonas signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support
Le 11/01/2023 à 23:13, Han-Wen Nienhuys a écrit : I was initially thinking there might be a way to avoid a full-blown parser/interpreter for PDF. But that would not work in all formats, so it's probably not acceptable. So you're right. For others following the conversation, the poll is at https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00189.html See my previous posts, I posted this link and also the one to the equivalent thread on lilypond-user-fr (which also leans towards SVG). It's currently 3-0 skewed towards SVG. Regarding rsvg and rust: maybe we could try with an older version of librsvg first? Rust was only introduced in 2.41, so if we go with 2.40, we can postpone the worry about compiling Rust. I'm not super fond of this: as I said, Rust induces little difficulty to (cross-)compile. Look at the PoC branch if you're interested, it's straightforward. It's more a question of how the person running the scripts sets up their environment, which we will need to care about sooner or later if we start requiring librsvg. OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
On Tue, Jan 10, 2023 at 11:32 PM Jean Abou Samra wrote: > > Le 10/01/2023 à 23:25, Han-Wen Nienhuys a écrit : > > On Mon, Jan 9, 2023 at 7:45 PM Jonas Hahnfeld wrote: > >> On Sun, 2023-01-08 at 23:18 +0100, Jean Abou Samra wrote: > >>> In order to keep support for vector graphics, even if not > >>> with EPS, we can add support for embedding SVG images. > >> Are we sure that this is actually what the users need? If everybody > >> just cares about including PDF (for logos), I'm not sure if we need to > >> implement support for SVG. > > PDF has much more features than SVG, so it's not obvious that that > > will be easier, and if we want to ingest the PDF graphic for output to > > SVG/PNG/PS, we'll have to interpret the PDF data, basically doing what > > Poppler does. > > > I don't understand how this is different from SVG. I was initially thinking there might be a way to avoid a full-blown parser/interpreter for PDF. But that would not work in all formats, so it's probably not acceptable. So you're right. For others following the conversation, the poll is at https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00189.html It's currently 3-0 skewed towards SVG. Regarding rsvg and rust: maybe we could try with an older version of librsvg first? Rust was only introduced in 2.41, so if we go with 2.40, we can postpone the worry about compiling Rust. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: RFC: require librsvg to implement SVG image support
Le 08/01/2023 à 23:18, Jean Abou Samra a écrit : * If so, how do we manage the transition? Do we make them optional at first, and if so, for how long? Only Werner commented on this aspect so far. Are there other opinions? OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
Le 10/01/2023 à 23:32, Jean Abou Samra a écrit : A thought in passing: whether we take Librsvg or Poppler, we will need libjpeg. This should also enable us to support JPEG in addition to PNG with not too much effort. On further thinking, I think I'm going to submit this separately as a first step. OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
On 2023-01-10 2:51 pm, Jean Abou Samra wrote: Hi Aaron, Thanks for your reply. Le 10/01/2023 à 03:25, Aaron Hill a écrit : I have had some success with converting EPS to SVG (albeit with some manual correction for color spaces) I'm curious about this, can you say more about these corrections? (If we do this, it's important to offer an optimal workflow to convert EPS to SVG, to advise in the release notes.) It was some time ago, so I will need to track down the EPS. At the time, I suspected that the source artwork might have been specifying colors in CMYK whereas the SVG ended up using RGB. But since the colors in question were branding-related, I was somewhat paranoid about matching the official Pantone exactly. I found a few reference resources online that listed the equivalent RGB and fixed up the SVG. I had used inkscape via the command-line to do the conversion, but I cannot recall which version I would have installed back then. It is possible there were color-handling bugs in inkscape itself, and perhaps those have been fixed so this is a non-issue. -- Aaron Hill
Re: RFC: require librsvg to implement SVG image support
Le 10/01/2023 à 23:32, Jean Abou Samra a écrit : (It hasn't appeared on the archives yet, I'll post a link when it does.) https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00189.html Also on -user-fr: https://lists.gnu.org/archive/html/lilypond-user-fr/2023-01/msg00048.html (Google's machine translation does an acceptable job on it) OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
Hi Aaron, Thanks for your reply. Le 10/01/2023 à 03:25, Aaron Hill a écrit : I have had some success with converting EPS to SVG (albeit with some manual correction for color spaces) I'm curious about this, can you say more about these corrections? (If we do this, it's important to offer an optimal workflow to convert EPS to SVG, to advise in the release notes.) OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
Le 10/01/2023 à 23:25, Han-Wen Nienhuys a écrit : On Mon, Jan 9, 2023 at 7:45 PM Jonas Hahnfeld wrote: On Sun, 2023-01-08 at 23:18 +0100, Jean Abou Samra wrote: In order to keep support for vector graphics, even if not with EPS, we can add support for embedding SVG images. Are we sure that this is actually what the users need? If everybody just cares about including PDF (for logos), I'm not sure if we need to implement support for SVG. PDF has much more features than SVG, so it's not obvious that that will be easier, and if we want to ingest the PDF graphic for output to SVG/PNG/PS, we'll have to interpret the PDF data, basically doing what Poppler does. I don't understand how this is different from SVG. Poppler can render to a Cairo context just like Librsvg, see the example here: https://www.cairographics.org/cookbook/renderpdf/ In terms of complexity for us, it's mostly equivalent. I've posted a request for feedback on lilypond-user to have a sense of which of SVG and PDF would be most useful. (It hasn't appeared on the archives yet, I'll post a link when it does.) A thought in passing: whether we take Librsvg or Poppler, we will need libjpeg. This should also enable us to support JPEG in addition to PNG with not too much effort. OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
On Mon, Jan 9, 2023 at 7:45 PM Jonas Hahnfeld wrote: > > On Sun, 2023-01-08 at 23:18 +0100, Jean Abou Samra wrote: > > In order to keep support for vector graphics, even if not > > with EPS, we can add support for embedding SVG images. > > Are we sure that this is actually what the users need? If everybody > just cares about including PDF (for logos), I'm not sure if we need to > implement support for SVG. PDF has much more features than SVG, so it's not obvious that that will be easier, and if we want to ingest the PDF graphic for output to SVG/PNG/PS, we'll have to interpret the PDF data, basically doing what Poppler does. I posted a question on stackoverflow, https://stackoverflow.com/questions/75076381/embedding-pdf-graphics-in-pdf-output-file-programmatically, maybe that will bring us some light. I looked at LuaTeX and it comes with a library for reading PDF (pplib), which looks small and self-contained. However, it may be that they can avoid looking too deeply into the PDF contents, because their output is always PDF too. However, we'd need a Cairo feature to dump PDF data directly into the output stream. > Another question would be about support in the default PS backend: Is > this feasible for SVGs? Would we again export the rendering from Cairo > and then paste into the output PS? Yes, that should not be too hard. cairo_ps_surface_create_for_stream() will write to a in-memory stream. > > This requires the ability to render an SVG to a Cairo > > surface. Cairo doesn't do this itself. It is the job of > > the librsvg library, which is part of the GNOME stack > > (like GLib and Pango which we already require). > > > > There is also PDF, which could be made to work via Poppler. > > However, it is built with CMake, for which the release > > infrastructure does not have support so far. Jonas said > > cross-compilation was difficult with CMake, and I believe > > him. > > Cross-compilation is always difficult, and what I was trying to say is > that the scripts in release/binaries/ currently don't support CMake. > Cross-compilation with CMake is sometimes a pain because IIRC it > doesn't really support the notion if different targets for host and > build, so something like a tools build for execution during the build > is not really possible. I don't know about Poppler, maybe it doesn't > have any such problems. we'd have to look. I was surprised at https://www.linuxfromscratch.org/blfs/view/svn/general/poppler.html ; the required dependencies are modest. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: RFC: require librsvg to implement SVG image support
On Mon, 2023-01-09 at 23:19 +0100, Jean Abou Samra wrote: > Le 09/01/2023 à 20:50, Jonas Hahnfeld a écrit : > > I tried very hard to install as much as possible from the official > > repositories (MetaPost on CentOS7 and Meson being the exceptions), > > which makes the environment very easy to reproduce. I'm not too fond of > > the rustup approach in general... > > Maybe this is a crazy idea, but what would you think of making the > release scripts download and execute rustup in a local directory > (isolated from whatever install the system might have), similar to > how they're downloading dependency tarballs? That would ensure the > compiler version is exactly the one wanted for us while not interfering > with anything on the system or require environment setup. The goal of the scripts was to assume that everything needed to build LilyPond (and its dependencies) is already there, only the runtime dependencies are taken care of. This is why we don't build GCC and other stuff from source (because it was horrible in GUB), and downloading pre-built binary stuff goes even more against this principle. signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support
On 2023-01-09 11:12 am, Jean Abou Samra wrote: I'm not really sure how to get factual data about this (a straw poll on the user list?). In my experience, for things like logos, SVG is more common (there *are* logos in PDF, they're just less common as far as I know, but again this is only my experience). Logos are probably most common on cover pages, but some of the folios in our choir's repository do start the music on the cover. As such, publisher logos and other artwork sometimes appear on that first page along side notation. The last page might also have non-musical graphics. Of course, I have no idea what formats these houses use internally, but the art libraries that I have access to use EPS for the vector format. I suspect that SVG is just too "new" a format for these older resources. (NOTE: One of the libraries I have also provides JPEGs but I find the DPI to be too low for any print use, and even screen use is not great. I wonder if PNG was too novel a format when this library was assembled.) I have had some success with converting EPS to SVG (albeit with some manual correction for color spaces), so I would have no real objection with LilyPond moving towards SVG as its preferred vector-based image format. What I would fight against is any form of rasterization. When helping to prepare bulletins and inserts for my church, it is a real struggle getting our printer to produce high quality output. Pure vector is the only way to have sharp, clear music notation. Even very high DPI raster ends up slightly out of focus. I suspect that somewhere in the software and hardware stacks, raster images are undergoing photographic manipulation/optimization. That is, they expect raster to be a natural real-world image, so it can freely mess about with gamma correction and low-pass filtering. Line artwork and music content does not fit this pattern, so it gets muddled. So, my only comment on the specific libraries and technologies that we end up using is that there must exist a pure vector pipeline from input sources to output documents. It is not burdensome for me to have to migrate my art assets to SVG. -- Aaron Hill
Re: RFC: require librsvg to implement SVG image support
Le 09/01/2023 à 20:50, Jonas Hahnfeld a écrit : I tried very hard to install as much as possible from the official repositories (MetaPost on CentOS7 and Meson being the exceptions), which makes the environment very easy to reproduce. I'm not too fond of the rustup approach in general... Maybe this is a crazy idea, but what would you think of making the release scripts download and execute rustup in a local directory (isolated from whatever install the system might have), similar to how they're downloading dependency tarballs? That would ensure the compiler version is exactly the one wanted for us while not interfering with anything on the system or require environment setup. OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
On Mon, 2023-01-09 at 20:12 +0100, Jean Abou Samra wrote: > Le 09/01/2023 à 19:44, Jonas Hahnfeld a écrit : > > On Sun, 2023-01-08 at 23:18 +0100, Jean Abou Samra wrote: > > > In order to keep support for vector graphics, even if not > > > with EPS, we can add support for embedding SVG images. > > Are we sure that this is actually what the users need? If everybody > > just cares about including PDF (for logos), I'm not sure if we need to > > implement support for SVG. > > I'm not really sure how to get factual data about this (a straw poll > on the user list?). > > In my experience, for things like logos, SVG is more common (there *are* > logos in PDF, they're just less common as far as I know, but again this is > only my experience). My experience is exactly the opposite for professionally designed logos... > > > Rust is actually a pretty big dependency here. How are we going to > > install this for the build? Especially on CentOS 7, I would be > > surprised if it can be installed from the distro repository. Would we > > have to go for the "official" binaries? That's a "meeh" from my side... > > Why "meeh"? In my (limited) experience, it is actually most common > to install Rust via rustup, because many crates pin their compiler > version and some require a nightly compiler, so you can't do with > a single globally installed compiler, while rustup arranges so that > the version of Rust used in each project is the one specified in > Cargo.toml. > > librsvg requires Rust 1.63, released last August, so whatever the > distro version unless very recent, we cannot use the Rust compiler > packaged by the distro. But unlike C++, this is considered normal > (which is IMHO a relief ...) in the Rust world. I tried very hard to install as much as possible from the official repositories (MetaPost on CentOS7 and Meson being the exceptions), which makes the environment very easy to reproduce. I'm not too fond of the rustup approach in general... signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support
Le 09/01/2023 à 20:12, Jean Abou Samra a écrit : while rustup arranges so that the version of Rust used in each project is the one specified in Cargo.toml. Sorry, I misremembered: s/Cargo.toml/rust-toolchain.toml. A pinned Rust version is specified there, Cargo.toml supports a minimum supported Rust version and errors out if it's run with an older compiler. On the other hand, even without a pinned version, you want to be able to upgrade the compiler frequently and possibly use several versions, which rustup can also do via its CLI. OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
Le 09/01/2023 à 19:44, Jonas Hahnfeld a écrit : On Sun, 2023-01-08 at 23:18 +0100, Jean Abou Samra wrote: In order to keep support for vector graphics, even if not with EPS, we can add support for embedding SVG images. Are we sure that this is actually what the users need? If everybody just cares about including PDF (for logos), I'm not sure if we need to implement support for SVG. I'm not really sure how to get factual data about this (a straw poll on the user list?). In my experience, for things like logos, SVG is more common (there *are* logos in PDF, they're just less common as far as I know, but again this is only my experience). Another question would be about support in the default PS backend: Is this feasible for SVGs? Would we again export the rendering from Cairo and then paste into the output PS? Yes, that would be the idea. I don't know another way. Cross-compilation is always difficult, and what I was trying to say is that the scripts in release/binaries/ currently don't support CMake. Cross-compilation with CMake is sometimes a pain because IIRC it doesn't really support the notion if different targets for host and build, so something like a tools build for execution during the build is not really possible. I don't know about Poppler, maybe it doesn't have any such problems. I didn't try thus far because I thought SVG would be better anyway, see above. Rust is actually a pretty big dependency here. How are we going to install this for the build? Especially on CentOS 7, I would be surprised if it can be installed from the distro repository. Would we have to go for the "official" binaries? That's a "meeh" from my side... Why "meeh"? In my (limited) experience, it is actually most common to install Rust via rustup, because many crates pin their compiler version and some require a nightly compiler, so you can't do with a single globally installed compiler, while rustup arranges so that the version of Rust used in each project is the one specified in Cargo.toml. librsvg requires Rust 1.63, released last August, so whatever the distro version unless very recent, we cannot use the Rust compiler packaged by the distro. But unlike C++, this is considered normal (which is IMHO a relief ...) in the Rust world. OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
On Sun, 2023-01-08 at 23:18 +0100, Jean Abou Samra wrote: > In order to keep support for vector graphics, even if not > with EPS, we can add support for embedding SVG images. Are we sure that this is actually what the users need? If everybody just cares about including PDF (for logos), I'm not sure if we need to implement support for SVG. Another question would be about support in the default PS backend: Is this feasible for SVGs? Would we again export the rendering from Cairo and then paste into the output PS? > This requires the ability to render an SVG to a Cairo > surface. Cairo doesn't do this itself. It is the job of > the librsvg library, which is part of the GNOME stack > (like GLib and Pango which we already require). > > There is also PDF, which could be made to work via Poppler. > However, it is built with CMake, for which the release > infrastructure does not have support so far. Jonas said > cross-compilation was difficult with CMake, and I believe > him. Cross-compilation is always difficult, and what I was trying to say is that the scripts in release/binaries/ currently don't support CMake. Cross-compilation with CMake is sometimes a pain because IIRC it doesn't really support the notion if different targets for host and build, so something like a tools build for execution during the build is not really possible. I don't know about Poppler, maybe it doesn't have any such problems. > Therefore, the proposal here is to add librsvg as a dependency > to LilyPond. The transitive dependencies it pulls in are > libxml2, GdkPixbuf, and libjpeg (the latter for GdkPixbuf). > > Build systems are > > - librsvg: Cargo (Rust package manager; cross-compilation > was relatively seamless) + Autotools (for the C API) Rust is actually a pretty big dependency here. How are we going to install this for the build? Especially on CentOS 7, I would be surprised if it can be installed from the distro repository. Would we have to go for the "official" binaries? That's a "meeh" from my side... Jonas signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support,RFC: require librsvg to implement SVG image support
> Therefore, the proposal here is to add librsvg as a dependency to > LilyPond. The transitive dependencies it pulls in are libxml2, > GdkPixbuf, and libjpeg (the latter for GdkPixbuf). Your proposal sounds good to me. > * If so, how do we manage the transition? Do we make them optional > at first, and if so, for how long? IMHO, we could make a hard cut for build requirements in the development series. The only important thing is that we don't rely on the very latest library versions (except where really necessary) to reduce build problems. Werner
