[OpenType] Coverage table format 2 text -- DNB

[Bob Hallissy]

> On 2010-06-09  at 18:49  Eric Muller wrote:
>
Thanks, Eric, for taking time to reply. I hope others will also chime in 
at some point.

> Remember that the coverage index is used to index in tables, so it must
> be in the range [0..nb_covered_glyphs -1].
Ok, I can agree with that.

> The field coverageIndex is
> just a "cached" value, namely the number of glyphs covered by the
> previous ranges.
Other than the sentence I originally quoted (from which one might deduce 
that the field is intended as a cache, but it certainly isn't explicit), 
is it said somewhere that the StartCoverageIndex (SCI) field is simply a 
cache?

> Since ranges are ordered, you can binary search for the
> range of interest, and the cached value saves you the visit to each
> previous range (which the search may not have visited).
I agree this is a reason to have SCI in each range.

> The spec could be improved by changing the text you quote to something
> like: "The StartCoverageIndex of a range must be the number of glyphs
> covered by the preceding ranges (and therefore 0 for the first range)"
Yes that would make it clearly state what you are suggesting. But I'm 
wondering if requiring ascending SCI was really the intent of the spec?

In any case, why would this constraint be necessary? Any implementation 
worth its salt would, as you suggest, do a binary search on the ranges 
and then depend on the SCI value in the located range record. Thus 
following set of ranges, for example, satisfy the requirement that the 
coverage indices be in the range [0..nb_covered_glyphs-1]:

start:  10
end:    10
SCI:     2

start:  20
end:    21
SCI:     0

but they are clearly not in ascending SCI order.

I'm not trying to be difficult. We agree that the spec wording could be 
improved -- just that I would propose to eliminate the confusing sentence:

> The Coverage Indexes for the first range begin with zero (0), and the 
> Start Coverage Indexes for each succeeding range are determined by 
> adding the length of the preceding range (End GlyphID - Start GlyphID 
> + 1) to the array Index. 

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100610/f6d4d564/attachment.html>