(02-09-2026, 12:00 AM)Jorge_Stolfi wrote: You are not allowed to view links. Register or Login to view.Thus any analysis that depends on word breaks will have some amount of "noise". In your case, strings that your program considers to be suffixes could be middle parts of the intended word.
Exactly. It would be most tedious to go through each transcription and try to judge what the transcriber meant and you'd always be guaranteed to get something wrong.
(02-09-2026, 12:00 AM)Jorge_Stolfi wrote: You are not allowed to view links. Register or Login to view.(01-09-2026, 10:33 PM)Dunsel wrote: You are not allowed to view links. Register or Login to view.? - splats. I strip any word that contains even 1 splat.It is a sensibe decision. The "?" may be an unreadable glyph, but may also be a "weirdo" glyph that occurs only a few times,and thus probably a Scribal error.
For the moment, I think it's reasonable. If it is a weirdo, it's not going to be in most 'normal' transcriptions. None that I know of transcribe the two "V" wierdos on f1r. And, as in the case of the ASCII characters in the ZL transcription, that would be for a later analysis. I'm just trying to get the big picture for the moment. Eventually, with the ledger, weighting, some OCR and spell checking algorithms, I think it would be possible to put some scoring system on repaired splats (those that have most of their letters).
(02-09-2026, 12:00 AM)Jorge_Stolfi wrote: You are not allowed to view links. Register or Login to view.I did not follow the details of this comment, but yes: in my word model, there is no standalone c or C. There are only Ch, CTh, CKh, CPh, CFh. Thus when I see something that looks like a c outside of these cases, I assume that it is a distorted e and transcribe it as "e". There are rare cases of CHh, CTHh, CKHh, CPHh, CFHh; I transcribe them as such, but I think those are actually Che, CThe, CKhe, CPhe, CFhe .
And that explains it perfectly. From my side, it didn’t look like the other transcriptions I’ve loaded into the ledger, so I was trying to understand why the "c" row looked so different.
Running your transcription through the ledger-building code recovered your "c" rule and put it directly into the ledger. Now that you’ve explained the transcription convention, the "c" row is exactly what I would expect to see from the rule you described above.
So, I would say those are pretty accurate ledger renditions of your transcription.

