I would agree that this is a "good" use of the <emph>. It reminds me
of using the em/@style or em/@class in XHTML. If you have other style
features (bold, italic, etc.), you can just nest the emph inside
another emph. This works well for XHTML markup. You may want to
develop XSL-FO syntax for your emph/@altrender usage. At least this
would give you a good rule for what to expect when transforming to
PDF (or some other) XSL-FO output format. (You may want other
features of this font besides just the font itself, like bold,
italic, etc.)

I would make a number of points about EAD 2002.

1. We are giving the real unicode characters in a utf-8 environment.
Therefore, the glyph problems of current fonts are really not our
problem. (Nothing personal...)
2. There may be real problems with specifying fonts that are
microsoft-centric in this open source world. It gets more narly when
you think that my windows 2000 has a different unicode edition for
the same font name as the font for windows 2003 XP Professional. The
result being that the glyphs for some scripts are still not in my
Windows 2000 Arial font though it has the same name.
3. Maybe it won't matter in one way, since you are pointing your
stylesheet to transform based on the expectation of emph being used
for font designation and my stylesheets are not. No problem on my
end, but you got your font just fine on your end.
4. Maybe we can solve this with a namespace element that really deals
with it. However, given the Microsoft issues in my previous point,
you may need much more identification information for the particular
version of the font you want to use (or can be used). But it is
possible that the element from the other namespace has this

As someone who stays in touch with this kind of glyph stuff, I have
asked the unicode developer here at LoC what unicode edition the new
Windows OS fonts have. His information is that they are still below
version 3.5. He has actually advocated using Takoma (correct me on
this) instead of Arial Unicode due to glyph coverage. Amazing as it
may seem, Microsoft has two big failings in this area: 1) most fonts
are still only at unicode 2.5; 2) Even those that claim higher
unicode edition converage have big holes in them where no glyphs are

Even the full range of current Latin script is still not covered by
glyphs on Microsoft Windows OS fonts. In some cases, non-MS browsers
do a good job of working with this failure despite the lack of font

These are all good reasons why many are thankful for Code 2000. It
may not be pretty, but who really wants to worry about rendering a
finding aid into PDF using a font that does not cover your unicode?

I can only hope that the community will: 1) pressure MS to upgrade
their OS fonts to current unicode edition; 2) Open type fonts will
come of age and be available for all to use.

Anyway, my two cents.

Mike Ferrando
Library Technician
Library of Congress
Washington, DC

--- Stephen Yearl <[log in to unmask]> wrote:

> A question for those who have some experience with multi-language
> instances.
> When creating xsl:fo one has to explicitly set @language-family to
> a font
> that will display the desired language. This is not a problem for
> western/romance languages since FOP's default font set has glyphs
> for these.
> It is a problem, say, for Arabic. There is a font I know of that
> has glyphs
> for the entire Unicode character range (at least as of version 2),
> that
> comes pre-installed on the most recent Windows releases, Arial
> Unicode MS.
> It is, however, particularly ugly and I'd like apply fonts for
> 'exotic'
> languages at a much finer level.
> I'm thinking that
> <p>This is in English but this <emph render="altrender"
> altrender="set_font:Iqraa">المرسل إليه</emph> is not, and
> neither is
> this<emph render="altrender"
> altrender="set_font:Pigiarniq">ᓴᓕᑦᑐᑐᖅ </emph>
> .</p>
> is 'acceptable-ish' but might abuse <emph> somewhat; this is not
> for
> linguistic effect. And it doesn't capture the essence of what I'm
> trying to
> achieve or tell one anything meaningful about the language.
> How have others dealt with this given the lack of a generic text
> segmentation element?
> (I guess that this is an informal call for something like the TEI's
> <seg> in
> EAD v.3).
> Thanks,
> St.
> Stephen Yearl
> Systems Archivist
> Yale University Library::Manuscripts and Archives

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around