Re: integrating Joram's 'visualindex'
Two weeks ago Dan asked the following: >> Can you force them to face each other? > > I think so, yes, with some TeX trickery. I've now had a closer look. Currently, LilyPond's PDF documentation is created in single-side mode, i.e., the page numbers are always in the upper right corner. It is possible to get a two-sided layout by inserting `@setchapternewpage odd`; this also makes chapters always start on an odd page. This first page of the visual index chapter could be used for some explanations, and the next two pages would be then facing each other, as desired. However, I think it would be still necessary to create the visual index outside of the `lilypond-book` framework; the necessary tight vertical typesetting is rather diametral to splitting the snippet into single staves that are then glued together as boxes with some vertical space inbetween, causing far too large vertical distances. Werner
Re: integrating Joram's 'visualindex'
> Le 3 août 2022 à 11:44, Werner LEMBERG a écrit : > > > Two weeks ago Dan asked the following: > >>> Can you force them to face each other? >> >> I think so, yes, with some TeX trickery. > > I've now had a closer look. Currently, LilyPond's PDF documentation > is created in single-side mode, i.e., the page numbers are always in > the upper right corner. It is possible to get a two-sided layout by > inserting `@setchapternewpage odd`; this also makes chapters always > start on an odd page. This first page of the visual index chapter > could be used for some explanations, and the next two pages would be > then facing each other, as desired. Sorry for jumping in as someone without any expertise in typography, but I can’t help thinking: why create the problem if it doesn’t already exist? :-) > However, I think it would be still necessary to create the visual > index outside of the `lilypond-book` framework; the necessary tight > vertical typesetting is rather diametral to splitting the snippet into > single staves that are then glued together as boxes with some vertical > space inbetween, causing far too large vertical distances. IIRC, it inserts the entire output instead of separate images if you use an explicit \book. > > >Werner >
Re: integrating Joram's 'visualindex'
On Aug 3, 2022, at 06:10, Jean Abou Samra wrote: > > Le 3 août 2022 à 11:44, Werner LEMBERG a écrit : >> >> >> Two weeks ago Dan asked the following: >> Can you force them to face each other? >>> >>> I think so, yes, with some TeX trickery. >> [… it is possible …] > > Sorry for jumping in as someone without any expertise in typography, but I > can’t help thinking: why create the problem if it doesn’t already exist? :-) If the index were split into two pages, I would prefer to see them together. I don't say that having to flip pages would rise to the level of "problem", but it would be an inferior experience. If accommodating it would disrupt the rest of the NR, then I think it would be better to make the visual index a separate document. — Dan
Re: integrating Joram's 'visualindex'
> Le 3 août 2022 à 13:12, Dan Eble a écrit : > > On Aug 3, 2022, at 06:10, Jean Abou Samra wrote: >> >>> Le 3 août 2022 à 11:44, Werner LEMBERG a écrit : >>> >>> >>> Two weeks ago Dan asked the following: >>> > Can you force them to face each other? I think so, yes, with some TeX trickery. >>> > [… it is possible …] >> >> Sorry for jumping in as someone without any expertise in typography, but I >> can’t help thinking: why create the problem if it doesn’t already exist? :-) > > If the index were split into two pages, I would prefer to see them together. > > I don't say that having to flip pages would rise to the level of "problem", > but it would be an inferior experience. I probably misunderstood the problem. Are you using a PDF reader where two pages at a time are shown at a time like when reading a book? If so, I understand the request. I thought this was uncommon, but I have no idea after all. > If accommodating it would disrupt the rest of the NR, then I think it would > be better to make the visual index a separate document.
Re: integrating Joram's 'visualindex'
> On Aug 3, 2022, at 07:24, Jean Abou Samra wrote: > > > >> Le 3 août 2022 à 13:12, Dan Eble a écrit : >> >> On Aug 3, 2022, at 06:10, Jean Abou Samra wrote: >>> Le 3 août 2022 à 11:44, Werner LEMBERG a écrit : Two weeks ago Dan asked the following: >> Can you force them to face each other? > > I think so, yes, with some TeX trickery. >> [… it is possible …] >>> >>> Sorry for jumping in as someone without any expertise in typography, but I >>> can’t help thinking: why create the problem if it doesn’t already exist? :-) >> >> If the index were split into two pages, I would prefer to see them together. >> >> I don't say that having to flip pages would rise to the level of "problem", >> but it would be an inferior experience. > > > I probably misunderstood the problem. Are you using a PDF reader where two > pages at a time are shown at a time like when reading a book? If so, I > understand the request. I thought this was uncommon, but I have no idea after > all. I usually use the Preview app in macOS, which has a few modes: • Show pages in a continuous scroll: Choose View > Continuous Scroll. • Show one page at a time: Choose View > Single Page. • Show two pages side by side: Choose View > Two Pages. — Dan
Re: integrating Joram's 'visualindex'
Hi Jean, > I probably misunderstood the problem. Are you using a PDF reader where two > pages at a time are shown at a time like when reading a book? If so, I > understand the request. I thought this was uncommon, but I have no idea after > all. This is my main way of reading PDFs! I have a widescreen [second] monitor, which can easily display two letter-sized (or equivalent) pages side-by-side. So much more convenient than single PDF pages or scrolling! Cheers, Kieren.
Re: integrating Joram's 'visualindex'
On 2022-08-03 4:24 am, Jean Abou Samra wrote: Le 3 août 2022 à 13:12, Dan Eble a écrit : If the index were split into two pages, I would prefer to see them together. I don't say that having to flip pages would rise to the level of "problem", but it would be an inferior experience. I probably misunderstood the problem. Are you using a PDF reader where two pages at a time are shown at a time like when reading a book? If so, I understand the request. I thought this was uncommon, but I have no idea after all. As a data point: I do use "book view" with all the manuals. While the typesetting probably could use left-facing and right-facing pages more intentionally, I have never really had any problems with the existing layout. -- Aaron Hill
Re: integrating Joram's 'visualindex'
> Le 3 août 2022 à 13:53, Aaron Hill a écrit : > > On 2022-08-03 4:24 am, Jean Abou Samra wrote: Le 3 août 2022 à 13:12, Dan Eble a écrit : >>> If the index were split into two pages, I would prefer to see them together. >>> I don't say that having to flip pages would rise to the level of "problem", >>> but it would be an inferior experience. >> I probably misunderstood the problem. Are you using a PDF reader where >> two pages at a time are shown at a time like when reading a book? If >> so, I understand the request. I thought this was uncommon, but I have >> no idea after all. > > As a data point: I do use "book view" with all the manuals. > > While the typesetting probably could use left-facing and right-facing pages > more intentionally, I have never really had any problems with the existing > layout. OK, I stand corrected. Today I learned :-)
Re: integrating Joram's 'visualindex'
> While the typesetting probably could use left-facing and > right-facing pages more intentionally, I have never really had any > problems with the existing layout. Well, it's not about the existing layout – even if we are going to use double-sided formatting, it wouldn't change much (besides some shifts in page numbering). The thing is that only in double-sided mode I can easily arrange the documentation to make the visual index appear on facing pages. Werner
Re: integrating Joram's 'visualindex'
On 2022-08-03 5:12 am, Werner LEMBERG wrote: While the typesetting probably could use left-facing and right-facing pages more intentionally, I have never really had any problems with the existing layout. Well, it's not about the existing layout – even if we are going to use double-sided formatting, it wouldn't change much (besides some shifts in page numbering). The thing is that only in double-sided mode I can easily arrange the documentation to make the visual index appear on facing pages. Theoretically, the documentation could be optimized for page turning, much like we do for music. In the NR, there are some sections of prose followed by relevant code snippets and the rendered result that sometimes awkwardly span across a page break, requiring flipping back and forth. For single-sided formatting, the only option is to try to fit things to one page; but with double-sided formatting, you would have the option to utilize facing pages. But again, I do not think double-sided formatting is strictly required for much of the existing content. The new visual index would be one of the few things that I think benefits reliably laying out side-by-side. -- Aaron Hill
Re: integrating Joram's 'visualindex'
>> Well, it's not about the existing layout – even if we are going to >> use double-sided formatting, it wouldn't change much (besides some >> shifts in page numbering). The thing is that only in double-sided >> mode I can easily arrange the documentation to make the visual >> index appear on facing pages. > > [...] In the NR, there are some sections of prose followed by > relevant code snippets and the rendered result that sometimes > awkwardly span across a page break, requiring flipping back and > forth. Indeed, this can be manually improved by inserting proper `@need` instructions. Note that it can only be improved and not fixed; in general, it is impossible to have a book-like layout with so many examples and just a few words plain text inbetween. With 'book-like' I mean non-ragged page bottoms that don't have excessive vertical space on the pages. > For single-sided formatting, the only option is to try to fit things > to one page; but with double-sided formatting, you would have the > option to utilize facing pages. This is a *hard* problem. Knuth's TeX engine has no support for that. There is active research to implement something like that for LaTeX using LuaTeX. But even if this might be possible to a certain extent, there are far too much examples to achieve good results for all of them. > But again, I do not think double-sided formatting is strictly > required for much of the existing content. The new visual index > would be one of the few things that I think benefits reliably laying > out side-by-side. Well, we don't have to take care of it at all; it's just inserting this single line of code I mentioned, and everything else is happening automatically. BTW, it would also make sense to improve the appendix holding the cheat sheet to cover exactly two pages; this could be a second benefit of two-side layout. Werner
Can't have rehearsal mark and segno mark at same moment
\version "2.23.12"
{
c'1
\mark \default
\repeat segno 2 {
c'1
}
}
A power user on -user-fr is frustrated that the above
doesn't work, as rehearsal-mark-event and segno-mark-event
are mutually exclusive at the same time step.
The request looks valid to me. Dan, what are your thoughts?
Did you have a specific reason in mind for forbidding this?
Should I open an issue?
Re: Can't have rehearsal mark and segno mark at same moment
On Aug 3, 2022, at 17:22, Jean Abou Samra wrote:
>
> \version "2.23.12"
>
> {
> c'1
> \mark \default
> \repeat segno 2 {
> c'1
> }
> }
>
> A power user on -user-fr is frustrated that the above
> doesn't work, as rehearsal-mark-event and segno-mark-event
> are mutually exclusive at the same time step.
I'm willing to discuss it, but I don't think you should open an issue yet.
I try to be conservative because it's easier to relax the rules than to tighten
them. I have tried to keep in mind the possibility of creating new features
where LilyPond uses "the" label at a given point of the piece. (The jump
instructions already do some of this.)
Having both a rehearsal mark and a segno seems like an unusual editorial
choice, where it might make sense to force power users into workarounds so that
more casual users can benefit from the warning.
Before discussing solutions, what are the details of the use case?
* Is this about true rehearsal marks, or one of the (ahem) creative uses of
rehearsal marks that are floating around in snippets? (e.g., fermata, CD track
number)
* Does the user want the rehearsal mark to appear in addition to or in lieu of
the segno?
* What does the user expect the automatic jump instruction to say?
* Are these the user's personal preferences, or are there historical examples?
Regards,
—
Dan
PATCHES - Countdown to August 5
Here is the current countdown list.
The next countdown will begin on August 5th.
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!1517 Make \caesura generally available - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/1517
!1516 configure: Use PKG_CHECK_MODULES directly - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/1516
!1514 ci: Reset git repository before test-baseline - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/1514
!1513 mf clean-ups - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/1513
!1511 Support delegating listening to member objects - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/1511
!1502 Page cleanups - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/1502
!1496 \fine does not end iteration - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/1496
Countdown:
!1520 Add ly_call() and ly_with_fluid() - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/1520
!1518 hairpin.cc: add left padding to broken hairpins - Martín Rincón Botero
https://gitlab.com/lilypond/lilypond/-/merge_requests/1518
Review:
!1521 Avoid building a temporary page for page layout - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/1521
!1515 Add mensurstrich bar type - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/1515
!1512 feta-scripts.mf: Improve shape of some glyphs. - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/1512
!1505 Use a unified output-def-kind variable instead of
is-{paper,layout,midi} - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/1505
New:
No patches in New at this time.
Waiting:
!1487 mf/README.md: Updated - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/1487
!1479 Rewrite PostScript font encoding access - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/1479
!913 release: binaries with cairo - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/913
Cheers,
Colin
