googlefonts / gideon

Gideon fonts
SIL Open Font License 1.1
1 stars 2 forks source link

Google Font QA report #1

Open vv-monsalve opened 3 years ago

vv-monsalve commented 3 years ago

Fontbakery report

Fontbakery version: 0.7.37

[21] GideonProfessional-Roman.ttf
πŸ”₯ FAIL: Checking file is named canonically. * [com.google.fonts/check/canonical_filename](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/canonical_filename)
--- Rationale ---
A font's filename must be composed in the following manner:
<familyname>-<stylename>.ttf
- Nunito-Regular.ttf,
- Oswald-BoldItalic.ttf
Variable fonts must list the axis tags in alphabetical order in square brackets
and separated by commas:
- Roboto[wdth,wght].ttf
- Familyname-Italic[wght].ttf
* πŸ”₯ **FAIL** Style name used in "GideonProfessional-Roman.ttf" is not canonical. You should rebuild the font using any of the following style names: "Thin", "ExtraLight", "Light", "Regular", "Medium", "SemiBold", "Bold", "ExtraBold", "Black", "Thin Italic", "ExtraLight Italic", "Light Italic", "Italic", "Medium Italic", "SemiBold Italic", "Bold Italic", "ExtraBold Italic", "Black Italic". [code: bad-static-filename]
πŸ”₯ FAIL: Checking OS/2 fsType does not impose restrictions. * [com.google.fonts/check/fstype](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/fstype)
--- Rationale ---
The fsType in the OS/2 table is a legacy DRM-related field. Fonts in the Google
Fonts collection must have it set to zero (also known as "Installable
Embedding"). This setting indicates that the fonts can be embedded in documents
and permanently installed by applications on remote systems.
More detailed info is available at:
https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fstype
* πŸ”₯ **FAIL** In this font fsType is set to 8 meaning that: The font may be embedded but must only be installed temporarily on other systems. No such DRM restrictions can be enabled on the Google Fonts collection, so the fsType field must be set to zero (Installable Embedding) instead. [code: drm]
πŸ”₯ FAIL: Substitute copyright, registered and trademark symbols in name table entries. * [com.google.fonts/check/name/unwanted_chars](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/unwanted_chars) * πŸ”₯ **FAIL** NAMEID #0 contains symbols that should be replaced by '(c)'. [code: unwanted-chars] * πŸ”₯ **FAIL** NAMEID #0 contains symbols that should be replaced by '(c)'. [code: unwanted-chars]
πŸ”₯ FAIL: Is the Grid-fitting and Scan-conversion Procedure ('gasp') table set to optimize rendering? * [com.google.fonts/check/gasp](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/gasp)
--- Rationale ---
Traditionally version 0 'gasp' tables were set so that font sizes below 8 ppem
had no grid fitting but did have antialiasing. From 9-16 ppem, just grid
fitting. And fonts above 17ppem had both antialiasing and grid fitting toggled
on. The use of accelerated graphics cards and higher resolution screens make
this approach obsolete. Microsoft's DirectWrite pushed this even further with
much improved rendering built into the OS and apps.
In this scenario it makes sense to simply toggle all 4 flags ON for all font
sizes.
* πŸ”₯ **FAIL** Font is missing the 'gasp' table. Try exporting the font with autohinting enabled. If you are dealing with an unhinted font, it can be fixed by running the fonts through the command 'gftools fix-nonhinting' GFTools is available at https://pypi.org/project/gftools/ [code: lacks-gasp]
πŸ”₯ FAIL: Are there non-ASCII characters in ASCII-only NAME table entries? * [com.google.fonts/check/name/ascii_only_entries](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/ascii_only_entries)
--- Rationale ---
The OpenType spec requires ASCII for the POSTSCRIPT_NAME (nameID 6).
For COPYRIGHT_NOTICE (nameID 0) ASCII is required because that string should be
the same in CFF fonts which also have this requirement in the OpenType spec.
Note:
A common place where we find non-ASCII strings is on name table entries with
NameID > 18, which are expressly for localising the ASCII-only IDs into Hindi /
Arabic / etc.
* πŸ”₯ **FAIL** Bad string at [nameID 0, 'mac_roman']: 'b'©2009-2021 Robert E. Leuschke'' [code: bad-string] * πŸ”₯ **FAIL** Bad string at [nameID 0, 'utf_16_be']: 'b'©2009-2021 Robert E. Leuschke'' [code: bad-string] * πŸ”₯ **FAIL** There are 2 strings containing non-ASCII characters in the ASCII-only NAME table entries. [code: non-ascii-strings]
πŸ”₯ FAIL: Copyright notices match canonical pattern in fonts * [com.google.fonts/check/font_copyright](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/font_copyright) * πŸ”₯ **FAIL** Name Table entry: Copyright notices should match a pattern similar to: "Copyright 2019 The Familyname Project Authors (git url)" But instead we have got: "Β©2009-2021 Robert E. Leuschke" [code: bad-notice-format] * πŸ”₯ **FAIL** Name Table entry: Copyright notices should match a pattern similar to: "Copyright 2019 The Familyname Project Authors (git url)" But instead we have got: "Β©2009-2021 Robert E. Leuschke" [code: bad-notice-format]
πŸ”₯ FAIL: Check name table: FONT_SUBFAMILY_NAME entries. * [com.google.fonts/check/name/subfamilyname](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/subfamilyname) * πŸ”₯ **FAIL** SUBFAMILY_NAME for Mac "Roman" must be "" [code: bad-familyname]
πŸ”₯ FAIL: Font enables smart dropout control in "prep" table instructions? * [com.google.fonts/check/smart_dropout](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/smart_dropout)
--- Rationale ---
This setup is meant to ensure consistent rendering quality for fonts across all
devices (with different rendering/hinting capabilities).
Below is the snippet of instructions we expect to see in the fonts:
B8 01 FF    PUSHW 0x01FF
85          SCANCTRL (unconditinally turn on
                      dropout control mode)
B0 04       PUSHB 0x04
8D          SCANTYPE (enable smart dropout control)
"Smart dropout control" means activating rules 1, 2 and 5:
Rule 1: If a pixel's center falls within the glyph outline,
        that pixel is turned on.
Rule 2: If a contour falls exactly on a pixel's center,
        that pixel is turned on.
Rule 5: If a scan line between two adjacent pixel centers
        (either vertical or horizontal) is intersected
        by both an on-Transition contour and an off-Transition
        contour and neither of the pixels was already turned on
        by rules 1 and 2, turn on the pixel which is closer to
        the midpoint between the on-Transition contour and
        off-Transition contour. This is "Smart" dropout control.
For more detailed info (such as other rules not enabled in this snippet), please
refer to the TrueType Instruction Set documentation.
* πŸ”₯ **FAIL** The 'prep' table does not contain TrueType instructions enabling smart dropout control. To fix, export the font with autohinting enabled, or run ttfautohint on the font, or run the `gftools fix-nonhinting` script. [code: lacks-smart-dropout]
πŸ”₯ FAIL: Checking OS/2 usWinAscent & usWinDescent. * [com.google.fonts/check/family/win_ascent_and_descent](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/family/win_ascent_and_descent)
--- Rationale ---
A font's winAscent and winDescent values should be greater than the head table's
yMax, abs(yMin) values. If they are less than these values, clipping can occur
on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33).
If the font includes tall/deep writing systems such as Arabic or Devanagari, the
winAscent and winDescent can be greater than the yMax and abs(yMin) to
accommodate vowel marks.
When the win Metrics are significantly greater than the upm, the linespacing can
appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7
(Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This
means the font developer can control the linespacing with the typo values,
whilst avoiding clipping by setting the win values to values greater than the
yMax and abs(yMin).
* πŸ”₯ **FAIL** OS/2.usWinAscent value should be equal or greater than 3937, but got 3212 instead [code: ascent]
πŸ”₯ FAIL: Checking OS/2 Metrics match hhea Metrics. * [com.google.fonts/check/os2_metrics_match_hhea](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/os2_metrics_match_hhea)
--- Rationale ---
OS/2 and hhea vertical metric values should match. This will produce the same
linespacing on Mac, GNU+Linux and Windows.
- Mac OS X uses the hhea values.
- Windows uses OS/2 or Win, depending on the OS or fsSelection bit value.
When OS/2 and hhea vertical metrics match, the same linespacing results on
macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has
released many fonts with vertical metrics that don't match in this way. When we
fix this issue in these existing families, we will create a visible change in
line/paragraph layout for either Windows or macOS users, which will upset some
of them.
But we have a duty to fix broken stuff, and inconsistent paragraph layout is
unacceptably broken when it is possible to avoid it.
If users complain and prefer the old broken version, they have the freedom to
take care of their own situation.
* πŸ”₯ **FAIL** OS/2 sTypoDescender (-920) and hhea descent (-1600) must be equal. [code: descender]
πŸ”₯ FAIL: Space and non-breaking space have the same width? * [com.google.fonts/check/whitespace_widths](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/hmtx.html#com.google.fonts/check/whitespace_widths) * πŸ”₯ **FAIL** Space and non-breaking space have differing width: The space glyph named space is 1320 font units wide, non-breaking space named (uni00A0) is 1485 font units wide, and both should be positive and the same. GlyphsApp has "Sidebearing arithmetic" (https://glyphsapp.com/tutorials/spacing) which allows you to set the non-breaking space width to always equal the space width. [code: different-widths]
πŸ”₯ FAIL: Check glyphs do not have components which are themselves components. * [com.google.fonts/check/glyf_nested_components](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/glyf.html#com.google.fonts/check/glyf_nested_components)
--- Rationale ---
There have been bugs rendering variable fonts with nested components.
Additionally, some static fonts with nested components have been reported to
have rendering and printing issues.
For more info, see:
* https://github.com/googlefonts/fontbakery/issues/2961
* https://github.com/arrowtype/recursive/issues/412
* πŸ”₯ **FAIL** The following glyphs have components which themselves are component glyphs: * uni1EB6 * uni1EB6 * uni1EB2 * uni1EAC * uni1EAC * uni1EA8 * uni1EA0 * Amacron * Aringacute * AEacute and 113 more. [code: found-nested-components]
⚠ WARN: Checking OS/2 achVendID. * [com.google.fonts/check/vendor_id](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/vendor_id)
--- Rationale ---
Microsoft keeps a list of font vendors and their respective contact info. This
list is updated regularly and is indexed by a 4-char "Vendor ID" which is stored
in the achVendID field of the OS/2 table.
Registering your ID is not mandatory, but it is a good practice since some
applications may display the type designer / type foundry contact info on some
dialog and also because that info will be visible on Microsoft's website:
https://docs.microsoft.com/en-us/typography/vendors/
This check verifies whether or not a given font's vendor ID is registered in
that list or if it has some of the default values used by the most common font
editors.
Each new FontBakery release includes a cached copy of that list of vendor IDs.
If you registered recently, you're safe to ignore warnings emitted by this
check, since your ID will soon be included in one of our upcoming releases.
* ⚠ **WARN** OS/2 VendorID is 'UKWN', a font editor default. If you registered it recently, then it's safe to ignore this warning message. Otherwise, you should set it to your own unique 4 character code, and register it with Microsoft at https://www.microsoft.com/typography/links/vendorlist.aspx [code: bad]
⚠ WARN: Stricter unitsPerEm criteria for Google Fonts. * [com.google.fonts/check/unitsperem_strict](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/unitsperem_strict)
--- Rationale ---
Even though the OpenType spec allows unitsPerEm to be any value between 16 and
16384, the Google Fonts project aims at a narrower set of reasonable values.
The spec suggests usage of powers of two in order to get some performance
improvements on legacy renderers, so those values are acceptable.
But values of 500 or 1000 are also acceptable, with the added benefit that it
makes upm math easier for designers, while the performance hit of not using a
power of two is most likely negligible nowadays.
Additionally, values above 2048 would likely result in unreasonable filesize
increases.
* ⚠ **WARN** Font em size (unitsPerEm) is 4000 which may be too large (causing filesize bloat), unless you are sure that the detail level in this font requires that much precision. [code: large-value]
⚠ WARN: Check if each glyph has the recommended amount of contours. * [com.google.fonts/check/contour_count](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/contour_count)
--- Rationale ---
Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be
constructured in a handful of ways. This means a glyph's contour count will only
differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3
contours, depending on whether its double story or single story.
However, a quotedbl should have 2 contours, unless the font belongs to a display
family.
This check currently does not cover variable fonts because there's plenty of
alternative ways of constructing glyphs with multiple outlines for each feature
in a VarFont. The expected contour count data for this check is currently
optimized for the typical construction of glyphs in static fonts.
* ⚠ **WARN** This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: Glyph name: four Contours detected: 3 Expected: 1 or 2 Glyph name: Z Contours detected: 2 Expected: 1 Glyph name: bracketleft Contours detected: 3 Expected: 1 Glyph name: bracketright Contours detected: 3 Expected: 1 Glyph name: brokenbar Contours detected: 3 Expected: 2 Glyph name: registered Contours detected: 2 Expected: 3 or 4 Glyph name: AE Contours detected: 3 Expected: 2 Glyph name: Racute Contours detected: 2 Expected: 3 Glyph name: uni0156 Contours detected: 2 Expected: 3 Glyph name: Rcaron Contours detected: 2 Expected: 3 Glyph name: Zacute Contours detected: 3 Expected: 2 Glyph name: Zdotaccent Contours detected: 3 Expected: 2 Glyph name: AEacute Contours detected: 4 Expected: 3 Glyph name: uni0210 Contours detected: 3 Expected: 4 Glyph name: uni0212 Contours detected: 2 Expected: 3 Glyph name: uni1E9E Contours detected: 2 Expected: 1 Glyph name: minute Contours detected: 0 Expected: 1 Glyph name: second Contours detected: 0 Expected: 2 Glyph name: lira Contours detected: 2 Expected: 1 Glyph name: uni20A6 Contours detected: 4 Expected: 1, 3 or 5 Glyph name: uni20AD Contours detected: 3 Expected: 1 Glyph name: partialdiff Contours detected: 1 Expected: 2 Glyph name: uni2219 Contours detected: 0 Expected: 1 Glyph name: AE Contours detected: 3 Expected: 2 Glyph name: AEacute Contours detected: 4 Expected: 3 Glyph name: Racute Contours detected: 2 Expected: 3 Glyph name: Rcaron Contours detected: 2 Expected: 3 Glyph name: Z Contours detected: 2 Expected: 1 Glyph name: Zacute Contours detected: 3 Expected: 2 Glyph name: Zdotaccent Contours detected: 3 Expected: 2 Glyph name: bracketleft Contours detected: 3 Expected: 1 Glyph name: bracketright Contours detected: 3 Expected: 1 Glyph name: brokenbar Contours detected: 3 Expected: 2 Glyph name: fi Contours detected: 2 Expected: 3 Glyph name: fl Contours detected: 1 Expected: 2 Glyph name: four Contours detected: 3 Expected: 1 or 2 Glyph name: lira Contours detected: 2 Expected: 1 Glyph name: partialdiff Contours detected: 1 Expected: 2 Glyph name: registered Contours detected: 2 Expected: 3 or 4 Glyph name: uni0156 Contours detected: 2 Expected: 3 Glyph name: uni1E9E Contours detected: 2 Expected: 1 Glyph name: uni20A6 Contours detected: 4 Expected: 1, 3 or 5 Glyph name: uni20AD Contours detected: 3 Expected: 1 Glyph name: uni2219 Contours detected: 0 Expected: 1 [code: contour-count]
⚠ WARN: Are there caret positions declared for every ligature? * [com.google.fonts/check/ligature_carets](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/ligature_carets)
--- Rationale ---
All ligatures in a font must have corresponding caret (text cursor) positions
defined in the GDEF table, otherwhise, users may experience issues with caret
rendering.
If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names
starting with 'caret_'. These can be compiled with fontmake as of version
v2.4.0.
* ⚠ **WARN** This font lacks caret position values for ligature glyphs on its GDEF table. [code: lacks-caret-pos]
⚠ WARN: Is there kerning info for non-ligated sequences? * [com.google.fonts/check/kerning_for_non_ligated_sequences](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/kerning_for_non_ligated_sequences)
--- Rationale ---
Fonts with ligatures should have kerning on the corresponding non-ligated
sequences for text where ligatures aren't used (eg
https://github.com/impallari/Raleway/issues/14).
* ⚠ **WARN** GPOS table lacks kerning info for the following non-ligated sequences: - f + f - f + i - i + f - f + l - l + f - i + l [code: lacks-kern-info]
⚠ WARN: Combined length of family and style must not exceed 27 characters. * [com.google.fonts/check/name/family_and_style_max_length](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/family_and_style_max_length)
--- Rationale ---
According to a GlyphsApp tutorial [1], in order to make sure all versions of
Windows recognize it as a valid font file, we must make sure that the
concatenated length of the familyname (NameID.FONT_FAMILY_NAME) and style
(NameID.FONT_SUBFAMILY_NAME) strings in the name table do not exceed 20
characters.
After discussing the problem in more detail at `FontBakery issue #2179 [2] we
decided that allowing up to 27 chars would still be on the safe side, though.
[1] https://glyphsapp.com/tutorials/multiple-masters-part-3-setting-up-instances
[2] https://github.com/googlefonts/fontbakery/issues/2179
* ⚠ **WARN** The combined length of family and style exceeds 27 chars in the following 'WINDOWS' entries: FONT_FAMILY_NAME = 'Gideon Professional Roman' / SUBFAMILY_NAME = 'Regular' Please take a look at the conversation at https://github.com/googlefonts/fontbakery/issues/2179 in order to understand the reasoning behind these name table records max-length criteria. [code: too-long]
⚠ WARN: Checking unitsPerEm value is reasonable. * [com.google.fonts/check/unitsperem](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/head.html#com.google.fonts/check/unitsperem)
--- Rationale ---
According to the OpenType spec:
The value of unitsPerEm at the head table must be a value between 16 and 16384.
Any value in this range is valid.
In fonts that have TrueType outlines, a power of 2 is recommended as this allows
performance optimizations in some rasterizers.
But 1000 is a commonly used value. And 2000 may become increasingly more common
on Variable Fonts.
* ⚠ **WARN** In order to optimize performance on some legacy renderers, the value of unitsPerEm at the head table should idealy be a power of between 16 to 16384. And values of 1000 and 2000 are also common and may be just fine as well. But we got 4000 instead. [code: suboptimal]
⚠ WARN: Do outlines contain any jaggy segments? * [com.google.fonts/check/outline_jaggy_segments](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/.html#com.google.fonts/check/outline_jaggy_segments)
--- Rationale ---
This check heuristically detects outline segments which form a particularly
small angle, indicative of an outline error. This may cause false positives in
cases such as extreme ink traps, so should be regarded as advisory and backed up
by manual inspection.
* ⚠ **WARN** The following glyphs have jaggy segments: * A.smcp: B<<96.0,90.0>-<247.0,110.0>-<293.0,138.0>>/L<<293.0,138.0>--<292.0,137.0>> = 13.67130713219584 * A.smcp: L<<293.0,138.0>--<292.0,137.0>>/B<<292.0,137.0>-<321.0,157.0>-<349.5,197.5>> = 10.407711312490015 * B.smcp: B<<1298.5,43.0>-<1176.0,5.0>-<1028.0,1.0>>/L<<1028.0,1.0>--<1029.0,1.0>> = 1.548157698977982 * B.smcp: L<<1028.0,1.0>--<1029.0,1.0>>/B<<1029.0,1.0>-<1017.0,0.0>-<987.0,0.0>> = 4.763641690726144 * E.smcp: B<<1607.0,405.0>-<1555.0,288.0>-<1531.0,137.0>>/L<<1531.0,137.0>--<1531.0,138.0>> = 9.03107179644063 * E.smcp: B<<259.0,115.0>-<343.0,150.0>-<358.0,212.0>>/L<<358.0,212.0>--<358.0,211.0>> = 13.60054251665873 * E.smcp: L<<1531.0,137.0>--<1531.0,138.0>>/B<<1531.0,138.0>-<1525.0,97.0>-<1513.5,66.0>> = 8.325650330426804 * E.smcp: L<<358.0,212.0>--<358.0,211.0>>/B<<358.0,211.0>-<385.0,322.0>-<385.0,797.0>> = 13.67130713219584 * Eacute: B<<824.0,1409.0>-<1697.0,1415.0>-<1647.0,1418.0>>/B<<1647.0,1418.0>-<1687.0,1417.0>-<1687.0,1370.0>> = 2.001534178285727 * Ecircumflex: B<<824.0,1409.0>-<1697.0,1415.0>-<1647.0,1418.0>>/B<<1647.0,1418.0>-<1687.0,1417.0>-<1687.0,1370.0>> = 2.001534178285727 and 111 more. [code: found-jaggy-segments]
⚠ WARN: Do outlines contain any semi-vertical or semi-horizontal lines? * [com.google.fonts/check/outline_semi_vertical](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/.html#com.google.fonts/check/outline_semi_vertical)
--- Rationale ---
This check detects line segments which are nearly, but not quite, exactly
horizontal or vertical. Sometimes such lines are created by design, but often
they are indicative of a design error.
This check is disabled for italic styles, which often contain nearly-upright
lines.
* ⚠ **WARN** The following glyphs have semi-vertical/semi-horizontal lines: * B.smcp: L<<572.0,14.0>--<456.0,13.0>> * F.smcp: L<<385.0,699.0>--<386.0,860.0>> * F: L<<1459.0,2507.0>--<1338.0,2506.0>> * F: L<<561.0,962.0>--<564.0,1418.0>> * H: L<<2661.0,1196.0>--<2662.0,1320.0>> * Hbar: L<<2661.0,1196.0>--<2662.0,1320.0>> * Hcircumflex: L<<2661.0,1196.0>--<2662.0,1320.0>> * K.smcp: L<<504.0,821.0>--<503.0,1130.0>> * K.smcp: L<<749.0,1088.0>--<751.0,761.0>> * K: L<<1010.0,1513.0>--<1013.0,1050.0>> and 210 more. [code: found-semi-vertical]

Summary

πŸ’” ERROR πŸ”₯ FAIL ⚠ WARN πŸ’€ SKIP β„Ή INFO 🍞 PASS πŸ”Ž DEBUG
0 12 9 111 7 65 0
0% 6% 4% 54% 3% 32% 0%

Note: The following loglevels were omitted in this report: