Files accidentally converted to UTF-8

[GoogleCodeExporter]

 - r154 converted web/www/horas/Latin/Sancti/05-01r.txt to UTF-8.
 - r155 converted web/www/horas/Latin/Tempora/104-4.txt to UTF-8
 - r157 converted web/www/horas/Latin/Commune/C1.txt to UTF-8
    - r158 then added CP1252 accents to the invitatory. It therefore has no consistent encoding at present.

Incidentally, I find changes like r166 a bit odd. The file was in Mac Latin-1, 
which was obviously wrong, but instead of converting it to CP1252, which would 
have preserved the accents, all the accents were removed, even though we 
ultimately want all the text to have accents.

Original issue reported on code.google.com by a...@liturgiaetmusica.com on 31 Oct 2011 at 10:10

[GoogleCodeExporter]

Indeed.  There are several softwares contributing to edits to the text, and 
indeed they sometimes trip over each other.    Certainly r157 was a mistake of 
that sort.  I believe that with r180 all the text is in correct and reasonable 
Windows-1252: which was not true even at r2, unfortunately.   The rule for now 
is: Windows-1252 only.  Most browsers accept its non-Latin-1 characters 
correctly even when told that the transmission is in Latin-1.

Our goal is, indeed, to add pronouncing accents to the Latin text, using the 
19th- and 20th-century conventions, and to replace "ae" with either "æ"z or 
"aë" depending on which is correct.  For now, the accent on æ must be omitted 
because it is not on the code page.   (The accent on œ doesn't apparently 
appear even in Unicode).  

The other goal, of course, is to move to UTF-8 on input and on output.   To do 
this gradually requires that the textbase support both at once, with the 
decision which being guessed (correctly!) when the file is read.  I am moving 
that work to branches/utf8.

Original comment by a...@malton.name on 2 Nov 2011 at 2:16

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****