PATCHES - Countdown to September 19
Here is the current countdown report. The next countdown will start on September 19th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1621 doc: Remove flageolet size tweak from snippet - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1621 !1619 Prepare Changes document for release - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/1619 !1615 Document \caesura - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1615 !1614 Adjust GregorianTranscription contexts and update docs - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1614 Countdown: !1625 Remove translation-status - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/1625 !1624 Fix ly:position-on-line? - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1624 !1623 Store accidental glyph name in 'glyph-name property - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1623 !1616 Add text marks - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1616 Review: !1628 Web-fr+it: fix links to learning manual in 2.23 download page - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1628 !1627 binaries: Disable win32 Dlls in bdwgc - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/1627 !1626 Revert "LyricEngraver: reduce property access" - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1626 !1622 Slur should not care for last dotted note - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1622 !1510 Better source locations for Scheme errors - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1510 New: No patches in New at this time. Waiting: !1610 RFC: Require Cairo for building - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1610 !1578 New margins by default - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1578 A good weekend to all! Colin
Re: NR: no working links in included PDFs
>> As with the Java part of `pax`, it may be possible to extract >> annotations from PDFs with a C/C++ program. But, it looks like >> `latex-pax` is adding the extracted annotations to the PDF using >> `pax.sty`. The `pax.sty` is for LaTeX, and it looks like it is for >> pdfLaTeX only. It would be quite difficult to get it to work with >> Texinfo on XeTeX/pdfTeX. > > Oh, I don't mean that we should exactly follow the `pax` algorithm. I > only mentioned it because it provides a solution. > > Isn't it possible to add links with the `pdfmark` operator in the same > way as is already done for annotations by `extractpdfmark`? In > Adobe's pdfmark reference manual (`5150.Pdfmark.pdf`) I see a section > 2.1.2 called 'Links', which appears to be exactly what's needed. The PDF output by pdfTeX/XeTeX has no information about the file name or position (page number, x-y coordinates, size, etc.) of the PDFs it includes. It means that even if we extract the link information from the included PDFs, we don't know where to apply it in the positions of the PDF output by pdfTeX/XeTeX. `pax.sty` seems to recognize the positions of the PDFs included by the LaTeX layer and reproduce the links. If something similar to this can be done with Texinfo, link reproduction can be realized. However, I have no idea how to do this in Texinfo.
Re: Fixing regressions and serious issues
On Wed, 2022-09-14 at 22:35 +0200, Jean Abou Samra wrote: > Le 14/09/2022 à 22:16, Jonas Hahnfeld a écrit : > > On Wed, 2022-07-20 at 11:39 +0200, Jonas Hahnfeld via Discussions on > > LilyPond development wrote: > > What do we do about this one? Over the past couple of weeks, I tried > > quite a number of ideas, with no success so far. > > Thanks a lot for working on this even if it didn't succeed so far. > > Just in case for others: Jonas shared some details about what he tried > in https://github.com/ivmai/bdwgc/issues/454#issuecomment-1244375504 I've tried some more and probably developed an understanding of what's happening - I will post on the upstream issue later. For our use case, however, we can "cheat" a bit because we statically link both bdwgc and libguile; https://gitlab.com/lilypond/lilypond/-/merge_requests/1627 should work around the crashes (at least they do for me in Wine). > > Questions: > > a) Do we stick to the plan of branching next week, after the planned > > release of 2.23.13 this weekend? > > b) If we decide to branch and eventually arrive in December without a > > fix, do we block the release? > > > > At the current moment, branching without a "guaranteed" release date > > bears a certain risk that we will end up with something half-finished > > while blocking progress before resuming a new cycle of development > > releases. What do people think? > > b) I would say yes. It would be sad, but for better or worse, our > significant part of our user base is on Windows, as far as I know. > > a) I don't know. > > One thing I can say is that finalizing !1510 (-dcompile-scheme-code) > is going to take me a day or two (not helped by being sick of working > on that problem), and it wouldn't be unreasonable to have it in the > unstable release before branching, as it changes the execution of Scheme > code in some significant respects (compiling is optional, but the new > error handling isn't). So I'd consider it reasonable to delay the release > to next week-end for now, and see what happens for the Windows crashes. It's not fully clear to me what "next" means here, but I really want to do an unstable release this weekend (probably on Sunday) unless there are very good arguments not to. The reason is simply that I don't have much time the weekend of the 24th/25th and no time at all the week after for an eventual branching. For !1510 I'd argue that it's simply too late for this weekend. Jonas signature.asc Description: This is a digitally signed message part
