Initial support for parsing the PANOSE number#172
Initial support for parsing the PANOSE number#172inferiorhumanorgans wants to merge 2 commits intoharfbuzz:mainfrom
Conversation
| /// Checks that face is marked as *Italic*. | ||
| #[inline] | ||
| pub fn is_italic(&self) -> bool { | ||
| let panose_italic = self |
There was a problem hiding this comment.
Let's make it less functional... We can move a panose getter into a private function, similar to Face::style().
| const SIZE: usize = 1; | ||
|
|
||
| fn parse(data: &[u8]) -> Option<Self> { | ||
| if data.is_empty() { |
There was a problem hiding this comment.
No need to check for that. FromData caller already did it.
|
It's definitely verbose... Do we really need all those enums? Maybe we can simply expose: struct Panose {
pub data: [u8; 10]
}plus 1250 LOC for a deprecated TrueType feature is a lot... Stuff like |
Yeah it's a lot… In terms of exposing a 10 byte slice, since it's a fixed length/offset field I think that's more suitable for Can the enums be eliminated? Sure. At its most basic this code is currently there to support three questions (is the font face italic/bold/monospaced). The checks could be collapsed into simply checking the bytes manually, but I think there's a legibility tradeoff. e.g. fn is_italic() -> bool {
(panose[0] == 2 && (panose[7] >= 9 && panose[7] <= 15)) ||
(panose[0] == 3 && (panose[7] >= 6 && panose[7] <= 13))
}Unsure what a happy medium would look like. I doubt that folks are clamoring to build an rtf parser/renderer, but as other use cases get added on (e.g. mapping weight to a weight class, or distinguishing between text / handwriting / symbol/wingdings font) I think having some sort of abstraction makes more sense. |
|
We can keep only enums used by the public API. Aka |
|
Any updates on this? |
|
Apologies — I'll have time next week to dig into this. |
|
No problem, just checking in. |
This includes a ton of boilerplate (apologies), a few tests, and adds checks for the PANOSE number in is_bold / is_italic / is_monospaced.
The PANOSE number also encodes a font weight that's distinct from the weight class in the OS/2 table so I've included a function to attempt to map the PANOSE weight to a weight class.