I'm have a font named "YoavKtav Black" on my system. When LO comes up, it says: warn:vcl.fonts:7088:7088:vcl/unx/generic/fontmanager/fontmanager.cxx:424: Unimplemented mac encoding 18432 to unicode conversion for fontname YoavKtav Black Should there be such a conversion? If there should, why isn't there? If there shouldn't - why is this printed? Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 360b5861fb46353e7a6b9f5abf13339cd719a8df CPU threads: 4; OS: Linux 6.0; UI render: default; VCL: qt5 (qfont+xcb) Locale: en-IL (en_IL); UI: en-US
Eyal, for me your comment doens't look like a bug report but like a question for advice. Please use ask.libreoffice.org in such a case.
(In reply to Dieter from comment #1) > Eyal, for me your comment doens't look like a bug report Then let me clarify for you: That message should not be printed. Either such conversion needs to happen, in which case the bug is that it's not implemented; or it doesn't need to happen, in which case the bug is that this message is printed.
The fontnames of fonts can be encoded in lots of different encodings, we convert them to unicode so we can show the font name. Your font seems to be using an encoding we don't support so we're not converting it and warn that we aren't. Though it looks like we "get away with it" and the name is all in ascii anyway(?) Is the font available anywhere that I can look at it.
18432 (0x4800) is certainly not listed at https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6name.html. I was able to find a font called "YoavKtav Black" but it (presumably) was a different version and didn't exhibit the problem, but had some other different issues like appearing to have blank glyphs for the latin area, so I'm leaning towards a buggy font claiming it's name is encoded in an encoding that doesn't exist.
I can allowlist it as that does seem to be its unmangled font name: https://gerrit.libreoffice.org/c/core/+/148417
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4b16ed30c345bbce7f579acf556db29a4d95b80a tdf#152278 a YoavKtav Black font reported as claiming its name is in 0x4800 encoding It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 185822 [details] Yoav Ktav black font Here's the font. I got it many years ago, someplace on the Internet where it was available for download... I'm not sure which version this is. Some meta-data obtained with fc-query: family: "YoavKtav Black"(s) style: "Regular"(s) fullname: "YoavKtav Black"(s) slant: 0(i)(s) weight: 0(f)(s) width: 100(f)(s) foundry: "MEIR"(s) index: 0(i)(s) outline: True(s) scalable: True(s) fontversion: 65536(i)(s) fontformat: "TrueType"(s) decorative: False(s) postscriptname: "YoavKtavBlack"(s) color: False(s) symbol: False(s) variable: False(s) fonthashint: True(s) order: 0(i)(s)
Yeah, fontforge also says "Invalid mac encoding 18432" on this so bug in font seems a fair assessment. Version here is "2.0, WIN2K-SP4 FIX!" while the one I found was "1.0" so I guess I had an older one. Silent about this particular font now anyway. Will adjust warning for other cases to indicate if the encoding is not implemented or is likely invalid.
(In reply to Caolán McNamara from comment #8) > Will > adjust warning for other cases to indicate if the encoding is not > implemented or is likely invalid. A warning explain what's actually (likely) wrong is great. Thank you. > Version here is "2.0, WIN2K-SP4 FIX!" Which tool do you use to see that? I used `file`, and then `fc-query`, on Linux. Is there some other tool which prints more meta-data?
It is probably not just a coincidence that 18432 (0x4800) is an ASCII zero (0x48) (and a zero byte). Most likely some font editing software mistakenly puts an ASCII zero there instead of a binary zero. Or somebody has even edited the font using some hex editor to change the encoding and made a mistake?
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/e6e37d2de2e78c8d0d4c7d9ee45e8c9094b9076a tdf#152278 a YoavKtav Black font reported as claiming its name is in 0x4800 encoding It will be available in 7.5.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Er, sorry, ASCII zero is of course *decimal* 48, not hex 48. But anyway, probably not a coincidence. Somebody has managed to not only mix up whether the encoding field is binary or text, but also the decimal and hex values of the ASCII zero character.
(In reply to Eyal Rozenberg from comment #2) > That message should not be printed. Either such > conversion needs to happen, in which case the bug is that it's not > implemented; or it doesn't need to happen, in which case the bug is that > this message is printed. Just a conclusion for the whole issue raised initially: Yes it needs to be printed. The conversion should happen, because that's how the file format is defined (the encoding is specified in the file for the data). The decoding can't happen, because the file has a garbage there. The warning helps anyone seeing an unexpected undecoded data, and there was no bug here. Personally I consider the workaround created here as mildly harmful (in the sense that it adds some artifact into the codebase, which was not a real issue, based on some mistake of some font author (that could be fixed easily on their side), but from now on, will be checked in the code). Of course, I don't advocate to undo the change, just a thought.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/842c2f1d4725b654f141b2b1695a174afc9b02b4 Related: tdf#152278 distinguish likely-invalid vs unimplemented in warning It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Eyal Rozenberg from comment #9) > Which tool do you use to see that? trusty "fontforge", I bet ttx can be also used to dump that information.
(In reply to Mike Kaganski from comment #13) > Just a conclusion for the whole issue raised initially: > > Yes it needs to be printed. The conversion should happen, because that's how > the file format is defined (the encoding is specified in the file for the > data). The decoding can't happen, because the file has a garbage there. The > warning helps anyone seeing an unexpected undecoded data, and there was no > bug here. What shouldn't be printed is "unimplemented decoding". That suggests that it's a reasonable encoding but LO just hasn't implemented yet. Caolan will - hopefully - print a message better explaining what is actually the case. > Personally I consider the workaround created here as mildly harmful (in the > sense that it adds some artifact into the codebase, which was not a real > issue, based on some mistake of some font author (that could be fixed easily > on their side), but from now on, will be checked in the code). Of course, I > don't advocate to undo the change, just a thought. I actually agree. I would be ok with not-special-casing this font - and, instead, detecting this kind of garbage in the file and silently ignoring it, or alternatively getting a more meaningful message about a suspected error in the font file itself.