In T257093#12195665, @Cparle wrote:

I don't think those pngs are in fact useless. I might have the sequencing wrong here, but this is how it looks to me ...

After more investigating, something is closing the <p> before processing the encountered <score> element, and starting a new <p> immediately afterward, so displaying the Lilypond using a <div> or <span> makes no difference. Not sure if this can be addressed in the Score extension, is this happening elsewhere?

In the extension docs we say something like "SVG rendering requires LilyPond >= 2.24 compiled with libcairo (default since LilyPond >= 2.26)" therefore setting $wgScoreUseSvg without libcairo LilyPond is pretty much an administrator configuration RTFM error 😄 of course it was unhelpful that LilyPond 2.24 was initially compiled without libcairo support in Debian, but that was out of our hands.

From the discussion on Help_talk:Score it seems this is resolved by updating old LilyPond syntax.

This patch adds an inline attribute to the <score> element, which wraps the Score image in a <span> element instead of a <div>. For now the sound` attribute is ignored when music is displayed inline.

FYI: SVG Score/LilyPond output is now enabled on WikiSource, e.g. fr:Méthode de Serpent and en:Translation:Méthode_de_serpent.

I've added a patch but it's not ready to merge yet - it needs documentation and a couple of tests, to come (at Wikimania; battery at 5 percent!)

Confirmed with upgrade to LilyPond 2.24 (see Special:Version, 特別:バージョン情報) that this now renders lyrics correctly on both examples, see supplied page oldid: 利用者:Bcxfu75k/score20210926

Seems silly to add another translation string for differentiating a "file not found" variant for the fopen error, which is likely going to be caught earlier, and LilyPond 2.24 doesn't use this script for PNG generation any more anyway.

Noting here that Score with SVG output enabled requires LilyPond 2.24+ which renders PNG directly (in addition to SVG files). the extractPostScriptPageSize.php script (and Ghostscript and ImageMagick) are only required for PNG-only output, using old versions of LilyPond < 2.24

I've updated the page Gitarre: Aufbau der CAGED-Skalenformen on German WikiBooks with the suggested LilyPond syntax update as per @mb above; looks good to me. @Mjchael if I've missed something and this is still incorrect somehow please revert my change and let me know here.

Hi @Lucas_Werkmeister_WMDE - I'm having trouble reproducing this (and I'm not sure why you'd want display_errors=1 like it's 1999 😄). What version or commit of the Score extension are you using?

It's worth noting that while WikiSource has the updated 2.24.4 version of LilyPond (see e.g. Spécial:Version on French WikiSource), the Score extension is not yet configured to output SVG files, so it is still displaying PNG images (see e.g. Méthode de Serpent). This patch might not be needed if the HTML was rendering SVGs instead of PNGs, per the HTML standard usage of the srcset attribute.

This patch preserves current CSS behaviour for PNG output, and uses the dark mode support class when SVG output is enabled.

Is anyone else here on-site in Paris next week? Perhaps we could convene an impromptu Score-LilyPond hackathon or birds-of-a-feather if so.

Re-reading the task description - I'm not sure there's really any decent solution to "embed the SVG from LilyPond in the HTML in such a way that it somehow recreates its text elements when we mince the HTML through a tool to produce a PDF"

It's LilyPond not Score that renders the text elements as glyphs in SVG, to guarantee exact output of the music fonts involved, and in the exact rendering layout, since that's the entire point of LilyPond. I can only offer some suggestions:

1. I don't know enough about the SVG spec to know if it supports attaching searchable-but-hidden (accessibility?) text or character attributes to the glyph paths, but it would be cool if that were possible. Unfortunately I'm not enough of a C or Scheme hacker to be able to write a patch for LilyPond if that is what is needed.
2. Is there an approach where we could (for example) get Score to parse the LilyPond file for text elements, and then smoosh all the words into an alt or data attribute on the <img> tag, or an associated hidden <span>, so it is still available in document search?
3. I'm not sure if this is right, but maybe we could abuse SVG attributes (see docs here) to include the text in the right place?

These two screenshots of part of the discussion on Wikipedia show the result of removing the CSS background rule at .mw-ext-score img and adding skin-invert to the containing div, before and after:

The SVG generated by LilyPond does not have a background. The Score extension wraps the SVG <img> tag in a div with class="mw-ext-score noresize" which is styled to have a white background. All we need to do is remove the white background CSS, and add skin-invert to the div classes, or otherwise tweak the CSS for mw-ext-score to invert the SVG colours. This is well supported by all major browsers, https://caniuse.com/?search=svg

I love it when a plan comes together! Thanks so much everyone!!!!! 🎵

So now that T385404 is done, we can hopefully now enable $wgScoreUseSvg = true and bask in our new SVG niceness? Or do we need to go through all the cached .ly files, and generate .svg results wherever there are currently .png files being used?

👏🍾🏖 !

Hilariously, the new stable 2.26.0 was released in April, but let's not allow that to distract us from the goal! The 2.24 series satisfies T49578 just fine for now.

We're so close! The LilyPond maintainer stated in T49578 that libcairo is enabled in the 2.24.4 in bookworm-backports, it would be easy to install that version and try it and see; it worked when I tried it some months ago, but I'm not currently near a terminal to confirm, sorry.

PLEASE NOTE: enabling $wgScoreUseSvg = true without libcairo support in LilyPond will cause a rendering error similar to the one reported in T428484

How about this quarter?

Hopefully it doesn't take another 13 years.

I'd just like to add that a year and a half later, using the ImageMagick 7.1.1-43 implementation in Debian Trixie, encoding AVIF is much much faster (but HEIF encoding is still slow). Using the same typical large photograph as last time (extracted PNG from a Canon CR3 raw file):

Thank you - improving PDF output on T181322 also depends on this.

In T385344#10885471, @Jdlrobson-WMF wrote:

I believe this could be handled by a transform.
https://www.mediawiki.org/wiki/Extension:Chart/Transforms

I want to test adding one woff2 file to the static resources of the Wikisource extension, which adds it to the static resources pipeline for deployment, and takes care of not having to add it to ULS, or pollute all of the other sister projects with a font that isn't needed outside this particular specialist usage on Wikisource. Petit Formal Script is open source with a SIL license, so we don't have to source it from Google or any other random CDN. The font designer Pablo Impallari has published all of them on GitHub. Except, of course, for one font. Can you guess which one? Correct! Petit Formal Script. So I've emailed him to see what the story is. In the meantime I am testing with a woff2 conversion of the TTF file supplied in the Google download zip. For now I am also not bothering with other webfont formats since woff2 is now supported everywhere.
Update: source for Petit Formal Script is at github.com/librefonts/petitformalscript

No further action required, this behaviour is in Lilypond not the Score extension, has a well known workaround as explained by @Beeswaxcandle, and is fixed anyway in Lilypond 2.24 which will hopefully be deployed soon via T385404.

No worries, and thanks again 🙂

Well 2.24 is the current stable releases, and 2.25 is the dev stream. I'm not sure if it's a good idea to use 2.25 until there's at least an RC, or a 2.26 stable release? Sorry, I'm not familiar enough with what the 2.25 new features are, or breaking changes (if any).

Thank you, done: T385404

Is anyone actually paying any attention at all to this bug, or what?

I have spare evenings here and there, I'd be happy to muck in if there's some code I can push around on Gerrit?

So, to solve this for Wikisource instances where use of "cursive" font family is occasionally required, we should add the Petit Formal Script woff2 to the default theme payload, or something?

Right. So since it can be solved in the same way, why has it taken seven years to not add a woff2 file in ULS, is it because the list of fonts provided can't be configured per wiki instance (e.g. include it in Wikisource config, but not others)?

If it's not a silly question, could this be solved in the same manner as the font used for the Wikisource Blackletter template?

I also wonder if we're trying to do much. It's already evident we don't have enough engineering resource to move some of these tickets. If the goal is to serve SVG files to be rendered in the client, then we should probably stick to SVG 1 and if there are weird text issues, then it is incumbent on the uploader to fix - use a common font, convert text to shapes, etc. I'm just an punter not an employee, so maybe I'm wrong, but it seems to me that the overall scope is ultimately to provide vector diagrams to illustrate an encyplopædia. Maybe we don't need to get too fancy :) It sure would be nice to have SVG music snippets T49578 for example, some time this decade.

In T49578#9915561, @Skierpage wrote:

The choices seem to be:

• Create a Debian 12 (Bookworm) shellbox to run the Debian Lilypond 2.24 package modified with cairo support.
• Backport the Debian Lilypond 2.24 with cairo support to Buster. (I tried building this in a Debian Buster container and ran into a debhelper-compat issue before even getting to the guile problems @Legoktm encountered)
• "The last resort" discussed above: run the Lilypond 2.24.3 generic Linux download from upstream in current shellbox. It worked for me in my Debian Buster container without requiring any install steps or moving files around, but I wasn't using shellbox.

In T40010#9653241, @Tercer wrote:

In a recent discussion in WikiProject Mathematics yet another rendering bug was encountered. Several users expressed the sentiment that SVG support in MediaWiki will never get fixed, and it is better to give up on them altogether and revert to PNGs. This is specially frustrating because the browsers can render the SVG correctly, but MediaWiki insists on passing it through librsvg and serving the resulting garbage instead.

Hi, nothing's happened for a week now? https://quarry.wmcloud.org/query/84387

I am now down a rabbit hole updating someone's BRISQUE, PIQE and NIQE code. It mostly now seems to work, but I don't have an NVidia card to test the BRISQUE code on.

In T257652#9993075, @Trougnouf wrote:

WebP is 8-bit only, right? (The reason I need a modern codec like AVIF/HEIC/JPEG XL is higher color bit depth.)

That is very cool :) My only nit-pick might be that starting with a JPEG source image might bias or throw off the lossy compression, since it will already have minor block and ring artifacts (especially if you're measuring SSIM or PSNR). Might be better to find an uncompressed TIFF or RAW image. Also, it might be fun to compare HDR images with higher bits (10 or 12 per element, e.g. RAW) which is where the newer WebP and AVIF codecs do a better job; and I'd like to dig into things like PIQE or BRISQUE measurements if I get time (unlikely!) since SSIM is a bit blunt.

Apologies - for what it's worth, using an arbitrarily chosen but reasonable quality of 80% for both conversions:

$ file IMG_0652.png
IMG_0652.png: PNG image data, 6984 x 4660, 8-bit/color RGB, non-interlaced
$ time convert -quality 80 IMG_0652.png IMG_0652.avif
real    0m30.996s
user    1m49.326s
sys     0m3.958s
$ time convert -quality 80 IMG_0652.png IMG_0652.jpeg
real    0m0.858s
user    0m0.721s
sys     0m0.136s
$ ls -l
-rw-rw-r-- 1 --- --- 1.1M Jul 17 16:19 IMG_0652.avif
-rw-rw-r-- 1 --- --- 2.4M Jul 17 16:19 IMG_0652.jpeg
-rw-rw-r-- 1 --- ---  41M Aug 24  2023 IMG_0652.png

I'm not sure that "80%" means the same thing in the different codecs, however.

Hi, strangely, some of my MIDI uploads have not been transcoded (Quarry) e.g. in my list of Commons uploads, the first six are fine, but File:6-Z46B_set_class_on_C.mid and on are still not, after 3 days?

Hi, apologies that I don't know how to help, and not sure if it's the same problem; the manual intervention here worked for files I uploaded to Commons on Monday (e.g. File:3-5B set class on C.mid), but files I uploaded yesterday are still waiting, e.g. File:4-3 set class on C.mid. I made a quarry query for these.

In T49578#8708363, @Legoktm wrote:

Our standard practice is to prefer using Debian packages when possible

@Legoktm hi - currently this is not possible due to the Debian maintainer leaving out libcairo support for some (undocumented as far as I can tell) reason.

As predicted, utter radio silence from the Debian maintainer of the 2.24 Lilypond package, so what do we do now? Make some noise on the Debian bug so the next version of Debian due in a couple of years might have libcairo built-in? Or can we please just get on with it, and use the generic binary from upstream Lilypond, which works fine on my Bookworm test instance? I'm not in a position to "deploy" any of this anywhere. Can someone help? This bug is eleven years old.

... have I gone mad, or have the Debian packages of lilypond 2.24 left out libcairo support? Is this some sort of torture?
Update: I have submitted a Debian bug regarding missing libcairo support in the lilypond 2.24 package.

Should we close this ticket, given we now have wgSVGNativeRendering and related settings merged to master on T208578?

Using the ImageMagick 6.9.11 implementation of encoding AVIF and HEIF (libavif 0.9.3, libheif 1.12.0) is still painfully slow, using a typical large photograph (extracted PNG from a Canon CR3 raw file):

$ file IMG_0652.png
IMG_0652.png: PNG image data, 6984 x 4660, 8-bit/color RGB, non-interlaced
$ time convert IMG_0652.png IMG_0652.avif
real    0m10.608s
user    0m29.370s
sys     0m2.031s
$ time convert IMG_0652.png IMG_0652.heif
real    0m17.438s
user    0m17.694s
sys     0m0.148s
$ time convert IMG_0652.png IMG_0652.jpg
real    0m0.756s
user    0m0.648s
sys     0m0.092s

I agree with @Trougnouf that this issue (use AVIF for thumbnails) shouldn't block progress on being able to upload AVIF files.

@Legoktm @TheDJ - is this likely to happen soon? I'm not sure I can help further other than annoy you by pinging... :-/

Lilypond packages are now built with 2.24 in bookworm and trixie (and sid).

Given the patch on T208578, should we adjust Score's behaviour around serving SVG? So, rather than use srcset (see T134455) to provide SVG with a PNG fallback, we look for the new $wgSVGNativeRendering setting and just serve SVG directly. We'll still need Lilypond to generate PNG, but it is only served for older versions of Mediawiki (using the current srcset behaviour) or where the SVG generated by Lilypond exceeds the new $wgSVGNativeRenderingSizeLimit setting. Another possibility (useful for older versions of Mediawiki) is to detect the presence of the NativeSVGHandler extension and serve SVG directly if enabled. Thoughts?

Fair enough. there seems to be promising recent activity on 1026200 anyway

Surely we can just pull the official upstream binary tarball from GitLab, extract it somewhere, and point LocalSettings.php variables at it? No Debian package required.

You'll have to forgive my total lack of knowledge of Wikipedia internals and toolchains since I'm not an employee, I'm just a Wikipedia editor with an overinflated sense of enthusiasm and can code in PHP, so I offered to help with the Score extension. I'm not sure I'd be much use for most of that?

As it turned out, GIMP added AVIF support to version 2.10.22 in September 2020, see #2668.

I've already done that. How do we get the new version of the Score extension deployed out to Wikipedia so we can enjoy our new SVG output?

This ticket was opened in 2005, nearly twenty years ago. I would like to see T49578 Score SVG output on Wikipedia, hopefully some time before the sun runs out of hydrogen and engulfs our planet in a fiery apocalypse. What can I do to help?

I can reproduce this now... sorry about the noise :)

That's all well and good, in that case, how are we to advance T5593 which has been languishing since 2005? That's nearly twenty years. I would like to see SVG Score output hopefully some time before the sun runs out of hydrogen and engulfs our planet in a fiery apocalypse.

@TheDJ - regarding Score SVG output, T49578 has been merged, but is still open. Not sure what happens now, but this would be a good test for using img srcset, since that's what we implemented in Score.

This was merged over 2 months ago, what happens next? I'd like to get T134455 advanced so we can get on with SVG Score output somehow.

+1 for @Glrx's answer to close; if you want exact PDF-like font rendering, convert it to curves and use parallel hidden text elements if you need the SVG to be indexed in full-text search data. If you want exact rendering and have big walls of text, perhaps you want a PDF file...?

Shall we close this, then?

Don't ask me, I didn't write these PoCs, and I don't know much about Lilypond's use of Scheme, or anything at all about Scheme. I'm just trying to get some PHP code to render music using LilyPond. So does that mean I should see spurious id output in logging?