Mplus 2: Version 1.000; Mplus 1: Version 1.000 #3444
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closed
aaronbell
added
- Ready for Review
II CJK
|
FYI @mintoming |
Fontbakery reportFontbakery version: 0.7.37 [1] Family checks⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available?--- Rationale --- There's no reasonable (and legal) way to run the command `ftxvalidator` of the Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc. If Font Bakery is not running on an OSX machine, the machine running Font Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call (rpc). There's an ssh example implementation at: https://github.com/googlefonts/fontbakery/blob/main/prebuilt/workarounds /ftxvalidator/ssh-implementation/ftxvalidator
[11] MplusCodeLatin[wdth,wght].ttf🔥 FAIL: Check variable font instances don't have duplicate names--- Rationale --- This check's purpose is to detect duplicate named instances names in a given variable font. Repeating instance names may be the result of instances for several VF axes defined in `fvar`, but since currently only weight+italic tokens are allowed in instance names as per GF specs, they ended up repeating. Instead, only a base set of fonts for the most default representation of the family can be defined through instances in the `fvar` table, all other instances will have to be left to access through the `STAT` table.
🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.--- 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: Checking OS/2 Metrics match hhea Metrics.--- 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: Checking correctness of monospaced metadata.--- Rationale --- There are various metadata in the OpenType spec to specify if a font is monospaced or not. If the font is not truly monospaced, then no monospaced metadata should be set (as sometimes they mistakenly are...) Requirements for monospace fonts: * post.isFixedPitch - "Set to 0 if the font is proportionally spaced, non-zero if the font is not proportionally spaced (monospaced)" www.microsoft.com/typography/otspec/post.htm * hhea.advanceWidthMax must be correct, meaning no glyph's width value is greater. www.microsoft.com/typography/otspec/hhea.htm * OS/2.panose.bProportion must be set to 9 (monospace). Spec says: "The PANOSE definition contains ten digits each of which currently describes up to sixteen variations. Windows uses bFamilyType, bSerifStyle and bProportion in the font mapper to determine family type. It also uses bProportion to determine if the font is monospaced." www.microsoft.com/typography/otspec/os2.htm#pan monotypecom-test.monotype.de/services/pan2 * OS/2.xAvgCharWidth must be set accurately. "OS/2.xAvgCharWidth is used when rendering monospaced fonts, at least by Windows GDI" http://typedrawers.com/discussion/comment/15397/#Comment_15397 Also we should report an error for glyphs not of average width. Please also note: Thomas Phinney told us that a few years ago (as of December 2019), if you gave a font a monospace flag in Panose, Microsoft Word would ignore the actual advance widths and treat it as monospaced. Source: https://typedrawers.com/discussion/comment/45140/#Comment_45140
⚠ WARN: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ WARN: Are there caret positions declared for every ligature?--- 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: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
⚠ WARN: Check mark characters are in GDEF mark glyph class)--- Rationale --- Glyphs in the GDEF mark glyph class should be non-spacing. Spacing glyphs in the GDEF mark glyph class may have incorrect anchor positioning that was only intended for building composite glyphs during design.
⚠ WARN: Check mark characters are in GDEF mark glyph class--- Rationale --- Mark characters should be in the GDEF mark glyph class.
⚠ WARN: Check GDEF mark glyph class doesn't have characters that are not marks)--- Rationale --- Glyphs in the GDEF mark glyph class become non-spacing and may be repositioned if they have mark anchors. Only combining mark glyphs should be in that class. Any non-mark glyph must not be in that class, in particular spacing glyphs.
⚠ WARN: Does GPOS table have kerning information? This check skips monospaced fonts as defined by post.isFixedPitch value
Summary
Note: The following loglevels were omitted in this report:
|
|
Regarding the FAILs on MplusCodeLatin:
|
aaronbell
added
-- Needs Upstream Resolution
|
Thomas Linard has requested the addition of ExtraLight and SemiBold to the variable font STAT table: We are working to resolve upstream. |
|
Updated Mplus Code Latin: Version 1.000; ttfautohint (v1.8.3) added; Mplus 1 Code: Version 1.000; ttfautohint (v1.8.3) added; Mplus 1: Version 1.000; ttfautohint (v1.8.3) added; Mplus 2: Version 1.000; ttfautohint (v1.8.3) added25bb9a5: [gftools-packager] Mplus 1: Version 1.000; ttfautohint (v1.8.3) added
68194ea: [gftools-packager] Mplus 1 Code: Version 1.000; ttfautohint (v1.8.3) added
acfed76: [gftools-packager] Mplus 2: Version 1.000; ttfautohint (v1.8.3) added
c303d0d: [gftools-packager] Mplus Code Latin: Version 1.000; ttfautohint (v1.8.3) added
|
aaronbell
force-pushed
the
gftools_packager_mplus
branch
from
2ba45d0
to
c303d0d
Compare
|
Now updated with two extra weights in each family |
aaronbell
added
- Ready for Review
and removed
-- Needs Upstream Resolution
Fontbakery reportFontbakery version: 0.7.37 [1] Family checks⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available?--- Rationale --- There's no reasonable (and legal) way to run the command `ftxvalidator` of the Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc. If Font Bakery is not running on an OSX machine, the machine running Font Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call (rpc). There's an ssh example implementation at: https://github.com/googlefonts/fontbakery/blob/main/prebuilt/workarounds /ftxvalidator/ssh-implementation/ftxvalidator
[11] MplusCodeLatin[wdth,wght].ttf🔥 FAIL: Check variable font instances don't have duplicate names--- Rationale --- This check's purpose is to detect duplicate named instances names in a given variable font. Repeating instance names may be the result of instances for several VF axes defined in `fvar`, but since currently only weight+italic tokens are allowed in instance names as per GF specs, they ended up repeating. Instead, only a base set of fonts for the most default representation of the family can be defined through instances in the `fvar` table, all other instances will have to be left to access through the `STAT` table.
🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.--- 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: Checking OS/2 Metrics match hhea Metrics.--- 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: Checking correctness of monospaced metadata.--- Rationale --- There are various metadata in the OpenType spec to specify if a font is monospaced or not. If the font is not truly monospaced, then no monospaced metadata should be set (as sometimes they mistakenly are...) Requirements for monospace fonts: * post.isFixedPitch - "Set to 0 if the font is proportionally spaced, non-zero if the font is not proportionally spaced (monospaced)" www.microsoft.com/typography/otspec/post.htm * hhea.advanceWidthMax must be correct, meaning no glyph's width value is greater. www.microsoft.com/typography/otspec/hhea.htm * OS/2.panose.bProportion must be set to 9 (monospace). Spec says: "The PANOSE definition contains ten digits each of which currently describes up to sixteen variations. Windows uses bFamilyType, bSerifStyle and bProportion in the font mapper to determine family type. It also uses bProportion to determine if the font is monospaced." www.microsoft.com/typography/otspec/os2.htm#pan monotypecom-test.monotype.de/services/pan2 * OS/2.xAvgCharWidth must be set accurately. "OS/2.xAvgCharWidth is used when rendering monospaced fonts, at least by Windows GDI" http://typedrawers.com/discussion/comment/15397/#Comment_15397 Also we should report an error for glyphs not of average width. Please also note: Thomas Phinney told us that a few years ago (as of December 2019), if you gave a font a monospace flag in Panose, Microsoft Word would ignore the actual advance widths and treat it as monospaced. Source: https://typedrawers.com/discussion/comment/45140/#Comment_45140
⚠ WARN: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ WARN: Are there caret positions declared for every ligature?--- 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: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
⚠ WARN: Check mark characters are in GDEF mark glyph class)--- Rationale --- Glyphs in the GDEF mark glyph class should be non-spacing. Spacing glyphs in the GDEF mark glyph class may have incorrect anchor positioning that was only intended for building composite glyphs during design.
⚠ WARN: Check mark characters are in GDEF mark glyph class--- Rationale --- Mark characters should be in the GDEF mark glyph class.
⚠ WARN: Check GDEF mark glyph class doesn't have characters that are not marks)--- Rationale --- Glyphs in the GDEF mark glyph class become non-spacing and may be repositioned if they have mark anchors. Only combining mark glyphs should be in that class. Any non-mark glyph must not be in that class, in particular spacing glyphs.
⚠ WARN: Does GPOS table have kerning information? This check skips monospaced fonts as defined by post.isFixedPitch value
Summary
Note: The following loglevels were omitted in this report:
|
aaronbell
changed the title
|
I've dehinted the fonts with Kanji to save space. |
Fontbakery reportFontbakery version: 0.7.37 [1] Family checks⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available?--- Rationale --- There's no reasonable (and legal) way to run the command `ftxvalidator` of the Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc. If Font Bakery is not running on an OSX machine, the machine running Font Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call (rpc). There's an ssh example implementation at: https://github.com/googlefonts/fontbakery/blob/main/prebuilt/workarounds /ftxvalidator/ssh-implementation/ftxvalidator
[11] MplusCodeLatin[wdth,wght].ttf🔥 FAIL: Check variable font instances don't have duplicate names--- Rationale --- This check's purpose is to detect duplicate named instances names in a given variable font. Repeating instance names may be the result of instances for several VF axes defined in `fvar`, but since currently only weight+italic tokens are allowed in instance names as per GF specs, they ended up repeating. Instead, only a base set of fonts for the most default representation of the family can be defined through instances in the `fvar` table, all other instances will have to be left to access through the `STAT` table.
🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.--- 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: Checking OS/2 Metrics match hhea Metrics.--- 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: Checking correctness of monospaced metadata.--- Rationale --- There are various metadata in the OpenType spec to specify if a font is monospaced or not. If the font is not truly monospaced, then no monospaced metadata should be set (as sometimes they mistakenly are...) Requirements for monospace fonts: * post.isFixedPitch - "Set to 0 if the font is proportionally spaced, non-zero if the font is not proportionally spaced (monospaced)" www.microsoft.com/typography/otspec/post.htm * hhea.advanceWidthMax must be correct, meaning no glyph's width value is greater. www.microsoft.com/typography/otspec/hhea.htm * OS/2.panose.bProportion must be set to 9 (monospace). Spec says: "The PANOSE definition contains ten digits each of which currently describes up to sixteen variations. Windows uses bFamilyType, bSerifStyle and bProportion in the font mapper to determine family type. It also uses bProportion to determine if the font is monospaced." www.microsoft.com/typography/otspec/os2.htm#pan monotypecom-test.monotype.de/services/pan2 * OS/2.xAvgCharWidth must be set accurately. "OS/2.xAvgCharWidth is used when rendering monospaced fonts, at least by Windows GDI" http://typedrawers.com/discussion/comment/15397/#Comment_15397 Also we should report an error for glyphs not of average width. Please also note: Thomas Phinney told us that a few years ago (as of December 2019), if you gave a font a monospace flag in Panose, Microsoft Word would ignore the actual advance widths and treat it as monospaced. Source: https://typedrawers.com/discussion/comment/45140/#Comment_45140
⚠ WARN: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ WARN: Are there caret positions declared for every ligature?--- 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: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
⚠ WARN: Check mark characters are in GDEF mark glyph class)--- Rationale --- Glyphs in the GDEF mark glyph class should be non-spacing. Spacing glyphs in the GDEF mark glyph class may have incorrect anchor positioning that was only intended for building composite glyphs during design.
⚠ WARN: Check mark characters are in GDEF mark glyph class--- Rationale --- Mark characters should be in the GDEF mark glyph class.
⚠ WARN: Check GDEF mark glyph class doesn't have characters that are not marks)--- Rationale --- Glyphs in the GDEF mark glyph class become non-spacing and may be repositioned if they have mark anchors. Only combining mark glyphs should be in that class. Any non-mark glyph must not be in that class, in particular spacing glyphs.
⚠ WARN: Does GPOS table have kerning information? This check skips monospaced fonts as defined by post.isFixedPitch value
Summary
Note: The following loglevels were omitted in this report:
|
1 similar comment
Fontbakery reportFontbakery version: 0.7.37 [1] Family checks⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available?--- Rationale --- There's no reasonable (and legal) way to run the command `ftxvalidator` of the Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc. If Font Bakery is not running on an OSX machine, the machine running Font Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call (rpc). There's an ssh example implementation at: https://github.com/googlefonts/fontbakery/blob/main/prebuilt/workarounds /ftxvalidator/ssh-implementation/ftxvalidator
[11] MplusCodeLatin[wdth,wght].ttf🔥 FAIL: Check variable font instances don't have duplicate names--- Rationale --- This check's purpose is to detect duplicate named instances names in a given variable font. Repeating instance names may be the result of instances for several VF axes defined in `fvar`, but since currently only weight+italic tokens are allowed in instance names as per GF specs, they ended up repeating. Instead, only a base set of fonts for the most default representation of the family can be defined through instances in the `fvar` table, all other instances will have to be left to access through the `STAT` table.
🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.--- 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: Checking OS/2 Metrics match hhea Metrics.--- 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: Checking correctness of monospaced metadata.--- Rationale --- There are various metadata in the OpenType spec to specify if a font is monospaced or not. If the font is not truly monospaced, then no monospaced metadata should be set (as sometimes they mistakenly are...) Requirements for monospace fonts: * post.isFixedPitch - "Set to 0 if the font is proportionally spaced, non-zero if the font is not proportionally spaced (monospaced)" www.microsoft.com/typography/otspec/post.htm * hhea.advanceWidthMax must be correct, meaning no glyph's width value is greater. www.microsoft.com/typography/otspec/hhea.htm * OS/2.panose.bProportion must be set to 9 (monospace). Spec says: "The PANOSE definition contains ten digits each of which currently describes up to sixteen variations. Windows uses bFamilyType, bSerifStyle and bProportion in the font mapper to determine family type. It also uses bProportion to determine if the font is monospaced." www.microsoft.com/typography/otspec/os2.htm#pan monotypecom-test.monotype.de/services/pan2 * OS/2.xAvgCharWidth must be set accurately. "OS/2.xAvgCharWidth is used when rendering monospaced fonts, at least by Windows GDI" http://typedrawers.com/discussion/comment/15397/#Comment_15397 Also we should report an error for glyphs not of average width. Please also note: Thomas Phinney told us that a few years ago (as of December 2019), if you gave a font a monospace flag in Panose, Microsoft Word would ignore the actual advance widths and treat it as monospaced. Source: https://typedrawers.com/discussion/comment/45140/#Comment_45140
⚠ WARN: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ WARN: Are there caret positions declared for every ligature?--- 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: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
⚠ WARN: Check mark characters are in GDEF mark glyph class)--- Rationale --- Glyphs in the GDEF mark glyph class should be non-spacing. Spacing glyphs in the GDEF mark glyph class may have incorrect anchor positioning that was only intended for building composite glyphs during design.
⚠ WARN: Check mark characters are in GDEF mark glyph class--- Rationale --- Mark characters should be in the GDEF mark glyph class.
⚠ WARN: Check GDEF mark glyph class doesn't have characters that are not marks)--- Rationale --- Glyphs in the GDEF mark glyph class become non-spacing and may be repositioned if they have mark anchors. Only combining mark glyphs should be in that class. Any non-mark glyph must not be in that class, in particular spacing glyphs.
⚠ WARN: Does GPOS table have kerning information? This check skips monospaced fonts as defined by post.isFixedPitch value
Summary
Note: The following loglevels were omitted in this report:
|
davelab6
reviewed
Jun 15, 2021
davelab6
reviewed
Jun 15, 2021
davelab6
requested changes
Jun 15, 2021
There was a problem hiding this comment.
Looking forwards to this :) However, the few minor things I commented on will, I guess, require a rebuild and coordination with the upstream to propagate them back there, so please work with @mintoming on this :)
|
@davelab6 These appear to be primarily metadata.pb changes rather than modifications to the actual font files. Internally, M PLUS 1P uses the "Mplus1p" name:
I do need to rebuild the Code version as Coji's updated it, but aside from that, I don't think we need to rebuild the others. |
|
Updated M PLUS 1 Code: Version 1.000 added; M PLUS 2: Version 1.000 added; M PLUS 1: Version 1.000 added; M PLUS Code Latin: Version 1.000; ttfautohint (v1.8.3) addedbd10172: [gftools-packager] M PLUS 1: Version 1.000 added
7b805a9: [gftools-packager] M PLUS 1 Code: Version 1.000 added
bfc48c4: [gftools-packager] M PLUS 2: Version 1.000 added
304e509: [gftools-packager] M PLUS Code Latin: Version 1.000; ttfautohint (v1.8.3) added
|
aaronbell
force-pushed
the
gftools_packager_mplus
branch
2 times, most recently
from
304e509
to
f6ea9cd
Compare
|
Updated M PLUS 1: Version 1.000 added; M PLUS 2: Version 1.000 added; M PLUS 1 Code: Version 1.000 added; M PLUS Code Latin: Version 1.000; ttfautohint (v1.8.3) addedbd10172: [gftools-packager] M PLUS 1: Version 1.000 added
7b805a9: [gftools-packager] M PLUS 1 Code: Version 1.000 added
bfc48c4: [gftools-packager] M PLUS 2: Version 1.000 added
304e509: [gftools-packager] M PLUS Code Latin: Version 1.000; ttfautohint (v1.8.3) added
|
aaronbell
force-pushed
the
gftools_packager_mplus
branch
from
f6ea9cd
to
304e509
Compare
|
Had some issues with conflicts between my local version of this and the repro :/. Think I got it all sorted out. Anyway, ended up rebuilding all the fonts to implement the fix Coji requested, and have updated metadata so this should be good to go now. |
* M PLUS 1 Version 1.000 taken from the upstream repo https://github.com/coz-m/MPLUS_FONTS at commit coz-m/MPLUS_FONTS@977baab.
* M PLUS 2 Version 1.000 taken from the upstream repo https://github.com/coz-m/MPLUS_FONTS at commit coz-m/MPLUS_FONTS@977baab.
* M PLUS 1 Code Version 1.000 taken from the upstream repo https://github.com/coz-m/MPLUS_FONTS at commit coz-m/MPLUS_FONTS@977baab.
…8.3) added * M PLUS Code Latin Version 1.000; ttfautohint (v1.8.3) taken from the upstream repo https://github.com/coz-m/MPLUS_FONTS at commit coz-m/MPLUS_FONTS@977baab.
|
Updated M PLUS Code Latin: Version 1.000; ttfautohint (v1.8.3) added; M PLUS 1 Code: Version 1.000 added; M PLUS 2: Version 1.000 added; M PLUS 1: Version 1.000 added929e92a: [gftools-packager] M PLUS 1: Version 1.000 added
2c22488: [gftools-packager] ofl/mplus1 remove METADATA "source". #2587 3c46e28: [gftools-packager] M PLUS 2: Version 1.000 added
a29ef42: [gftools-packager] ofl/mplus2 remove METADATA "source". #2587 13231d2: [gftools-packager] M PLUS 1 Code: Version 1.000 added
46a6656: [gftools-packager] ofl/mplus1code remove METADATA "source". #2587 4a3599e: [gftools-packager] M PLUS Code Latin: Version 1.000; ttfautohint (v1.8.3) added
86129a6: [gftools-packager] ofl/mpluscodelatin remove METADATA "source". #2587 |
aaronbell
force-pushed
the
gftools_packager_mplus
branch
from
b72d9f2
to
86129a6
Compare
|
@aaronbell I still don't have a working gftools[qa], can you send me a zip ? |
|
1P is a rounded version which is different than these, so it shouldn't be deprecated. That said, it would probably be worth investigating if a new version of 1P should also be produced. For QA, are you just looking for fontbakery? Or something else? |
|
Also browser previews; I can still generate fontbakery report, but I can't have browser screenshots to check consistency across platform and eventual visual weirdness. |
Designer would like to modify the metrics for the Latin version of the font. So I am splitting it from this PR and will do a separate PR for the font.
aaronbell
changed the title
|
Please note that I have removed M Plus Code Latin and M Plus 1 Code from this PR. The designer wants to modify the vertical metrics and I will need some time to work with him to get that done—will submit a separate PR with that font. However, I believe this is ready to move forward as is. |
Designer has requested a similar treatment of the vertical metrics in M Plus 1 Code fonts as M Plus Code Latin. Will submit those two separately than these two.
aaronbell
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
438bea5: [gftools-packager] Mplus 1: Version 1.000; ttfautohint (v1.8.3) added
c5ae89a: [gftools-packager] Mplus 2: Version 1.000; ttfautohint (v1.8.3) added
e97a9da: [gftools-packager] Mplus 1 Code: Version 1.000; ttfautohint (v1.8.3) added
a29c278: [gftools-packager] Mplus Code Latin: Version 1.000; ttfautohint (v1.8.3) added