Variation of Fixed has not been defined about colr-gradients-spec HOT 17 CLOSED

To me, we should make it clear in one place, that Fixed, F2DOT14, etc, variations are added by interpretting those as integer values.

from colr-gradients-spec.

You mean, treating the F2Dot14 like a 16-bit integer, and treating the Fixed like a 32-bit integer?

For F2Dot14, that what I would do. (Equivalent interpretation: the scaled deltas are signed numerators of 1/16384ths added to the F2Dot14.)

For Fixed, it would mean that the scaled deltas are treated like signed numerators of 1/65536ths, with the largest possible deltas being ±1/2. A question to consider is whether that limit in delta size would always be adequate.

from colr-gradients-spec.

You mean, treating the F2Dot14 like a 16-bit integer, and treating the Fixed like a 32-bit integer?

Yes.

For Fixed, it would mean that the scaled deltas are treated like signed numerators of 1/65536ths, with the largest possible deltas being ±1/2. A question to consider is whether that limit in delta size would always be adequate.

Interesting. Having to vary 32bit numbers wasn't a requirement before, so ItemVariationStore doesn't support it. I suggest we address that in ItemVariationStore. Where do we need to vary Fixed again? And yes, I suggest we address that in ItemVariationStore now even if not needed immediately. I'll think about it. Let me know if you file an issue for that somewhere and I'll suggest my change there.

from colr-gradients-spec.

That's exactly the point wrt Fixed: it's 32-bit, but deltas have only ever needed to be 16-bit.

In the doc I linked to above, I mentioned some possible options:

• Variation deltas are applied only to the integer portion of a Fixed value.
• Variation deltas are applied only to the fractional portion.
• Add an additional member to VarFixed that is a static coefficient applied to the deltas, which are then interpreted as signed numerators of 1/65536ths.
• Extend the VarFixed struct to have two pairs of var store indices.
• Cut VarFixed: the Affine2x2 matrix elements are not variable.

Another possibility would be to add an ItemVariationStore enhancement—e.g., a format 2 to accommodate 32-bit deltas that could be used alongside format 1 (i.e., use format 2 if 32-bit deltas are needed, else use format 1); or a format 2 that can include both 16-bit and 32-bit deltas.

Yet another possibility might be to change the design of the Affine2By2 structure: instead of using VarFixed structures for each matrix element, use Fixed for the matrix elements and have some separate structures, perhaps an array of records that identify the matrix element to which they apply (so only elements that vary need a record) and a pair of indices that reference separate deltas for the int and frac portions of the Fixed matrix element.

Or another possibility: instead of Fixed for the matrix elements, use a 16-bit fractional type (maybe F2Dot14), if that might be adequate.

I haven't done a survey of where Fixed values are used to get a sense of how likely it is we might later want other Fixed values to be variable. If there are other places it might be useful, we should come up with a solution that would likely make sense for other contexts. But if PaintFormat3 seems like a rare exception, we can do what's economical for this case.

Let me know if you file an issue for that somewhere and I'll suggest my change there.

For now, this is the issue I filed for this, so I'd continue discussing proposals here.

from colr-gradients-spec.

+1 to first class support in ItemVariationStore. I can all too easily imagine a conversation of the form "I want a VarFixed for ... oh but we crippled it when did COLR" ... and an "I told you so" from Behdad :D

from colr-gradients-spec.

Searching across all of OT, it appears that use of Fixed values is pretty limited:

• some table version fields
• some CFF(2) charstring operators take a Fixed operand
• post.italicAngle
• fvar: axis min, default and max values, and coordinates for named instances
• STAT: axis values

The only thing that, conceptually, one might consider being variable is post.italicAngle.

from colr-gradients-spec.

So seems like your bringing up this was speculative. The reason I didn't deem 32bit variations necessary was that spatial values in OT are all 16bit.

italicAngle is non-issue since is superseded by slnt tag.

So, as of now we don't know any uses of such change? If that's correct, I suggest closing non-issue.

from colr-gradients-spec.

Huh?

The spec you and Dominik provided included variation of Fixed values, VarFixed, in the Affine2By2 struct in PaintFormat3. But combination of variation deltas with Fixed values is as yet undefined. That is not speculative; it's a blocking issue for the current draft of COLR v1. I've suggested several alternative possibilities, without preference to any of them.

from colr-gradients-spec.

Ah, lemme check. Thanks.

from colr-gradients-spec.

Yeah, agree, Affine needs full variation. Let me come up with my recommended change.

from colr-gradients-spec.

And thanks for spotting this.

from colr-gradients-spec.

Here's my proposal for supporting 32bit variations in ItemVariationStore. To quote the relevant parts from [0]:

ItemVariationData subtable:
Type | Name | Description
-- | -- | --
uint16 | itemCount | The number of delta sets for distinct items.
uint16 | shortDeltaCount | The number of deltas in each delta set that use a 16-bit representation. Must be less than or equal to regionIndexCount.
uint16 | regionIndexCount | The number of variation regions referenced.
uint16 | regionIndexes[regionIndexCount] | Array of indices into the variation region list for the regions referenced by this item variation data table.
DeltaSet | deltaSets[itemCount] | Delta-set rows.

Change uint16 shortDeltaCount such that if the top bit is 1, then the delta-set rows switch to being 32bit+16bit numbers instead of the current 16bit+8bit numbers.

Since current spec already says that shortDeltaCount must be less than or equal to regionIndexCount, and no font can reasonably be having regionIndexCount >= 32k, it follows that any tables using the proposed new feature will be considered invalid with older implementation, which is a desirable feature.

[0] https://docs.microsoft.com/en-us/typography/opentype/spec/otvarcommonformats#item-variation-store

from colr-gradients-spec.

That seems like a nice solution.

For any font tools, it suggests a validation check: don't allow >= 32K regions.

And it suggests there should be a constraint added to VariationRegionList.regionCount: "must be less than 32,768". If COLRv1 were added to OT 1.9 and if there were an OT1.8.4 preceding that, then I think this constraint should be added right away to 1.8.4. I've opened MicrosoftDocs/typography-issues#560 to track this change request for the OT spec.

from colr-gradients-spec.

I think this can be closed. (Re-open if any concerns arise.)

from colr-gradients-spec.

The name "shortDeltaCount" was based on the representation using a mix of int16s—the "shorts"—and int8s. But with the high bit set, the "shorts" are really "longs". So, "shortDeltaCount" doesn't seem to be a good generic name to cover both cases.

Related: I have in mind to describe this as a packed value comprised of a flag and a count value, and I'll give masks for the two elements symbolic names. Something like the following:

Mask	Name	Description
0x8000	LONG_WORDS	Flag indicating that “word” deltas are long (int32)
0x7FFF	WORD_DELTA_COUNT_MASK	Count of “word” deltas

The representation of delta values uses a mix of long types (“words”) and short types. If the LONG_WORDS flag is set, deltas are represented using a mix of int32 and int16 values. This representation is only used for deltas that are to be applied to data items of Fixed or 32-bit integer types. If the flag is not set, deltas are presented using a mix of int16 and int8 values. See the description of the DeltaSet record below for additional details.

The count value indicated by WORD_DELTA_COUNT_MASK is a count of the number of deltas that use the long (“word”) representation, and must be less than or equal to regionIndexCount.

...

DeltaSet record:

Type	Name	Description
int16 and int8 or int32 and int16	deltaData[regionIndexCount]	Variation delta values

Logically, each DeltaSet record has regionIndexCount number of elements. The elements are represented using long and short types, as described above. These are either int16 and int8, or int32 and int16, according to whether the LONG_WORDS flag was set. The delta array has a sequence of deltas using the long type followed by sequence of deltas using the short type. The count of deltas using the long type is derived using WORD_DELTA_COUNT_MASK. The remaining elements use the short type. The length of the data for each row, in bytes, is regionIndexCount + (wordDeltaCount && WORD_DELTA_COUNT_MASK) if the LONG_WORDS flag is not set, or 2 x that amount if the flag is set.

(An alternative to LONG_WORDS could be DWORD_DELTAS.) With those names, the above field could be named "wordDeltaCount".

But I don't know if that is too contrary to typical use of "word" in relation to integer types. I'm entirely open to suggestions here.

from colr-gradients-spec.

Whatever works. Flag looks fine to me. I personally don't see any problem with calling this field shortDeltaCount where the flag will specify when flag enabled this is number of longs.

from colr-gradients-spec.

@PeterConstable can you proceed with whichever language you think fits the spec best? - no objection to either wordDeltaCount or shortDeltaCount.

I will optimistically assume yes and close, but please reopen if not.

from colr-gradients-spec.