LEMDO work 2022-10-31 to 2022-11-04
to : Martin Holmes
Minutes: 440
Worked with PS to figure out a strategy for image encoding and rendering
that will support the range of different image styles the team wants to use
and be optimized for rendering. The strategy we’ve settled on is to always
include the true image width and height in the <img>
tag (taken from the TEI), along with a pre-calculated @class
attribute of landscape
or portrait
. This gives enough info
for the rest of the layout decisions to be handled by the CSS.
The TEI <figure>
element will be used
attribute to provide caption and alt text, and a @type
attribute will be used to specify the preferred rendering option (still
to be specified).
Also closed some tickets whose fixes have proved successful, and added a couple of CSS tweaks over the weekend.
On Tuesday, we had a scheduled meeting to go through the proposed rollout
of the new taxonomy for @place
. We made a number of decisions on
this and other issues:
- NH and JJ will map out the correspondences between existing and new values for the attribute.
- Next week we will collectively write the XSLT identity transform which will make the changes in the input XML, as a training activity.
- For stage directions, the existing
@type
attribute will still be used as hints for default rendering. Editors can override using either@rendition
or@style
, but would not be expected to do this in modern texts. The new placement values are purely informational. - Based on a couple of instances in Hamlet, there seems to be a need
for the
@place
attribute to be available on the<sp>
element. NH and JJ will seek out further examples of this and raise a ticket on the TEI repo. W will seek other ways to encode this relatively rare phenomenon in the interim. - The annotation rendering seems to be working OK, except in the case of
prose, where (of course) there are no block elements inside a speech, so no
way the vertical lines for block annotations can be created. If the speech
markers are placed on the outside of the
<p>
element containing the speech, then you do get the vertical line, as expected. In other words, to trigger a vertical line, an entire block element in the HTML output must be contained within the annotation. This seems reasonable, and it’s hard to imagine any other working approach. - The click target on vertical lines was too narrow, so I’ve expanded it a bit.
On Thursday, worked through some open tickets, and finally fixed the problem with issue #6, so I expect to see a working search filter for documentation audiences when the build has completed.
On Friday, JJ and I eliminated all cases of listBibl/head
in favour of a <head>
element in a parent <div>
and changed the schema so that only <bibl>
is allowed in
<listBibl>
. This makes processing much easier.