Implement Test for Conformance Requirement: url-templates

[garretrieger]

Link to requirement: https://w3c.github.io/IFT/Overview.html#url-templates

[yChenMonotype]

Hi @garretrieger,

I have trouble creating a test when modifying patch map url_template from byteArray [128, 7, '.', 'i', 't', 'f', '', 't', 'k'] to [8, 'p', 'a', 't', 'c', 'h', 'e', 's', '/', 128, 7, '.', 'i', 't', 'f', '', 't', 'k']. After url_template is updated, entries and entryIDs offsets are recalculated to accommodate the new url_template, see https://github.com/w3c/ift-client-tests/blob/url-templates/generators/testCaseGeneratorLib/utils.py#L45.

here is the test generation:
https://github.com/w3c/ift-client-tests/blob/url-templates/generators/ClientTestCaseGenerator.py#L427

The idea is to move the .ift_tk patches from the same directory as the based ift font to it's patches directory and the JS should be able to download and apply the patches accordingly.

In the browser, the .ift_tk patches are successfully downloaded, however there was an error from wasm when trying to apply the patch.

Browser confirms that patch is downloaded successfully:

Her is the error from the JS/WASM:

[garretrieger]

I suspect what is happening here is that the table keyed patch contains binary diff against the "IFT " (or "IFTX") table which is invalidated as a result of the URL template changing length. Then when the patch is applied it corrupts the IFT/IFTX table since the bytes of the table have shifted around from what the patch is expecting.

There's a few possible ways forward that come to mind:

• Option 1: add an option to the encoder to force patch generation to not use delta's (ie. perform a full replacement of the source table). This would make the table keyed patches independent of the contents of the IFT/IFTX table.
• Option 2: add an option to the encoder to set the specific URL template to use. Then you could generate a test font and associated patches with the URL template of whatever length and contents as needed.
• Option 3: manually replace the binary diff for the IFT/IFTX in the table keyed patch(es) with one that corrects the patch relative to the changed IFT/IFTX table.

Depending on what you're looking to accomplish I think option 1 or 2 would be reasonable, the encoder changes should be straightforward. Option 3 is probably difficult/complex to do correctly so probably not recommended.

I'm thinking option 2 is probably the best as that will give flexibility to set up the URL template however you need to and maintain the overall correctness of the patches. Let me know if that sounds good and I can make the encoder changes needed to support this.

[yChenMonotype]

Thank you @garretrieger, option 2 sounds great! It makes sense to set URL template in the encoding process instead of modifying IFT/IFTX table binary.

[garretrieger]

I've made the change in ift-encoder (w3c/ift-encoder#209) and pulled that into this repo (#42)

In the segmentation plan (https://github.com/w3c/ift-encoder/blob/main/ift/config/segmentation_plan.proto#L175) there's now an optional setting which can be used to set the url template prefix.

To use the setting in this repo, you can either modify the segmentation plan config file that's generated during test preparation or you can modify the base_segmentation_plan section of https://github.com/w3c/ift-client-tests/blob/main/encoder/config/segmentation_config.txtpb#L12 to add the setting. The base_segmentation plan settings are transferred to the generated segmentation plan config file.