Mariage

Task arising out of meeting with CC 2012-12-03:

1. In references, any <ref> element in listBibl should be converted to a <ptr> element.
2. Encoding instructions/documentation should be updated to reflect this.
3. When rendering, the target attribute of the ptr should be used to create a link out of the first component in the reference (title of an article, etc.).

1. le_blanc.xml:
Page number “76” in the t.o.c. should be in alignment with “ſon Mary.” in the chapter title, “La Conſolation & la Direction d'vne/Femme , qui n'eſt point aimée de/ſon Mary.” There seems to be a bug that’s creating a line break between the chapter title and page #.

2. maladies_des_femmes.xml:
a) Links to notes are still causing formatting issues in t.o.c. but I believe most of these problems should be fixed when the notes are replaced with <sic><corr> tags.

b) The note next to page number “75” (“Anomalie de pagination de la part de l'imprimeur; à la place de « 74 », il a mis « 75 ».”) is interfering with the first line of that page (“engendre la gonorrhee: il aduiẽt auſsi que la quãtité ou la quali-”). It’s creating an indent that shouldn’t be there.

3. References.xml file:
a) Link references within references. (Reminder: if a term appears more than once within the same reference, only tag the first occurrence.)

b) Remove <ref> links in all <cit><quote>s. (We decided not to put <ref> links in quoted material to avoid giving the erroneous impression that the source of the quote came from one of our references)

c) References need to be reviewed because there are still some, such as for word definitions, which should be converted into notes.

4. Review and standardize usage of <cit><quote> -> See MH’s blog post “Quotes and cits -- need to do a review and standardize” (15/06/11)

5. All <argument> tags need to be changed into <label> tags.

6. Include a “back” button (⇐) for references and notes? This could be helpful for the user because when you click on a link within a reference or a note, the only way to return to the original reference/note is by going back to the text and clicking on the link. By including a “back” button in the window of a reference/note, the user will be able to return to the original reference/note more easily. CC and MH will have to discuss this.

7) MH has to upload changes to Mariage site for GMM and EGB through Exist Client.

Reminders for CC:
1. Questions to ask Evelyne for Marinello text:
a) Does she want all abbreviated terms for medications written in Latin to be translated into French and then have references written for them?

b) Definitions for “thym,” “maladie de nymphe” and “ansules”?

2. Ask Hélène Cazes to:
a) transcribe missing Greek phrase in Sonnet 1609 (“Et voſtre Muſe eſt tanquam [missing greek text] vous ne portez...”)

b) verify that transcription of Greek word in Des maladies des femmes (“à raiſon dequoy les Grecs l'on appellé μπτοα”) is correct.

MH also suggested that he could ask a student who knows ancient Greek to complete these two tasks.

There's a problem with the display of the chapter heading "Le traictement de la femme nouuellement accouchee, & tout le temps de ſa couche" (c.50.p.845) in the Maladies des femmes table of contents. There is a break between "tout" and "le" but there shouldn't be one. EDIT by MDH: This appears to have solved itself, or to have been solved by a previous fix. There's no break I can see. It's possible to make lines break by setting very large text in a narrow browser window, but that's preferable to having the text disappear or intrude into another block of text.

Handler needs to be written for <g> tags that are not in context of an abbreviation. EDIT by MDH: This has been fixed.

Find out why paragraphs that begin with drop-caps don't inherit "margin-top: 0" and "margin-bottom: 0" from TEI header in the Maladies des femmes. EDIT by MDH: The simple answer to this is that I was explicitly excluding the paraStyle CSS in the case of a drop-cap paragraph because any text-indent setting screwed up the drop-cap. However, I've now done something more sophisticated, by stripping out the text-indent setting with a replace() using this regex:

(text-indent[\s]*:[\s]*[^;]*[;])|(text-indent[\s]*:[\s*][\d][^\s;]*$)

Task for MH: Please find out why note tags are interfering with alignment of chapter and page numbers in table of contents in Maladies des femmes text. Chapter and page numbers should be floating right.

EDIT by MDH: This task seems to have been obviated by two things: First, most of the notes included in the TOC should actually be <choice>/<sic>/<corr> or <choice>/<orig>/<reg> blocks, so there will be a lot fewer note buttons in the TOCs in any case. Second, including a note inside a linked page reference is impractical, because it's not clear what clicking on it could or should do -- show the note, or go to the page reference? So on balance, it makes more sense to attach notes to the text preceding floating page numbers, if there's actually a need for a note, but when the note is simply (for instance) noting an incorrect page number in the original, we can just use <choice>/<sic>/<corr>.

[EDIT BY MDH: Fixed this in the CSS. Look out for unwanted side-effects.] Task for MH: Figure out why page numbers for even-numbered pages float far left for both Le Blanc and Maladies des Femmes texts.

EDIT by MDH 2011-12-22: I believe this task has been obviated by the proposed (and partially-implemented) change from using <argument> to using <label>. Setting this task to Completed.

Note to self: I thought I had made substantial amendments to the schema that would permit us to use <argument> inside e.g. <p>, because that's where our marginal arguments most often show up. However, in the Le Blanc text, that seems to be failing, so I need to revisit it. The text has been marked up in such a way that open ps and divs are being closed before and argument and opened again afterwards, and when I try to refactor appropriately, the code turns out not to be valid. Either the validation process is failing somehow, or the schema is not the most recent, or perhaps my modifications didn't go far enough.

EDIT by MDH 2011-12-22: I believe both of these issues are now fixed. I wrote a template to split lists and it's now in use, and I think LSPW has fixed the erroneous @target attributes. Setting this task to Completed.

Several XHTML validation issues have arisen recently. They fall into the following categories:

• Unexpected elements inside lists. le_bon_mariage.xml has many instances of page breaks, and forme works which occur inside lists. The XSLT doesn't expect this, and outputs XHTML elements inside <ul> and <ol> which are of course invalid (only <li> is allowed).
• Duplicate ids in reference links. Reference links inside the text are provided with unique ids so that you can navigate to them, and these ids are constructed from the target id of the reference itself, followed by an underscore and a number; numbers are provided in sequence by counting preceding references. This is going wrong somehow, resulting in more than one reference link with the same id attribute in the XHTML.

The first requires a policy decision (do we allow other elements than item inside of list?), followed by fixes to the XML and/or the XSLT to deal with the consequences of the policy. The second seems to be caused by typos in the @target attributes of ref elements in the references file; I've identified a set of these and asked LSPW to fix them. The same kind of typos also show up in anthology documents, so I've identified a stack of them using XQuery and sent them to LSPW too.

NOTE: With regard to the first issue, I wrote to the TEI list, and had a number of useful responses; I think the most appropriate was to keep the current markup (which is, after all, "correct"), but use a two-stage transformation to get the document to XHTML. In the first stage, any lists bisected by page breaks, forme works etc. would be split into two lists, allowing the second transform to proceed appropriately. This is a really good idea, and could also be used to handle bisected lgs, which are currently output as <ul>/<li> sets if they're not bisected, or <div>/<span> sets if they are.

Arising out of a discussion with CC: The intended use of <choice>/<orig>/<reg> in the original transcriptions of the engravings is to restore normal contemporary usage, while the modern transcription is a full modernization. However, there are instances of <choice>/<orig>/<reg> which are used to replace long s with short s (dating back to when we had no modernizations), so these are inconsistent with our policy, and we should get rid of them. I might be able to do this entirely mechanically -- in the case of any regularization where the only difference is between long and short s, I can simply replace the entire <choice> element with the contents of <orig>; while for every regularization where a long s exists in the <orig> but other things are also regularized in the <reg>, I can add an attribute we can use temporarily to find and manually fix them. This is now on my task list.