Re: ISSUE-406 + #lineBreak-uax14

I was not sufficiently clear in my description. Of course, the
#lineBreak-uax14 designator can be listed in a document defined profile
based on IMSC1 text profile as the base profile.

What I had apparently not understood was what was meant by "The Document
Instance shall conform to the following table:" in Sections 6.10, 7.4,  and
8.4. I presumed that by listing feature designators, you were specifying
whether the features so designated may be used in a document. In the case
of most features, there is a syntactic feature that corresponds to a
designator. However, that is not true for #lineBreak-uax14, which may be
used by an application to signal whether a particular algorithm is used or
not by the implementation, as opposed to whether a syntactic feature is
used in the document.

>From your question, it appears you may in addition consider the presence of
a designator in these sections as indicating whether a feature can be
required in a document specific profile over and above the use of an IMSC
profile.

This doesn't seem a legitimate requirement. If an application of IMSC1 also
wants to require an implementation to support a superset of IMSC1, then
they should be able to additional require features not required by IMSC1.

Furthermore, I wonder if the fact that absent a generic requirement for
UAX14 line break support, then there is no guarantee of reproducibility of
line breaks even given the same font metrics, same resolution, and same
region extents?

Given the focus on reproducible behavior, e.g., defining the use of
specific glyph metrics, I would expect that UAX14 be mandated by IMSC1.







On Mon, Sep 21, 2015 at 9:35 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Glenn,
>
> Couple of questions related to #lineBreak-uax14 and ISSUE-406 [1].
>
> - why can #lineBreak-uax14 only be signaled through a profile
> declaration and cannot be set through a ttp attribute?
>
> - what is the default value of #lineBreak-uax14 in absence of a
> profile declaration?
>
> Thanks,
>
> -- Pierre
>
> [1] http://www.w3.org/AudioVideo/TT/tracker/issues/406
>
>