| | <<<Back 1 day (to 2018/01/08) | 20180109 |
| deekej | hello guys, I'm currently in contact with our fontconfig developer in regards to the CJK fonts mappings we were discussing yesterday | 11:19.33 |
| | he offered his help to you in case you're missing some functionality from fontconfig itself | 11:19.58 |
| | he's willing to help if something is missing in fontconfig to satisfy your requirements, e.g. for the CJK fonts lookup :) | 11:20.58 |
| chrisl | We can't use fontconfig for CIDFont subsitution | 12:23.10 |
| deekej | chrisl: is it because of the fontconfig missing some support? | 12:39.51 |
| chrisl | Partly, but mainly that the font files most commonly used for CIDFont substitution don't actually contain the information needed to make it work. Hence the need to specify the Registry, Ordering and Supplement values manually in the subsitution record | 12:41.42 |
| deekej | ah, ok | 12:42.42 |
| chrisl | TrueType, and even OpenType, has similar, but not directly comparable metadata | 12:43.23 |
| | Hence you just have to know/guess/hope the TTF you want to use approximates the Reg/Ord/Sup of the *actual* CIDFont | 12:44.11 |
| deekej | dealing with CJK is never easy :-/ | 12:45.06 |
| chrisl | AIUI, fontconfig does allow for its own metadata for each font, so it could be added. But I'm frankly, against using fontconfig in this way - I wish we'd never included it in GS in the first place | 12:46.55 |
| deekej | chrisl: yeah, but I guess there's no way this could be reverted now :-/ | 12:48.03 |
| chrisl | No, but we can avoid extending it..... | 12:48.24 |
| | Don't get me wrong, I'm not bad mouthing fontconfig, it's just it's use is better at the document *creation* time | 12:50.05 |
| deekej | yes, that's what I actually told to my colleagues when discussing it :) I knew you wouldn't like to have more maintenance work, especially related to CJK :) | 12:50.06 |
| | np ;) | 12:50.26 |
| chrisl | The biggest problem, even if fontfonfig added the metadata required, and an interface to access it - creating that metadata accurately for a useful body of font files would be a big, big task | 12:53.10 |
| deekej | I can imagine | 12:53.39 |
| | I still want to convince my colleagues to drop the custom CJK mapping files, and just roll with DroidSansFallback | 12:54.18 |
| | their biggest concern ATM is that in each country people have different favourite typeface, and that it might break printing for them :-/ | 12:54.58 |
| kens | If they are fallong back to any font other than the one requested, its already broken | 12:55.20 |
| chrisl | Well, they should embed their fonts: Postscript and PDF are *supposed* to be device independent | 12:55.34 |
| | FWIW, given the capability is there, I don't have a huge problem with the custom cidfmap mappings - they make at least some sense when you have control over the fonts files available on the system | 12:57.06 |
| deekej | I think the main problem would be if people have some documents where the fonts are not embedded... In that case the custom CJK that are "native" for that region might help I guess. But if our files are 10 years outdated, I no longer see a point to be doing this. | 12:58.21 |
| chrisl | I think that's a strong argument for your case. | 12:59.25 |
| deekej | okay, thanks :) | 13:00.31 |
| chrisl | There's also at least a couple of other distros that were shipping cidfmap mappings to font files they had long since dropped | 13:00.54 |
| | That didn't produce useful results either ! | 13:01.11 |
| deekej | yeah, this was the case for Fedora as well. People were trying to fix some issues with this approach, but they forgot to remove those files once the issues were gone... o.O | 13:03.54 |
| | I'm glad I've finally got rid of it in Fedora... :D | 13:04.12 |
| | chrisl: could you please merge this pull-request? https://github.com/ArtifexSoftware/urw-base35-fonts/pull/19 | 13:06.39 |
| | chrisl: the other one can wait :) | 13:06.51 |
| | this pull-request just merges some config files... I have realized that Nimbus Sans and Nimbus Sans Narrow is the same font typeface according to WPF font model whitepaper. | 13:07.48 |
| chrisl | deekej: both done | 13:10.43 |
| deekej | chrisl: thanks | 13:32.44 |
| | hmm, Akira Tagoh (fontconfig upstream developer) said that many people actually hated the Google Droid Sans Fallback for displaying CJK languages | 14:37.56 |
| kens | Then they should embed their fonts. | 14:38.12 |
| deekej | and supposedly it was replaced with Google Noto Sans CJK | 14:38.15 |
| kens | Yeah but we can't (currently) use that | 14:38.30 |
| | Bluntly, if you don't embed fonts, then you will get a replacement font. If you don't want that, then embed the fonts. No excuses! | 14:38.55 |
| deekej | kens: ah, ok. Is there any limitation for that in Ghostscript? | 14:38.56 |
| kens | What Noto ? | 14:39.06 |
| deekej | yes | 14:39.10 |
| kens | I cna't recall offhand why we can't use it | 14:39.18 |
| | chrisl will probably remember | 14:39.25 |
| deekej | kens: no problem :) | 14:39.29 |
| chrisl | Google distribute the Noto fonts as OTF/CFF and we can't use those for CIDFont subsitution | 14:40.47 |
| kens | Ah, there you go :-) | 14:40.54 |
| deekej | ah, ok | 14:41.08 |
| chrisl | It's not impossible, but it would be a fair amount of work to make it happen | 14:41.56 |
| | deekej: note that the purpose of using DroidSansFallback for automatic CIDFont substitution is *not* to look nice, or even right - it's a best guess to make the results legible | 14:43.38 |
| deekej | chrisl: yeah, I understand. :) I'm just trying to find some solution that wouldn't require you to do anything, and that would be OK with people from CJK regions :) | 14:44.47 |
| chrisl | deekej: From my point of view, I kind of want it to be *obviously* wrong, whilst still making the file readable | 14:45.39 |
| tor8 | deekej: chrisl: kens: the Noto Sans CJK fonts are opentype/CFF only. | 14:59.49 |
| kens | Yeah Chris said that | 15:00.03 |
| tor8 | and they are not trivial to just convert to TTF outlines (and they're *much* bigger than DroidSansFallback) | 15:00.34 |
| | but one benefit is that they do have language specific variants | 15:01.05 |
| kens | I'm, not at all sure thats a benefit for us | 15:01.26 |
| tor8 | mupdf uses the noto cjk fonts (but that's only because we can use OpenType/CFF fonts in PDF, which doesn't have the same limitations as postscript) | 15:01.40 |
| | kens: it would possibly be a benefit, because then you could use the japanese flavored characters when substituting for the Adobe-Japan registry | 15:02.15 |
| kens | In this case, I htink its the limitations of *PDF*, PostScript is less limited, which is why we can't use the Noto fonts | 15:02.20 |
| tor8 | likewise traditional/simplified chinese for GB/CNS | 15:02.38 |
| kens | tor8 : Yes, but that's a relatively small number of fotns | 15:02.40 |
| | Most of the fonts we see are /Identity | 15:02.50 |
| chrisl | Including all the language variaints just means an explosion in download size - I'd prefer to avoid that | 15:02.55 |
| kens | Again, if you go to a substitute font, the result is *wrong*. It may be legible, but its not what the author intended and is therefore incorrect | 15:03.28 |
| tor8 | kens: yes. mupdf only uses the noto CJK fonts for fonts with the CJK cmaps | 15:03.55 |
| | kens: and we support EPUB, where you're not supposed to embed the fonts :) | 15:04.35 |
| kens | Fortunately for us, we don't :) | 15:04.56 |
| tor8 | if the source han sans/noto sans cjk (same fonts, different name) were trivially available as TTF I'd suggest gs try to use them as well | 15:05.12 |
| | but as it stands, I see no real world benefit over just using droid sans fallback | 15:05.22 |
| kens | Its certainly not worth the engineering efrfort to replace one wrong answer with a different wrong answer, IMO | 15:06.01 |
| chrisl | It's more than just being available as TTF, they'd also have to be widely used by the distros - and that's not likely now | 15:06.22 |
| | I have an open enhancement to make OTF/CFF fonts work as CIDFont subsitutes, but it's a fair amount of work, and I just haven't found the time | 15:07.34 |
| deekej | chrisl: since you're planning to this work in the future, wouldn't be that a good time to check if the 'pdfwrite' could get the OTF/CFF support as well? IIRC, you said that pdfwrite is currently the only limitation why Ghostscript can't currently support OTF/CFF fully... | 15:15.04 |
| | reason why I'm asking is that it seems that almost the whole world is "planning" to migrate to TTF/OTF as tome point in the future | 15:15.45 |
| kens | Not that simple | 15:15.48 |
| | pdfwrite is perfectly happy with CFF OTF fonts, when they are not being used as substitutes. | 15:16.07 |
| deekej | For example LibreOffice has dropped it support for Type1 last year completely... | 15:16.08 |
| kens | Yes, but that's not a problem | 15:16.20 |
| chrisl | deekej: Nope, pdfwrite is what prevents us from switching the base35 to OTF, not from using OTF in general | 15:16.24 |
| deekej | chrisl: ah, ok, that's actually what I meant. :) I didn't express myself clear enough. | 15:17.15 |
| kens | Again, no urgency on our (or anyone else's) part | 15:17.32 |
| | Because its only font substitutes | 15:17.38 |
| | And why should anyone else care what format we choose to use for font substitution | 15:17.55 |
| deekej | I see | 15:18.26 |
| | Forward 1 day (to 2018/01/10)>>> | |
Log of #ghostscript at irc.freenode.net.