Changes in .csv mapping file that have to be corrected/changed

[JoyfulGen]

While fixing these issues (#295, #273, #257) @giannatan made changes to the .csv mapping file. She's sent me a detailed list of the changes she made, and some of them are correct, some are not, and some are things that need to be discussed.

Square notation

Change	Comment
added alternate F clef	Error: there shouldn't be an alternate F clef for square notation
divisio maior + finalis added	Correct
width column changed from [1, 1]/2/1 to [2] (single shared column instead of two separate ones) for podatus, pes cephalicus, obilque, as both components share one column	This is correct for the podatus2b and the oblique, but not for the pescephalicus and podatus2a
scandicus 22b/22c width changed from [2, 1] and [1, 1, 1] respectively to [1, 2] for both	Error: the scandicus22b and 22c have different widths because they look different. The original widths are correct.

Hufnagel notation

Change	Comment
Added divisio finalis	Correct
width changed from [1, 1] to [2] for podatus and clivis (-> single shared column)	Error: both of these neumes have a width of [1, 1] in Hufnagel, unless the clivis2a needs to have a width of [1] because the elements are ligated. This change explains the podatus error in #295; the width is wrong because the mapping file is wrong
ligature encoding fixed for clivis2a-5a by replacing con="e" with ligated="true" on both nc elements	This is correct for now, but won't be later. See DDMAL/Neon#1366
torculus22/23/etc. changed width to [1, 2] (last two components now share a column), con="e" on third nc replaced with ligated="true" for ligation to actually show up in neon	Same as above

@giannatan where did you get your mapping files? Some of the elements you added are already in mine, so I'm worried there are alternate versions floating around.

It's very important that all of our mei mapping files, in mothra and our various resources repos, match exactly. I suggest we don't make more changes until @giannatan, @zih-syuan and I have confirmed that my comments above are correct and work properly. Once that's done, we can make a definitive mapping file and make absolutely sure that all our files are updated! Once Neon is updated to accept con="e", we'll have to update the mapping file again.

[giannatan]

hi! the mapping files are/were the same ones used by the ic, i had to make changes as more encoding bugs that had to do with the csv itself were found. i can make the changes you mentioned to the csvs i have now, unless you want to use it to make a formal "standardized" one?

[JoyfulGen]

Yes I do want to make a formal "standardized" one! So did you get your mapping files from the IC, or from a repo somewhere?

[giannatan]

@JoyfulGen i got the files from the ic repo!

[JoyfulGen]

Important update: DDMAL/Neon#1366 is now fixed, so we should not replace con=e with ligated=true.

[JoyfulGen]

@giannatan could you upload the mapping file that's currently used by mothra to this issue?

[giannatan]

hufnagel.csv
square.csv

should be these two!

[JoyfulGen]

I've made the changes I outlined above to the two mapping files:

hufnagel definitive.csv
square definitive.csv

@giannatan and @zih-syuan could you both have a look and confirm that these look good and will work well? Are there any more changes we should make?

[giannatan]

@JoyfulGen looks good! i think switching this in will result in little to no issues, so i can make the swap if you wish

[JoyfulGen]

Yes, that sounds good! I'd like to see what this looks like in Mothra. Once @zih-syuan also confirms that it looks good, we can replace all of our various mapping files in various repos with this definitive version. Thank you!

[zih-syuan]

Hi Gen, before I confirm the definitive square mapping files, could I check one encoding decision?

For the square-notation obliques, the mapping uses two <nc ligated="true"> components without @con. Is that intended to be our canonical representation for obliques?

I checked the current MEI 5.1 Guidelines: they define @ligated and @con separately, but I couldn’t find a prescribed canonical encoding specifically for square-notation obliques. I’d like to confirm that omitting @con here is intentional before we propagate this mapping across the repositories.