| | <<<Back 1 day (to 2017/05/28) | 20170529 |
| deekej | hello folks, just a small question :) You have a git repository 'urw-core35-fonts', but you release it as 'urw-base35-fonts' archive... | 08:48.07 |
| | I know about the PostScript specifications (base fonts level 1, 2, and 3) | 08:48.34 |
| | so I'm just asking if there's any specific reason for it? :) | 08:49.00 |
| | (I will be creating a new package for Fedora now, so I want prevent any possible problems in the future) | 08:49.52 |
| kens | chrisl woudl be the right person to answer, but... I suspect the answer is simple; we call it base 35 because that's the PostScript term, but what we get from URW is called the 'core' 35. We simply rename it to be consistent with PostScript. | 08:50.25 |
| deekej | ah, ok :) | 08:50.50 |
| | thanks for clarification :) | 08:50.56 |
| | in that case I'll stick with the urw-base35 name :) | 08:51.07 |
| kens | Probably simplest, since URW don't publish the fonts themselves. | 08:51.32 |
| | The AGPL variants I mean | 08:51.46 |
| deekej | yes, they provide it to you, and you publish it instead of them, right? | 08:52.09 |
| chrisl | I think kens is right - tbh, URW's naming varies randomly :-( | 08:52.17 |
| kens | deekej : We don't particularly want to be the upstream source, but as I recall Artifex arranged for the fonts to be GPL'ed. URW aren't interested in publiching GPL fonts (they make their money sellign them after all), and so we (reluctantly) do it. | 08:53.21 |
| deekej | chrisl: I recall you telling me what kind of versioning mess they've produced 5 months ago :) I just got back to it now :) | 08:53.28 |
| kens | Every time we get something from them we have to work on it | 08:53.42 |
| chrisl | deekej: of the URW releases I've handled, every one (so far) has had different file names, different font names, and version numbers that vary between 1.10 to 1.00 without rhyme or reason | 08:54.37 |
| | Which reminds me, I have another update to deal with - when I have the mental fortitude to tackle it <sigh> | 08:57.06 |
| deekej | chrisl: ouch :-/ good luck with it, then ;) | 08:58.32 |
| chrisl | It's a very minor update - hopefully, it won't be too painful | 08:59.13 |
| deekej | chrisl: I remember you said that ghostscript can use TTF/OTF fonts as substitutions if Type 1 fonts are missing, but the substitution can't be guaranteed to be absolutely flawless, unless the fonts use the CFF outlines... | 10:33.47 |
| | but if I read the wikipedia right, the OTF should contain the CFF outlines | 10:34.30 |
| kens | OTF may contain either CFF or TrueType outlines | 10:34.45 |
| chrisl | At the moment, you cannot safely use OTF/CFF in place of the base35 Type 1 fonts | 10:35.14 |
| deekej | chrisl: hmm, OK. So what happens if I have installed the same fonts both in OTF and Type 1 - will ghostscript automatically use the Type 1 fonts? | 10:36.11 |
| | or do I need to configure this somehow with ghostscript? | 10:36.26 |
| kens | Depends what you have set up in fontmap/cidfmap | 10:36.31 |
| chrisl | Ghostscript will look first in its default fontpath | 10:36.46 |
| deekej | right now Fedora has some really old outdated CIDfmap from Adobe, which I plan to update to same version you use with Ghostscript | 10:37.39 |
| kens | I don't think you can have a cidfmap from Adobe | 10:37.55 |
| | That's a Ghostscript thing | 10:38.02 |
| | You might have CMaps from Adobe | 10:38.10 |
| deekej | ah, you're right | 10:38.28 |
| | https://github.com/adobe-type-tools/cmap-resources | 10:38.29 |
| kens | CMaps are a different thing altogether, they are only used in conjunction with CIDFonts | 10:38.48 |
| | (exccept for ToUnicode CMaps, but let's not go there) | 10:39.03 |
| chrisl | For the base35 fonts, we (as shipped) map the "industry name" to the "URW name", then let Ghostscript's normal font search search handle finding the actual file | 10:39.11 |
| | "gs -h" will print (amongst other things) the places it will search | 10:39.41 |
| deekej | oh, thank you for the info | 10:40.02 |
| | btw: I found in the fedora package some CIDfnmap and cidfmap files | 10:40.44 |
| | I guess those will need update at some point as well | 10:41.00 |
| | I will dig out where we got them from | 10:41.08 |
| chrisl | cidfmap defines substitutes for *CIDFonts* | 10:41.21 |
| | The biggest packaging problem we've had with cidfmap files is that some distros have/had a cidfmap referencing font files that the gs package did depend upon | 10:42.34 |
| | And, basically, if you point gs at a CIDFont substitute that doesn't exist, it falls in a heap - there's no way to recover from that | 10:43.17 |
| deekej | looking at the log, people were workarounding some bugs with the cidfmap... but that was 10 years ago.. o.O | 10:45.40 |
| | so if I get it right, the closest way to vanilla build is to not use the cidfmap or custom CIDfnmap files, right? | 10:46.48 |
| chrisl | Our default cidfmap is empty | 10:47.08 |
| | cidfmap is really a way to handle badly made PDF files (not work around bugs!) | 10:47.40 |
| deekej | in case the fonts are installed correctly, there should not be any need for cidfmap or CIDfnmap, am I right? | 10:47.41 |
| chrisl | Not exactly...... | 10:48.08 |
| | I repeat: we're talking about CIDFonts here, *not* fonts | 10:48.34 |
| | CIDFonts are similar to, but not the same as fonts | 10:48.56 |
| deekej | yeah, I realize that. I was just thinking it was connected to it | 10:49.36 |
| chrisl | Ghostscript has the ability to take a suitable TrueType font, and use it as a substitute for a CIDFont | 10:49.49 |
| | TBH, if you stumble across a CIDFont file, I'll be *extremely* surprised | 10:50.23 |
| deekej | these are the files previous maintainers were using: | 10:51.59 |
| | http://pkgs.fedoraproject.org/cgit/rpms/ghostscript.git/tree/CIDFnmap | 10:51.59 |
| | http://pkgs.fedoraproject.org/cgit/rpms/ghostscript.git/tree/cidfmap | 10:52.05 |
| chrisl | Well, all those do if reference other files, so..... | 10:52.54 |
| deekej | yeah, I think I start to get it :D sorry, this is still completely new for me, I'm trying to wrap my head around it | 10:53.34 |
| chrisl | My guess is that the use of ".runlibfileifexists" means those referenced files some with separate packages which include the required font files | 10:54.30 |
| | (I say font files because they are almost certainly TTF files, rather than on-disk CIDFonts) | 10:54.56 |
| deekej | I think I start to understand. | 11:05.17 |
| | Anyway, if I go back to my initial problem. Fedora Packaging Guidelines require me to package OTF fonts where possible. I can see them in your repository, but I can't find them in the archive you provide. I guess you have some reason for it. | 11:06.54 |
| chrisl | Yeh, they don't work, currently | 11:07.43 |
| deekej | can you be more specific, please? they do not work with ghostscript, or generally? | 11:08.09 |
| chrisl | They cause problems with pdfwrite just now, *if* you try to use them for the base35 fonts - they work fine otherwise | 11:09.02 |
| deekej | thanks :) | 11:09.21 |
| | that will make my decision regarding packaging much simpler :) | 11:09.31 |
| chrisl | When we have time, the problem with pdfwrite will be fixed, and we can then allow OTF/CFF fonts as base35, too | 11:10.08 |
| | FWIW, we'll *never* be able to use OTF/TTF fonts for the base35 | 11:11.58 |
| | Forward 1 day (to 2017/05/30)>>> | |
Log of #ghostscript at irc.freenode.net.