Skip to content

Meaning of 'glyph area descendant' #236

Closed
Closed
Meaning of 'glyph area descendant'#236
Labels
WR-commenter-agreedWR-resolveddiscussed and agreedi18n-needs-resolutionIssue the Internationalization Group has raised and looks for a response on.pr merged
Milestone
1ED-CR1

Description

@r12a
r12a
opened on Jan 26, 2017

[This was intended to be a quick query by email, but it is developing into a thread, so i'm copying the discussion here for ongoing discussion.]

my original question:
I'm working on review comments for the ruby section, but i'm a bit stuck because i don't understand the meaning of the term 'glyph area descendant', and i don't see it described anywhere. Could one of you explain what that is? I think it will be important to understand it in order to assess the ruby section.

Activity

  1. r12a commented on Jan 26, 2017

    @r12a
    r12a
    on Jan 26, 2017
    Author

    [reply by Glenn]

    It is referring to the area tree produced in formatting. See XSL-FO for the conceptual model. The basic hierarchy in this local context is:

        block area
        line area
            inline area
                glyph area

    A glyph area is an inline area, so this may reduce to the following depending on context:

        block area
        line area
            glyph area

    Thus, glyph areas are always descendants of a line area, and may have an intervening inline area or even an inline-block and inline area between the glyph area and the ancestor line area.

    Note that XSL-FO classifies a line area as a special type of block area.

  2. r12a commented on Jan 26, 2017

    @r12a
    r12a
    on Jan 26, 2017
    Author

    [my response]

    So is it equivalent to a character? grapheme cluster? font glyph? something else? I'm trying to figure out what we're counting when looking for N.

  3. r12a commented on Jan 26, 2017

    @r12a
    r12a
    on Jan 26, 2017
    Author

    [response from Nigel]

    "Glyph area" itself is a term widely used in the spec, though there is no
    definition for it, since it is an XSL-FO concept - see
    https://www.w3.org/TR/2006/REC-xsl11-20061205/#d0e723

    I see that for Ruby there are two classes of glyph area, spacing ones and
    non-spacing ones. Maybe it would also be an improvement to be explicit and
    say "the number of non-spacing glyph areas that are descendants of these
    inline areas" where that applies.

    So is it equivalent to a character? grapheme cluster? font glyph? something else? I'm trying to figure out what we're counting when looking for N.

    Looking at the fact that non-spacing glyphs are omitted from counting,
    that effectively leaves the other glyphs, or I suppose grapheme cluster
    would be equivalent, since for counting purposes it is irrelevant whether
    you include the non-spacing glyph areas or not, and the non-spacing ones
    would be combined into the same grapheme cluster.

    In other words, "a" and "á" would both count as 1 whether you count the
    grapheme clusters or the spacing glyph areas. If you were to count all
    the glyph areas then "a" would be 1 and "á" would be 2.

    We haven't discussed it but I assume the spec text for ruby is based on
    the glyph area counts rather than the other concepts you mention, since it
    is directly concerned with how the glyphs should be laid out.

  4. r12a commented on Jan 26, 2017

    @r12a
    r12a
    on Jan 26, 2017
    Author

    [from here, discussion is moved to this issue]

    10.2.34 tts:rubyAlign
    https://www.w3.org/TR/2016/WD-ttml2-20161117/#style-attribute-rubyAlign

    Let IR and IB be, respectively, the inline areas generated by (1) a ruby text container or ruby text annotation and (2) an associated ruby base container or ruby base. Further, let NR and NB, be, respectively, the number of glyph area descendants of these inline areas.

    If the value of this attribute is auto, then if NR equals NB, the semantics of withBase apply; otherwise, if NR is less than NB, the semantics of spaceAround or spaceBetween apply, respectively, according to whether NB is less than or equal to one (1) or is greater than one; otherwise (NR is greater than NB), the semantics of center apply.

    I'm not sure how this works for the following cases:

    1. the ruby annotation contains the text 'píng'. How many glyph areas is that? What if the annotation is 'píng píng'?
    2. the ruby annotation contains hindi text with conjuncts. Is the conjunct + vowel sign one glyph area? (Conjuncts may or may not be equivalent to grapheme clusters.)
    3. the ruby annotation contains arabic text with the ligature lam-alif, composed of two font glyphs. Is this one glyph area or two?
    4. the ruby annotation contains any arabic text, which is mostly joined up consonants. How many glyph areas is that?
  5. r12a
    added
    i18n-needs-resolutionIssue the Internationalization Group has raised and looks for a response on.
    on Jan 26, 2017
  6. skynavga
    added
    question
    on Jan 26, 2017

  7. skynavga commented on Jan 26, 2017

    @skynavga
    skynavga
    on Jan 26, 2017
    Collaborator

    The term glyph area is operationally defined by XSL-FO. The terms spacing and non-spacing are terms of art from the Unicode Standard, see, e.g., combining character, also used font specifications, e.g., OpenType Font.

    As presently specified, the definition of glyph area is effectively implementation dependent. That may not be the best we can do, however, so let's consider where it is necessary to improve this.

    First, in the context of Japanese text, this isn't a practical problem; however, in the general case, I agree it could be, as some of your examples demonstrate.

    1. the ruby annotation contains the text 'píng'. How many glyph areas is that? What if the annotation is 'píng píng'?

    4 and 9, respectively

    1. the ruby annotation contains hindi text with conjuncts. Is the conjunct + vowel sign one glyph area? (Conjuncts may or may not be equivalent to grapheme clusters.)

    a reasonable implementation would likely map a single grapheme cluster to a single glyph area for the purpose of counting ruby in this context

    1. the ruby annotation contains arabic text with the ligature lam-alif, composed of two font glyphs. Is this one glyph area or two?

    a reasonable implementation would likely include all joined glyphs including any non-spacing marks that apply to them into a single glyph area for the purpose of counting ruby in this context; in other words, it would like extremely strange to separate otherwise joined glyphs or component glyphs

    1. the ruby annotation contains any arabic text, which is mostly joined up consonants. How many glyph areas is that?

    see above

  8. skynavga
    modified the milestone: on Feb 23, 2017
  9. skynavga
    self-assigned this
    on Apr 20, 2017
  10. skynavga
    assigned
    skynavga
    and unassigned
    skynavga
    on May 11, 2017
  11. skynavga
    added a commit that references this issue on May 16, 2017

    Add and use glyph area term; change glyph area descendant elaboration…

    3e4ee77

  12. skynavga commented on May 16, 2017

    @skynavga
    skynavga
    on May 16, 2017
    Collaborator

    Merge editorial clarifications/elaborations from PR #314.

  13. skynavga
    closed this as completedon May 16, 2017

  14. 17 remaining items

  15. skynavga
    removed
    agenda
    on Jan 10, 2018

  16. css-meeting-bot commented on Jan 10, 2018

    @css-meeting-bot
    css-meeting-bot
    on Jan 10, 2018
    Member

    The Working Group just discussed Meaning of 'glyph area descendant' ttml2#236.

    The full IRC log of that discussion <nigel> Topic: Meaning of 'glyph area descendant' ttml2#236
    <nigel> github: https://github.com//issues/236
    <nigel> Nigel: On reviewing this, it appears that there is work to do.
    <nigel> Glenn: I missed that - I will tag it for my priority.
  17. skynavga
    added this to the milestone on Jan 10, 2018
  18. skynavga
    assigned
    skynavga
    and unassigned
    nigelmegitt
    on Jan 10, 2018
  19. skynavga
    added a commit that references this issue on Jan 14, 2018

    Add tts:rubyAlign withBase as at risk (in placeholder status); add gl…

    3c97c68
  20. skynavga
    added
    pr open
    and removed
    editor priority
    on Jan 14, 2018
  21. skynavga
    closed this as completedin #553on Jan 16, 2018
  22. skynavga
    added a commit that references this issue on Jan 16, 2018

    Merge pull request #553 from w3c/issue-0236-glyph-descendant-misc

    c4d0886
  23. skynavga
    removed their assignment
    on Jan 16, 2018
  24. skynavga
    added
    WR-resolved
    WR-commenter-agreed
    and removed
    WR-spec-updated
    pr open
    on Jan 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    WR-commenter-agreedWR-resolveddiscussed and agreedi18n-needs-resolutionIssue the Internationalization Group has raised and looks for a response on.pr merged

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions