Arbitrary number for \gresetinitiallines

[jperon]

Woud it be possible to have more than 2 lines for the initial ?
I tried a workaround with wrapfigure, which sounds promising, but the length of the lines doesn't adjust, so they get out of margin :

\documentclass[12pt]{article}

\usepackage{gregoriotex,libertine,wrapfig}

\begin{document}

\begin{wrapfigure}[3]{l}{0.25\textwidth}
{\fontsize{120pt}{140pt}\selectfont I}
\end{wrapfigure}
\makeatletter\gre@noinitial\makeatother
\gabcsnippet{(c3)
()N(ed~)vo(e)cá(ehgh)bit(fd~) me,(e.) *(,)
et(fde) e(ef/hg)go(h) ex(h)áu(hhh)di(fe)am(e.f!gwh) e(hfge)um :(e.) (:)
e(fde)rí(ehh)pi(f)am(fdf) e(fgFE'f)um,(fe..) (;)
et(ef~) glo(e)ri(ef/hg)fi(g)cá(gi/jhhf)bo(h_g) e(hghf)um :(f.) (:)
lon(hg~)gi(h)tú(i)di(h)ne(hhh) di(f)é(fgFE'f)rum(fe..) (;)
ad(e!f'g)im(gf~)plé(fgE'C)bo(c!e'f) e(fgFE'f)um.(fe..) (::)
}


\end{document}

Perhaps it could be related to #1418

[rpspringuel]

This is something that's been on my ideal list of features for a while now, but I've not had a chance to work on it. Right now the readjustment of the line length that is necessary after the initial is handled within the manual line breaks and so it's necessary for the gabc code to contain multiple z or Z in order for multiline initials. I'd like to move that into the automatic line breaking mechanisms to remove this dependency and make it (and the placement of the initial) more responsive to setting \gresetinitiallines to numbers higher than 2.

There is, however, a work around for now. If \gresetinitiallines{2} is set, then the first "line" of the score can actually be more than 1 line of the score. The initial's vertical placement has to be adjusted manually using initialraise but it's possible to simulate a 3 (or more) line initial in a fragile way:

\documentclass[12pt]{article}

\usepackage{gregoriotex,libertine,wrapfig}

\grechangestyle{initial}{\fontsize{200pt}{0pt}\selectfont}
\newdimen\initialwidth
\initialwidth=0.25\textwidth
\grechangedim{manualinitialwidth}{\the\initialwidth}{scalable}
\grechangedim{initialraise}{-25pt}{scalable}
\gresetinitiallines{2}

\begin{document}

\gabcsnippet{(c3)
IN(ed~)vo(e)cá(ehgh)bit(fd~) me,(e.) *(,)
et(fde) e(ef/hg)go(h) ex(h)áu(hhh)di(fe)am(e.f!gwh) e(hfge)um :(e.) (:)
et(ef~) glo(e)ri(ef/hg)fi(g)cá(gi/jhhf)bo(h_g) e(hghf)um :(f.) (:z)
lon(hg~)gi(h)tú(i)di(h)ne(hhh) di(f)é(fgFE'f)rum(fe..) (;)
et(ef~) glo(e)ri(ef/hg)fi(g)cá(gi/jhhf)bo(h_g) e(hghf)um :(f.) (:)
lon(hg~)gi(h)tú(i)di(h)ne(hhh) di(f)é(fgFE'f)rum(fe..) (;)
et(ef~) glo(e)ri(ef/hg)fi(g)cá(gi/jhhf)bo(h_g) e(hghf)um :(f.) (:)
lon(hg~)gi(h)tú(i)di(h)ne(hhh) di(f)é(fgFE'f)rum(fe..) (;)
ad(e!f'g)im(gf~)plé(fgE'C)bo(c!e'f) e(fgFE'f)um.(fe..) (::z)
}


\end{document}

[rpspringuel]

See #1491 for my progress on this.

[davidweichiang]

Would it be good enough to use post_linebreak_filter to change the width of the rules to match the width of the line? The above example, plus the post_linebreak_filter hack, looks like:

[rpspringuel]

That would be almost exactly what I was thinking about, I've just never been able to figure out how to get the post_linebreak_filter to work that way. That's why my work on multi-line initials is stuck with still exploiting a z that is present in the gabc (though I've reduced it to just 1 being required in the semi-manual mode).

The thing I'm working on right now is getting the initial positioned correctly vertically (it's baseline should line up with the baseline of the last shortened line. This means calculating/predicting the heights of the lower lines because the initial is typeset at the beginning of the first line (as part of the first syllable). Unfortunately, calculating/predicting line heights of lines which haven't been printed yet is hard, and only possible in our case because of the our second pass adjustment of line heights (which means we record the information needed to make those calculations).

[davidweichiang]

The post_linebreak_filter hack is at https://github.com/davidweichiang/gregorio/tree/parshape. The TeX code uses an attribute to mark the box that contains the staff lines, and the Lua code just assumes that the top-level hlists are lines and that they have the desired width.

\parshape and \wrapfig work, but for some reason \lettrine does not.

What's the baseline of a line of music? Is it the baseline of the words?

[rpspringuel]

It's the baseline of the lowest element. That's usually the lyrics, but could be the translation (if present). If there are no lyrics then the baseline is the baseline that the lyrics would have if they were present.

[davidweichiang]

Since there's some glue between the lines, should the initial remain aligned with the lowest indented line, even if the glue stretches or shrinks?

[rpspringuel]

That has been our traditional alignment target, but to be honest as I've been working on this over the past few days I'm no longer sure that it's the correct alignment target.

In general for drop caps, I think it's more usual for the top of the dropped cap to be aligned with the top of the first line (though perhaps not including extensions above the nominal top line from things like accents). If we consider the initial in a score to be a form of drop cap, should it not have a similar alignment target? Perhaps the top line of the staff?

Of course, the complication here are the annotations. These go above the initial and we generally don't want them to protrude too high above the staff. Does this mean that annotations should push down the initial? Do they only do so if the are bigger than a certain size? Does the presence of above lines text, a commentary, or really high notes change this, and if so how?

I feel like some effort should be taken to look at old books with various size initials and see if there is any pattern to how things are lined up. Does anyone else have any opinions on this?

If we decide to keep the target alignment, #1491 is getting fairly close to getting the alignment right (I'm still missing something in my calculation of a custom line heights when variable line heights matter, look at the 2-line-initials test to see this problem, and have yet to deal with the glue issue that @davidweichiang just mentioned), but I haven't yet tried to incorporate @davidweichiang's solution for automatic adjustment of line width, so I don't know how the two will interact yet.

[davidweichiang]

Questions about #1491:

• In adjust_initial_raise, would it be simpler to directly measure the height+depth of the lines (and glues) to figure out the vertical position?
• I am not seeing how the result of adjust_initial_raise is getting passed back to TeX, but couldn't this function directly move the initial into the right place?
  If I'm thinking about this correctly, it would not require a second pass.

(I'm also not seeing why the variable heights computation requires a second pass, but that's a separate issue.)

[rpspringuel]

would it be simpler to directly measure the height+depth of the lines (and glues) to figure out the vertical position?

Probably. I've never really considered that option. Is it possible? My understanding has always been that our biggest hurdle is the fact that TeX processes stuff in one direction only. Thus when I'm typesetting the initial (the first, or very nearly the first) item in the score, I don't yet know things like how tall the lines will be. What I can do, and incidentally what we do with the line heights, is start with a reasonable guess and then record information about the elements that are either extremely high or extremely low as we encounter them (and figure out what line they are on). Then on a second pass we can use that information to refine our guess and repeat the process. Ideally this process will converge relatively rapidly (perhaps on the second pass) so that our guesses stop changing (and we can say we've arrived at "the solution." That's why I'm looking at our line height information and mostly reproducing the calculations associated with that (though I'm clearly missing something, since I'm not quite getting the same result).

I am not seeing how the result of adjust_initial_raise is getting passed back to TeX, but couldn't this function directly move the initial into the right place?

It gets passed back to TeX by setting \gre@dimen@temp@five which is then used to set the \raise for the box with the initial. I suppose the printing of the initial could also be brought over, I just hadn't considered that possibility.

[davidweichiang]

https://github.com/davidweichiang/gregorio/tree/parshape now uses Lua to calculate the vertical shift. But it will be off if the glue stretches or shrinks.

post_linebreak_filter gets called after each paragraph is made, so it does have access to all the lines and their heights/depths. It adds them up and then shifts the initial down by that much.

[davidweichiang]

Looking at the above image, though, I think I agree with your suggestion that aligning the top of the initial with the top of the first line is better (not to mention easier).

[rpspringuel]

So, I've finally had a chance to look at your parshape branch and am coming up with several problems:

1. You use \textwidth in gregoriotex-main.tex (lines 337 and 340). This is a LaTeX only macro and breaks our plainTeX support. You probably should be using our internal alias \gre@dimen@linewidth (which actually points at \hsize, the plainTeX equivalent).
2. gregoriotex-main.tex line 268 still makes use of \gre@adjustlineifnecessary which you've removed. This leads to lots of test being unable to compile.
3. Initials with descenders (which I admit, is probably a really rare thing) encroach on the line below them. See gabc-output/glyphs/shape-switching for an example. Admittedly, the initial in this test is a lowercase letter (g) which is why I think this is probably a really rare issue, and perhaps one we don't even need to fix (i.e. in the rare instance where initials have descenders, perhaps this is what they should do).
4. Applied to tex-output/bugs/fix-1373 this seems to break embedding scores in a parbox (and the notes go with them).
5. commentary is getting pushed into the right margin. See tex-output/commentary. It looks like the commentary box is getting pushed out by the initial width

[davidweichiang]

Thanks! I had not even tried running the tests yet. I can open a draft PR to make it easier to review.