Re: no links in PDFs with gs 9.56.1
Am Sa., 30. Juli 2022 um 12:39 Uhr schrieb Werner LEMBERG : > > > >> In case you are forced to use 9.56.1, add `-dNEWPDF=false` to the > >> gs command line options (in file `Documentation/GNUmakefile`) to > >> make gs use the old PDF engine, which produces good results. > > > > So this is about the post-processing step with extractpdfmark + gs, > > right? > > Yes – I always build the documentation with 'extractpdfmark'; maybe > this gs bug doesn't show up otherwise. > > > Werner If I build the docs I use 'extractpdfmark' as well. In the light of this thread I tried ghostscript self-compiled from their most recent master, giving me 9.57.0. Though, compile time is bad: Always doing time make LANGS='en' doc -j5 CPU_COUNT=5 I get for Uncompiled guile real111m56,272s user190m51,445s sys17m51,542s Compiled guile real98m43,545s user162m33,293s sys15m33,015s This is insane. Tbh, I did not check whether pdf links are present but directly downgraded to gs 9.55.0, with below timing values: Uncompiled guile real50m20,112s user129m33,921s sys17m42,618s Compiled guile real44m32,826s user116m10,453s sys17m1,201s Better, but still bad, regarding the fact I compiled only the english docs. Yes, I have a weak laptop... No idea, if we can do anything to improve the situation. Anyway, I thought I share my observations. Cheers, Harm
Re: no links in PDFs with gs 9.56.1
Le 07/08/2022 à 11:43, Thomas Morley a écrit : Am Sa., 30. Juli 2022 um 12:39 Uhr schrieb Werner LEMBERG : In case you are forced to use 9.56.1, add `-dNEWPDF=false` to the gs command line options (in file `Documentation/GNUmakefile`) to make gs use the old PDF engine, which produces good results. So this is about the post-processing step with extractpdfmark + gs, right? Yes – I always build the documentation with 'extractpdfmark'; maybe this gs bug doesn't show up otherwise. Werner If I build the docs I use 'extractpdfmark' as well. In the light of this thread I tried ghostscript self-compiled from their most recent master, giving me 9.57.0. Though, compile time is bad: Always doing time make LANGS='en' doc -j5 CPU_COUNT=5 I get for Uncompiled guile real111m56,272s user190m51,445s sys17m51,542s Compiled guile real98m43,545s user162m33,293s sys15m33,015s This is insane. Tbh, I did not check whether pdf links are present but directly downgraded to gs 9.55.0, with below timing values: Uncompiled guile real50m20,112s user129m33,921s sys17m42,618s Compiled guile real44m32,826s user116m10,453s sys17m1,201s Better, but still bad, regarding the fact I compiled only the english docs. Yes, I have a weak laptop... No idea, if we can do anything to improve the situation. Regardless of the issue (which is problematic indeed), I would advise building without extractpdfmark (../configure --without-extractpdfmark). Its only advantage is to reduce the size of PDFs. If you just want to check the doc section you wrote, that's not really needed. Best, Jean Anyway, I thought I share my observations.
Re: no links in PDFs with gs 9.56.1
> If I build the docs I use 'extractpdfmark' as well. In the light of > this thread I tried ghostscript self-compiled from their most recent > master, giving me 9.57.0. [...] > > [compilation time] is insane. I also noticed a slower documentation build with ghostscript's new PDF engine, but not as extreme. Please file a GS bug report. There is already https://bugs.ghostscript.com/show_bug.cgi?id=705534 but the reporter wasn't able to provide something useful, so I guess a new issue is best. Werner
Re: generate-documentation failure on context mods
On Jul 12, 2022, at 09:29, David Kastrup wrote:
>
>> Apparently, document-mod-list in document-context-mods.scm reads
>> an unbound variable.
>
> Well, yes.
>
> ((assign)
> (string-append
>(format #f "@item Sets translator property @code{~a} to" name-sym)
>(if (pretty-printable? value)
>(format #f ":~a\n" (scm->texi (car args)))
>(format #f " ~a.\n" (scm->texi (car args))
>
> Here (pretty-printable? value) should likely be (pretty-printable? (car
> args)) .
Thank you. I included this change in
https://gitlab.com/lilypond/lilypond/-/merge_requests/1525 by necessity.
—
Dan
Re: no links in PDFs with gs 9.56.1
Am So., 7. Aug. 2022 um 13:05 Uhr schrieb Werner LEMBERG : > > > > If I build the docs I use 'extractpdfmark' as well. In the light of > > this thread I tried ghostscript self-compiled from their most recent > > master, giving me 9.57.0. [...] > > > > [compilation time] is insane. > > I also noticed a slower documentation build with ghostscript's new PDF > engine, but not as extreme. Please file a GS bug report. There is > already > > https://bugs.ghostscript.com/show_bug.cgi?id=705534 > > but the reporter wasn't able to provide something useful, so I guess a > new issue is best. > > > Werner Well, I don't feel being competent enough to file a bug report there, at least as soon as it comes to 'how exactly do we invoke GS' and/or a (minimal) example being able to reproduce the problem. Sorry, Harm
Draft plan for next stable release
Hi all, back in May, I proposed the idea to have a next stable release before the end of the year and there was generally agreement in the replies: https://lists.gnu.org/archive/html/lilypond-devel/2022-05/msg00099.html The following is a proposal of a possible timeline; I don't expect this to be final and if there are good reasons, I think we can and should change it. I'm trying to take some of my availabilities into account, let's see how it works out... (I don't have time to do a release next weekend, August 13/14) Weekend of August 20/21: LilyPond 2.23.12 after: build freeze; no changes to configure, Makefiles, and release/ scripts allowed unless there are very good reasons Weekend of September 10/11 OR 17/18: LilyPond 2.23.13 (depends on my availabilities, I will have to see) During week of September 19-25: Branching stable/2.24 unless some really big problems are reported [ branch is frozen, no new features or syntax changes; master is open again for development and I will pick fixes into the stable branch; translation work continues on the branch and I'll synchronize back to master during the releases ] Weekend of October 1/2: release candidate LilyPond 2.23.80 Weekend of October 29/30 OR November 5/6: LilyPond 2.23.81 End of November or begin of December: final LilyPond 2.24.0; or, if needed, additional release candidate 2.23.82 (in that case hopefully rather November and then final release around mid December) Comments? Jonas signature.asc Description: This is a digitally signed message part
Re: Draft plan for next stable release
> Le 7 août 2022 à 21:02, Jonas Hahnfeld via Discussions on LilyPond > development a écrit : > > Hi all, > > back in May, I proposed the idea to have a next stable release before > the end of the year and there was generally agreement in the replies: > https://lists.gnu.org/archive/html/lilypond-devel/2022-05/msg00099.html > > The following is a proposal of a possible timeline; I don't expect this > to be final and if there are good reasons, I think we can and should > change it. Agreed. > I'm trying to take some of my availabilities into account, > let's see how it works out... > > > (I don't have time to do a release next weekend, August 13/14) > Weekend of August 20/21: LilyPond 2.23.12 > after: build freeze; no changes to configure, Makefiles, and release/ > scripts allowed unless there are very good reasons > > Weekend of September 10/11 OR 17/18: LilyPond 2.23.13 > (depends on my availabilities, I will have to see) > > During week of September 19-25: Branching stable/2.24 unless some > really big problems are reported > > [ branch is frozen, no new features or syntax changes; master is open > again for development Is open again for development of build stuff, right? Or do you see more freezing happening? > and I will pick fixes into the stable branch; > translation work continues on the branch and I'll synchronize back to > master during the releases ] > > Weekend of October 1/2: release candidate LilyPond 2.23.80 > > Weekend of October 29/30 OR November 5/6: LilyPond 2.23.81 > > End of November or begin of December: final LilyPond 2.24.0; or, if > needed, additional release candidate 2.23.82 (in that case hopefully > rather November and then final release around mid December) > > > Comments? In general, sounds like a good plan to me. Thanks, Jean > > Jonas signature.asc Description: Binary data
