[mpeg-OTspec] Re: [OpenType] JLREQ <-> fonts

[Levantovsky, Vladimir]

Dear Suzuki-san, all,

Thank you for providing additional comments. I don't think there is an urgency to address these issues by the next meeting but in general I think we (the AHG, i.e.) need to start collecting the list of issues that need to be addressed in the spec. We have an amendment that is now under DAM ballot so it is too late introduce any new issue there. And, since this is a second amendment to ISO/IEC 14496-22:2009 edition of the OFF standard - according to a new JTC1 process we would have to start working on the next, 3rd edition if we decide to make new changes and amend parts of the spec.

Over the last few months we had quite a few requests for changes, clarifications and new additional technologies (e.g. SVG outlines), so this work would be justified but it would require active involvement from all interested parties. I would like to thank you all for your contributions.

Thank you and regards,
Vladimir


> -----Original Message-----
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com]
> On Behalf Of suzuki toshiya
> Sent: Friday, October 07, 2011 1:24 PM
> To: OTspec
> Cc: opentype-migration-list at indx.co.uk
> Subject: [mpeg-OTspec] Re: [OpenType] JLREQ <-> fonts
> 
> Hi,
> 
> Eric Muller wrote:
> > It seems to me that we would have a much more reliable system if we
> used
> > an OT feature that would fundamentally deliver glyphs in the JLREQ
> > model. I understand that this also begs for a Chinese equivalent of
> > JLREQ; it's unclear to me whether we want/need a separate feature for
> > Chinese. And then there is the question of Hangul as well.
> 
> Indeed. I guess EPUB people may know some experts from China,
> Taiwan and Korea.
> 
> I think, the first step for OpenType experts would be the
> reconsideration that the features noted as only for Japanese
> in current spec are really only for Japanese, or pan-CJK.
> 
> Recently, there was a question about Taiwanese ruby in Unicode list:
> 	http://www.unicode.org/mail-arch/unicode-ml/y2011-m09/0158.html
> 
> Although I don't know how ruby annotation is required in Taiwan
> and Korea, "ruby" in current OpenType spec is noted as:
> 	Script/language sensitivity: Applies only to Japanese.
> 
> It might be reasonable to reconsider if "ruby" should be only
> for Japanese in future. In fact, ISO/IEC TR 29166 (edited by
> JTC1/SC34/WG5) will mention Korean ruby that vertical Hangul
> annotation is given to each Hanja even in horizontal writing mode.
> 
> Such kind of "only for Japanese" feature should be discussed for
> first. I will try to collect. Is this an urgent issue for next
> SC29/WG11 meeting?
> 
> Regards,
> mpsuzuki
> 
> Eric Muller wrote:
> > Message from OpenType list:
> >
> >
> >> ****** Attachments to this email message have been removed ******
> >
> > In the model of Japanese layout presented in JLREQ [1], a number of
> > characters such as the ideographic punctuations and the brackets are
> > described as 1/2 em wide, and the spacing tables add some space
> around
> > them as needed, typically an 1/2 em on one side, or 1/4 em on each
> side.
> > See for example figure 64 in JLREQ; the blue cells are space which is
> > added by the layout engine (and there is no space character in the
> > text). Not apparent from the figure: the added space is elastic, and
> is
> > adjusted as needed for the justification of the lines; and there is
> > space added on each side of each character - you don't see them in
> the
> > figure because the default width of many of those spaces is 0, but
> they
> > can grow for justification.
> >
> > The note 1 following that table states:
> >
> >
> >> In font <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#font>
> >> implementations, punctuation marks
> >> <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#punctuation-marks>
> can
> >> be given a different character width, but it is expected that the
> font
> >> is capable of following the line composition rules explained here to
> >> produce the final result. For example, when opening brackets (cl-01)
> >> <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#cl-01> and closing
> >> brackets (cl-02)
> >> <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#cl-02> are
> implemented
> >> with full-width size, it is possible that a minus half em space is
> >> inserted between adjacent closing brackets (cl-02)
> >> <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#cl-02> and opening
> >> brackets (cl-01)
> >> <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#cl-01> (Some
> >> implementations prepare minus half em
> >> <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#half-em> and quarter
> >> em <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#quarter-em>
> >> spaces). In letterpress printing
> >> <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#letterpress-
> printing>,
> >> it was also common practice to combine punctuation marks with a
> >> half-width body and half em spaces in order to make it easier to
> >> remove the space later for adjustment. Because of that, the types
> were
> >> picked up except for the punctuation marks at the type-picking
> >> <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#type-picking> phase,
> >> following the manuscript, and the punctuation marks were picked only
> >> when they were necessary in composing a page. Later, with the
> >> increasing adoption of Monotype machines, punctuation marks with a
> >> full-width body became popular and both full-width and half-width
> >> punctuation marks have been used, mixed together, since then.
> >
> > It is indeed the practice in OpenType fonts to have the advance width
> of
> > those glyphs at 1em and to place the ink accordingly. For example,
> the
> > ink of a left parenthesis is in the right half of the em, and the
> left
> > half is empty; the ink of a right parenthesis is in the left half of
> the
> > em; the ink in a middle dot is in the center half em, with the left
> and
> > right quarter em empty.
> >
> > I suspect that in addition to the letterpress heritage, this allowed
> > "western" layout engines to produce acceptable results. Essentially,
> the
> > most typical space that is normally added by a JLREQ-aware engine is
> > built in the glyph, and a non-JLREQ-aware engine will therefore
> produce
> > an acceptable layout most of the time (in unjustified lines, at
> least).
> >
> > The consequence for a JLREQ-aware layout engine is that it must
> > fundamentally "remove" that built-in space. This means a table in the
> > layout engine to record what to remove (how much, on which side) from
> > which character.  While such a table is often adequate, there are
> some
> > problems:
> >
> > - first, this convention is not recorded anywhere in the OT specs,
> yet
> > it is clearly crucial for the interoperability of layout engines and
> fonts
> >
> > - proportional and non-square fonts present a challenge; should one
> > remove 1/2em or 1/2 the advance width of the glyph
> >
> > - the situation is a bit different for Chinese, where the ideographic
> > comma and period are centered in the em, instead of being on the left
> > half; yet, there is no reliable way for a layout engine to know if it
> > deals with a Japanese font or with a Chinese font (not to mention
> > pan-CJK fonts)
> >
> > It seems to me that we would have a much more reliable system if we
> used
> > an OT feature that would fundamentally deliver glyphs in the JLREQ
> > model. I understand that this also begs for a Chinese equivalent of
> > JLREQ; it's unclear to me whether we want/need a separate feature for
> > Chinese. And then there is the question of Hangul as well.
> >
> > Discussion?
> >
> >
> > Eric
> >
> > [1] JLREQ : Requirements for Japanese Text Layout, W3 Working Group
> > Note, http://www.w3.org/TR/2009/NOTE-jlreq-20090604/
> >
> >
> >
> >> ****** Attachments to this email message have been removed ******
> >
> >
> >
> > List archive: http://www.indx.co.uk/biglistarchive/
> >
> > subscribe: opentype-migration-sub at indx.co.uk
> > unsubscribe: opentype-migration-unsub at indx.co.uk
> > messages: opentype-migration-list at indx.co.uk
> >
> >
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>