Please add a test case for https://github.com/googlei18n/noto-fonts/issues/770

Make a test case for Kannada shaping with ZWJ. harfbuzz/harfbuzz#341 has sample strings.

Please add test case for https://github.com/googlei18n/noto-fonts/issues/793

I've been working on hooking up some recent variable fonts work to the test suite and noticed that several of the test fonts used for variable font tests are lacking a STAT table. However, the OpenType spec says:

Two tables are required in all variable fonts:

• A font variations ('fvar') table is required to describe the variations supported by the font.
• A style attributes (STAT) table is required and is used to establish relationships between different fonts belonging to a family and to provide some degree of compatibility with legacy applications by allowing platforms to project variation instances involving many axes into older font-family models that assume a limited set of axes.

I imagine this is not a major issue since it's perfectly possible to apply variations without a STAT table but figured it was worth mentioning.

Examples include:

• fonts/TestGVAROne.ttf
• fonts/TestGVARTwo.ttf
• fonts/TestGVARThree.ttf

I just fixed a bug in opentype.js that could make for a new test case, see opentypejs/opentype.js#633
The CFF endchar command supports a compatibility to the Type 1 seac command in order to implement standard encoding accented characters. This seems to also affect fontkit and it would help to be caught for other parsers/renderers as well.

Apple core text engine has issues with Kannada words with double/triple/multiple u+0ccd (ZERO WIDTH JOINER), meaning base letter ending with u+0ccd and one or many half-forms with it forced by multiple u+0ccd.

Open the below weblinks in SAFARI on mac, and chrome on mac to see the difference.

search word ದಟ್ಸ್
in below link which uses Tunga Webfont:
http://kannada.oneindia.com/amphtml/news/2009/04/19/karnataka-muslim-sangharsha-samiti-to-support-bjp.html

Search words in
ಎಕ್ಸ್ , ಮಾರ್ಚ್, ಟೆಕ್ಸ್ಟ್, ಬುಕ್ಸ್, ಸಾಫ್ಟ್, ಜಸ್ಟ್
in below link which uses Tunga Webfont:
http://kannada.oneindia.com/news/bangalore/e-kannada-exhibition-conversation-kannada-online-expo-ravindra-kalakshetra-114263.html

When testing fontkit on the Travis continuous integration system, the wrapper script gives a Syntax error. Perhaps @devongovett knows how to fix this? Do we need to use a specific version of Node.js? See here for how to specify a Node.js version in .travis.yml files.

https://travis-ci.org/unicode-org/text-rendering-tests/jobs/227862426#L566

/home/travis/build/unicode-org/text-rendering-tests/src/third_party/fontkit/render:3
let fontkit = require('fontkit');
    ^^^^^^^
SyntaxError: Unexpected identifier
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:929:3

Please look at this below issue. Please add a test case for this.

https://github.com/googlefonts/noto-fonts/issues/1615

There’s now a freshly registered Vendor ID UNIC for the Unicode Consortium. For test fonts that were specially built for this test suite, change the font vendor ID to UNIC.

ಜಿ಼ೕಬೆನ್

the above is discontinuous with coretext but correct in harfbuzz

I believe the variable assigned on this line should be of type SBInteger rather than SBUInteger since it can receive a negative value:

With Macintosh and AAT-specific cases removed.

@brawer Hello Sascha,

There seems two modes or type of Text engine in MacOS and iOS.

1. Notes app, Twitter -new tweet window, youtube comment window
2. Pages, emails, twitter- view tweet, youtube-comment view

First type has a lot of issues. How to test them separately?

Why is the difference?

I can give some sample text and show the difference, if it helps understanding this better.

For example:

• composite glyphs with nested components (components that are themselves composite glyphs),
• composite glyphs with attachment points (components where bit ARGS_ARE_XY_VALUES is set),
• composite glyphs with transformed components (components where one of the bits WE_HAVE_A_SCALE, WE_HAVE_AN_X_AND_Y_SCALE or WE_HAVE_A_TWO_BY_TWO is set).

@jenskutilek, would you be OK contributing your cvar test font from fonttools/fonttools#1113 (comment) to Unicode’s test suite for text rendering? Ideally you could send a pull request for adding a font TestCVAROne.ttf to the test fonts directory. The font can be a small subset (just the o and n glyphs would be enough). I’d then add a test case around your font. By contributing your test font, you’d help to make sure that all implementations correctly handle cvar tables.

CoreText sometimes re-orders path outlines. We should accept this kind of re-ordering difference between the expected (red) and observed (green) path. Need to figure out some algorithm.

For example, here’s test case AVAR-1/400 for CoreText running on macOS 10.12 Sierra. The difference of up to 1 font design unit in descender (in viewBox) is already recognized as harmless; the question is how to recognize the equivalent path geometries.

-<svg version="1.1" viewBox="0 -199 960 1199">
+<svg version="1.1" viewBox="0 -200 960 1200">
   <symbol id="AVAR-1/400.gid1" overflow="visible">
     <path d="
-      M 480,-100
-      Q 371,-100 279,-46
+      M 279,-46
       Q 188,8 134,100
       Q 80,192 80,301
       Q 80,409 134,501
       Q 188,593 279,646
       Q 371,700 480,700
       Q 588,700 680,646
       Q 772,592 826,500
       Q 880,409 880,301
       Q 880,192 826,100
       Q 772,8 680,-46
       Q 588,-100 480,-100
+      Q 371,-100 279,-46
       Z
-
-      M 480,-15
-      Q 565,-15 637,27
-      Q 710,70 752,142
+      
+      M 637,27
+      Q 710,70 752,142
       Q 795,215 795,301
       Q 795,386 752,458
       Q 710,530 637,572
       Q 565,615 480,615
       Q 394,615 322,572
       Q 250,530 207,458
       Q 165,386 165,301
       Q 165,215 207,142
       Q 250,70 322,27
       Q 394,-15 480,-15
+      Q 565,-15 637,27
       Z

       M 707,342
       L 707,257
       L 253,257
       L 253,342
       Z

       M 523,73
       L 438,73
       L 437,527
       L 523,527
       Z
     " />
   </symbol>
   <use x="0" y="0" xlink:href="#AVAR-1/400.gid1" />
 </svg>

Just for reference, in 2014, I originally formulated a proposal for an "SFNTQA" test suite for OpenType fonts, and I’ve posted that proposal in December 2015 on the fontTools repo:
fonttools/fonttools#416

This repo has a slightly different, but related goal, so I’m just cross-linking that issue here.

Emoji has become very popular and contains a variety of font formats.

Sell also: https://www.colorfonts.wtf/

ಜಿ಼ೕಬೆನ್

This word is broken in coretext. Correct in harfbuzz

Apple core text and Microsoft 10 doesn't remove the dotted circle from diacritics with combination of non-breaking space(\u00A0).

Although harfbuzz removes the dotted circle (\u25CC) from diacritics. Harfbuzz leaves a space in place of the dotted circle (\u25CC)

್
ಾ
ಿ
ೀ
ು
ೂ
ೆ
ೇ
ೈ
ೊ
ೋ
ೌ
ಂ
ಃ
ಁ
ೃ
ೄ
ೕ
ೢ
ೣ
಼

ಜಾ಼ಕಿರ್
This word is incorrect in harfbuzz and noto serif Kannada,
but correct in coretext and noto sans Kannada!

https://github.com/googlei18n/noto-fonts/issues/769#issuecomment-254315022 has test cases for Myanmar shaping. Before making adding them as test cases, we need to triple-check that these are actually Unicode strings and not in Zawgyi encoding.

အကျွန်ုပ်သည်
သွားလတံ္တနည်း
သဗ္ဗာသဝသုတ်
အကျွန်ုပ်သည်
သာဝတ္ထိ
ဤသို့
မြတ်စွာဘုရားသည်
သွားလတံ္တနည်း

Given the input string "A\nB", the Tehreer stack will crash when creating the second line of the run. The fix is to pass the paragraph starting offset to SBParagraphCreateLine(...) here:

The fix should look like this:

SBLineRef line = SBParagraphCreateLine(paragraph, paraStart, paraLen);

Can we include adobe world-ready composer for testing?

I think it would be valuable if the text rendering reports had information about the specific version of the OS (in the case of CoreText) or the libraries (in the case of FreeStack) that were used when the report was generated. For the FreeStack it may be necessary to reference a specific commit hash, in case a new build of a given library wasn't available at the time.

The data of this table is:

+0000 │ 00 01 00 03 00 0E 00 00 00 00 00 00 00 00 00 02 00 01 00 01 00 03 00 01

It looks like pointers for markGlyphSetsDefOffset and itemVarStoreOffset are missing.

Hello, I work on Allsorts, which is a font parsing and shaping engine implemented in Rust. Earlier this year I undertook the work to make is possible for execute this test suite against Allsorts via our allsorts-tools binary. The test suite helped guide my implementation of glyph positioning and contour extraction, which were included in the recent 0.6 release. We don't yet support morx or variable fonts so a lot of the tests still fail but for the things we do support, they generally pass.

I'm opening this issue to discuss the possibility of incorporating Allsorts into the test suite. I have a commit that adds Allsorts as an engine but I'm not sure how to go about integrating it like the other supported engines—suggestions welcome.

The master branch of FreeType can now parse CFF2, which can be used to generate test cases.

u+0ca1,u+0ccb,u+0c82 combination has issue with core text engine.

Apple core text engine has trouble rendering above combination.
Open the below weblinks in Safari in mac.
Same websites in google chrome (harfbuzz) in mac shows no issue rendering this text.

Search 'ಡೋಂಗಿ' in below website

Tunga webfont:
http://kannada.oneindia.com/amphtml/news/2009/04/19/karnataka-muslim-sangharsha-samiti-to-support-bjp.html

Tunga webfont:
http://www.kannadaprabha.com/karnataka/fake-baba-cheats-youth-over-woman-fascination-in-mysuru/285796.html

Google Noto Sans-Kannada webfont:
http://www.prajavani.net/news/article/2016/10/03/442512.html

No Webfont:
http://vijaykarnataka.indiatimes.com/topics/ಬಿಜೆಪಿಯ-ಡೋಂಗಿ-ಹಿಂದುತ್ವ-ಬಯಲು

It has same problem with all consonants.

ಕೋಂ ಖೋಂ ಗೋಂ ಘೋಂ ಙೋಂ ಚೋಂ ಛೋಂ ಜೋಂ ಝೋಂ ಞೋಂ ಟೋಂ ಠೋಂ ಡೋಂ ಢೋಂ ಣೋಂ ತೋಂ ಥೋಂ ದೋಂ ಧೋಂ ನೋಂ ಪೋಂ ಫೋಂ ಬೋಂ ಭೋಂ ಮೋಂ ಯೋಂ ರೋಂ ಱೋಂ ಲೋಂ ವೋಂ ಶೋಂ ಷೋಂ ಸೋಂ ಹೋಂ ಳೋಂ ೞೋಂ

At https://raw.githack.com/icu-project/text-rendering-tests/master/reports/FreeStack.html , SVG 'glyphs/images' in 'Expected' and 'Observed' lines are vertically misaligned and only partially shown.
(observed with Firefox 49 on Ubuntu).

This may as well be a Firefox issue and coming up with a work-around should be a very low priority. Just reporting as an FYI item.

Make a test case for this problem: w3c/alreq#147

https://github.com/unicode-org/text-rendering-tests/blob/master/fonts/Selawik-README.md does not explain how the hinting is activated on MacOS, but this is one of the key aspects of the test font. I hope @robmck-ms can update it to explain this :)

Please consider adding IVS Test Version 1.001, which includes nearly 40 million UVSes (Unicode Variation Sequences) in its Format 14 'cmap' subtable, and whose installable OpenType/CFF font is available for download on the Latest Release page. The font resource is huge, nearly 200MB, due to the size of the 'cmap' table, which is one of the reasons for making it available on the "Latest Release" page. I would have otherwise needed to ZIP it to bring it under GitHub's 100MB limit. Its UVS definition file needed to be ZIPped and split.

There are no test cases for these two fonts:
TestGVAR-Composite-0.ttf
TestGVAR-Composite-Missing.ttf

Is a glyph composed of components supposed to render the components in their transformed variant if the glyph itself is not targeted in the gvar table, or not?

For test case SHARAN-1, the test suite reports a test failure for CoreText on macOS 10.14 but the rendered path looks fine. For example, the first path in the test expectation, which was generated by HarfBuzz and FreeType, has the following delta to CoreText; note that the final moveto in the test expecation is a no-op because it is immediately followed by closepath.

--- expected
+++ CoreText
@@ -1,2 +1 @@
-<path d="M-86,203 L-86,211 Q-74,230 -43,265 Q-12,299 0,307 L8,307 Q46,283 66,263 Q86,243 86,223 Q86,187 4,128 L-4,128 Q-46,171 -86,203 Z M0,217 Z" />
-
+<path d="M-86,203 L-86,211 Q-74,230 -43,265 Q-12,299 0,307 L8,307 Q46,283 66,263 Q86,243 86,223 Q86,187 4,128 L-4,128 Q-46,171 -86,203 Z" />

To fix, we probably should change the test runner to filter out empty sub-paths.

"ಆ್ಯಕ್ಷಿಸ್‌"

Failed in Apple Core Text
Passed in Windows IE, EDGE
Passed in Chrome

Eg: "ಆ್ಯಕ್ಷಿಸ್‌" in this popular Kannada newspaper
http://www.prajavani.net/news/article/2017/03/09/476699.html
This website uses "Google Noto Sans Kannada" webfont.

Chrome

Edge

Safari

Apple bugtracker: 30948070

CMAP-3 says:

The font for this test case contains a ‘cmap’ table of format 0, platform 1, encoding 0, language 18. Platform 1 means the classic Macintosh up to MacOS 9; the combination of encoding 0 and language 18 indicates the MacOS Turkish character encoding.

According to the docs language id 18 is Croation, not Turkish as indicated:

Inspecting the font with ttx confirms that it is using language id 18 as well:

<cmap_format_0 platformID="1" platEncID="0" language="18">

A few folks and myself have recently been working on getting Font.js uplifted to ES2020 and browser+node compatibility, but it's hard to come by dedicated fonts for testing things like detecting the correct number of GPOS/GSUB script/feature/lookups, ligature resolution, non cmap-4/12 character support, fvar, etc.

Is there a subset of this battery of fonts that might work well for the purpose of not specifically text rendering, but certainly doing everything up to the shaping step?

... like we are doing with all of the unicode-org repos

tnx!

This is a test font for Illustrator bugs, it contains only h n o, all of which are broken in some way in Illustrator. I think it is because of the IUP mechanism, but I'm not sure if that explains everything. The outlines are buggy and the spacing is also off.

VotoSerifGX-IUP-gvar.zip

As your great work on providing morx test cases, I wonder if it is possible to have some tests for trak also? The list of fonts providing it are listed here. Some kerx ones also would be nice.

The second test in "GPOS–2: Coverage in Pair Adjustment Positioning" is not a valid test. It checks if a renderer picks the first of two equally matching sets:

"The second subtable has two PairSets, both kerning .."

but in the associated font "TestGPOSTwo.otf", the value of PairSetCount (2) is not equal to the length of its Coverage list (1). This is not correct according to the OpenType specifications for GPOS Pair Adjustment, PosFormat 1:

"The PairSet array contains one offset for each glyph listed in the Coverage table and uses the same order as the Coverage Index."

so the PairSetCount should have been 1 as well (and then there is nothing to test against left). Testing with a technically invalid font may lead to undefined behavior, and the offered scenario is not unique in this – all other tests would suffer the same fate if their fonts are invalid.

I recommend this test be removed from the test suite.

SVG fonts were added a while ago via #56, but there are actually no tests for SVG font rendering in the test suite.
Opentype.js may soon have parsing and writing support for them (opentypejs/opentype.js#672) and I'd like to try to implement the rendering, so it would be great to have tests for that.

This was reported to HarfBuzz, harfbuzz/harfbuzz#2098, but the following fonts don’t seem to be used in any of the test cases (or anywhere in the repository):

fonts/TestRVRN-CFF2.otf
fonts/TestRVRN.ttf
fonts/TestVRTR-CID-Regular.otf
fonts/TestVRTR-Regular.otf
fonts/TestVRTR-TTF-Regular.ttf
fonts/Selawik-variable.ttf
fonts/TestGVAR-Composite-0.ttf
fonts/TestGVAR-Composite-Missing.ttf
fonts/TestShapeKndaV3.ttf
fonts/TestTRAKOne.ttf

So the question is, what are these fonts for and if they are for tests are we (HarfBuzz) missing something to test them?