Eliminate biginitial style

[henryso]

This discussion began in #630. Please continue the discussion here.

[rpspringuel]

Since I'm the one that raised this issue, allow me to write my "manifesto" of where I see this going:

Deciding what kind of initial to have accompany a score is, in my mind, a typesetting decision, not a score representation one, and thus should be in the TeX and not the gabc. I would thus like to see the initial-style field in the gabc header deprecated. Additionally, I'd like to see GregorioTeX be able to automatically break the shorter lines instead of relying on manual line breaks in the gabc. (The mechanics behind drop-caps might be helpful in making this happen.)

In it's place, I'd introduce a \gresetinitialsize command which takes a numerical argument representing the number of lines of the score the initial takes up (currently 0-2, but eventually 0-4).

There would then be just one set of initial related parameters: initial (style), beforeinitialshift, afterinitialshift, manualinitialwidth, and initialraise (distances). The default values for these parameters would be chosen to be approximately appropriate for 1-line initials. The user would be responsible for changing them when switching to larger initials.

I would then add an example which demonstrates how to set up some "master commands" which can allow the user to quickly switch between different initial settings in a project where it is necessary to switch back and forth between various sized initials. I would not include such commands in the package.

[henryso]

I agree with this on a philosophical level (which is why I closed out my pull request). However, there is a technical issue in that center determination on the first syllable changes depending on whether or not there is an initial. Perhaps the first syllable could use a different macro to indicate the two different "centerings", which would result in four centerings:

• no initial vowel centering
• initial vowel centering
• no initial first letter centering
• initial first letter centering

[eroux]

I agree with the general idea, including the new centering proposed by @henryso I just think maybe we should leave it for 4.1?

[rpspringuel]

This is definitely something I would leave for 4.1.

A different macro for the first syllable is, I think, almost a necessity at this point. We're already disecting it six-ways from Sunday in order to do the styling that @henryso introduced and this will just make things worse.

As I see it, the first syllable needs to have the following parts identified:

1. Initial
2. First letter after the initial
3. everything else in the syllable
4. First part of the syllable (what comes before the vowel) when there is an initial
5. First part of the syllable when there isn't an initial
6. Middle part of the syllable (vowel) when there is an initial
7. Middle part of the syllable when there isn't an initial
8. Last part of the syllable (what comes after the vowel)

4 & 5 are different when the syllable starts with a consonant; 6 and 7 are different when the syllable starts with a vowel. I've assumed that the initial is never in the last part of the syllable.

There might be a way to extract 5 & 7 from 4 & 6 using 1 and some of xstring's string manipulation capabilities, but that might very well create difficulties with the formatting stuff.

Though, with a different command for the first syllable than for all the rest, we may not need to put styling commands explicitly in the gtex file and can instead apply them completely internally. That might make the string manipulation of the first syllable possible.

[henryso]

People will always find a way to do some weird styling, special characters, and texverbs, so I think it's better to just divide in up into the pieces you mentioned rather than manipulate in it TeX.

[henryso]

@rpspringuel, how should I deal with user-specified styling of the first letter of the score? Should I provide styled and unstyled versions?

[rpspringuel]

I'm not sure what you mean. Do you mean a first syllable which is styled with tags in gabc (<b></b> etc.) and then extracting the potential initial with and/or without those tags?

[henryso]

Yes, that's what I mean.

[rpspringuel]

I should think that tags in the gabc should be generally ignored in the first word because of the existence of the appropriate styles in the TeX (initial, firstsyllableinitial, firstsyllable, and firstword). Not ignoring them would lead to strange interactions between the tag formatting and the styles.

Is there a situation where one would want the tags to apply despite the styles? Or some situations where the tags allow something the styles don't?

[henryso]

We could ignore styles, but people seem to do very "interesting" things with that first syllable, and this would be surprising behavior. I'm willing to bet that someone's going to want to do something unusual like make all e's in the score red.

[rpspringuel]

In that case I would pass the tags as they are entered in the gabc and let the user sort out the interactions manually.

[henryso]

Ok, so by example, let's say the first syllable is <b><c>P</c>sal</b>m. I would extract:

1. <b><c>P</c></b>
2. <b>s</b>
3. <b>al</b>m
4. <b>s</b>
5. <b><c>P</c>s</b>
6. <b>a</b>
7. <b>a</b>
8. <b>l</b>m

Does that congrue with what you are thinking?

[rpspringuel]

Yes. That concurs with my thought.

[henryso]

Not 4.1?

[rpspringuel]

I marked it as 5.0 rather than 4.1 because it requires a user interface change (we'll be deprecating commands that are specific to the big initial). I expect it will appear in 4.1, but then the next release will have to be 5.0, not 4.2. Putting the 5.0 milestone on it was my way of noting that (admittedly, it's not a very clear way of doing so).

[henryso]

Is the intent to have the initial-style gabc header be transferred like the annotation headers or is the initial-style header to be deprecated?

[henryso]

@rpspringuel Did you have any thoughts on this?

[henryso]

An additional question: Is the desired end result to have two states: initial and no-initial, or three: normal-initial, big-initial, and no-initial? I cannot proceed much further with the implementation (which you can see in my fork as fix-632) unless I know the answer to this and my previous question.

[rpspringuel]

Sorry, been a bit busy this past week.

My idea was that the initial-style header would be deprecated and replaced by a \gresetinitialsize macro (or something similarly named). Thus, I'm thinking more in the lines of the changes made to centering-scheme than annotation.

The \gresetinitialsize macro should, at the least, allow for 0, 1, and 2 line initials (the current options). Ideally it should also allow for 3 and 4 line initials (a feature requested by Br. Innocent in a face-to-face conversation we had some time ago).

[eschwab]

That scheme makes sense to me. However, I would propose a macro name that indicates that it is concerned with the line height and not font size. \gresetinitialheight or \gresetinitiallineheight or something else.

[henryso]

How about \greinitiallines?

[rpspringuel]

You know, I almost put that down in my previous post and then realized that I has used \gresetinitialsize in my first post and thus changed to be consistent. I think that or \gresetinitiallines would be very appropriate.

[henryso]

How would I deprecate \gre@style@biginitial properly? If the desired end state is that there is only one style, \gre@style@initial, I can't see any way to deprecate \gre@style@biginitial in a backward-compatible way. Is this OK?

[rpspringuel]

I would add something like the following to \grechangestyle

\IfStrEq{#1}{biginitial}{\gre@deprecated{biginitial style}{initial style}\grechangestyle{initial}{#2}}{<current contents of macro>}

This way if the user tries to change the big initial style they get warned about it. Off the top of my head, I can't think of a way of warning those who were happy with the defaults, but I think about it some more and see if I can't come up with something.

[henryso]

Should I create a branch off develop in the main repository to collaborate?

[rpspringuel]

I don't think that's necessary at this point. I'm busy with a paper for probably the next week and won't have time to do any work, just to suggest ideas.

Speaking of which, here's the brainstorm I had today.

Like the allowdeprecated=false option for GregorioTeX, the command-line tool should have a run time option that forces it to error out when it encounters a deprecated header, rather than simply emitting a warning and continuing on. Autocompilation should then tie into this flag so that a deprecated header in a gabc file will halt compilation just as a deprecated macro name does when allowdeprecated=false is used. When it's not used, we need to make sure that the command-line tool's deprecation warning ends up in the log file (it may already do this, I don't have time to check).

Since the elimination of the biginitial style involves deprecating the initial-style header, setting the command-line tool up in this fashion will ensure that the appropriate warning/error ends up in the log file.

To maintain backwards compatibility, something like what you did for the centering-scheme header needs to be done when deprecated functions are allowed. I.e. the command-line tool passes a special command which allows GregorioTeX to trip into the equivalent of the old settings (raising the appropriate warnings in the process) and then get back out when the score is completed.

[henryso]

I didn't think about that angle. I'll give it a shot.

[henryso]

By the way, we don't have to make the command line tool error out in that way. The command line tool typically emits something deprecated when a deprecated feature is used. This is easily trapped in TeX, so the stop/continue behavior can live wholly in TeX. That's how I implemented the initial-style deprecation. It will emit \GreSetInitialStyle, which uses the \gre@deprecated macro to control whether TeX should stop.

[rpspringuel]

I agree that the behavior can be completely controlled in TeX. However, I still think it might be a good idea if the command-line tool had the capability of erroring out in the event of a deprecation. If it did this, then I could conceive of writing a shell script which could check every gabc file in a large file, looking for the file which need to be updated.

Actually, now that I think about it, this might be a better accomplished with the gabc-to-gabc functionality of the command-line tool. The command-line tool obviously shouldn't output any deprected headers when writing a gabc file, so by passing it over all the gabc files with the -F gabc option, all the deprecated headers should get removed. We probably need to update the gabc-output writing stuff to make sure that happens.

[henryso]

OK, but I think that's better handled as a separate issue.

[rpspringuel]

Agreed.

[rpspringuel]

Well, let me qualify that. In so much as your works deprecates the initial-style header, it should also make the changes to gabc-write.c such that initial-style headers are no longer written out. The other headers which have already been deprecated should be handled separately.

[henryso]

Understood. It already behaves that way for initial-style. I'll create the issue to check the other headers.