| | <<<Back 1 day (to 2015/01/26) | 20150127 |
| mvrhel_laptop | yes! with nsis, I can get the file association icons working correctly. | 04:03.21 |
| | wish I had worked with this from the start | 04:03.29 |
| henrys | mvrhel_laptop: I"m imagining you in front of visual studio with your hololens ;-) | 05:01.40 |
| mvrhel_laptop | :) | 05:03.11 |
| kens | Drat, Marcos has left me dealing with this idiot from HP. Now I need to go and try to figure out what stupidity he's up to. | 08:36.51 |
| chrisl | Maybe you should be ill, too | 08:38.54 |
| kens | I am ill, I have a cold.... | 08:50.45 |
| | Crop of dumbquestions this morning as well :-( | 08:51.15 |
| | Another one having problems downloading from ghostscript.com | 09:13.29 |
| chrisl | Maybe GoDaddy want rid of us...... | 09:26.29 |
| kens | Well I could understand that I guess | 09:32.45 |
| | Well that's about as polite as I can manage to be to that customer. | 10:32.57 |
| | It must be idiot day today | 10:44.35 |
| posdak | buenas | 12:26.59 |
| | me gustaria saber si con gs9.06 puedo comvertir con codigo asp vbscript una url en pdf | 12:27.50 |
| kens | SOrry, don't understand Spanish..... | 12:28.05 |
| posdak | ok | 12:28.13 |
| | hi, with gs9.06 ¿I can transform a url in pdf? | 12:30.48 |
| | in asp | 12:30.52 |
| | vbscript | 12:30.54 |
| kens | No. | 12:30.56 |
| posdak | ok thanks | 12:31.06 |
| kens | You can process PostScript, PDF PCL or XPS and generate a PDF file, that's the only valid input | 12:31.22 |
| posdak | Do you know if there is a free program that does? | 12:31.46 |
| kens | I'm not sure exactly what you want to do. You want to pass a URL to an application, what are you expecting it to do with the URL ? | 12:33.01 |
| posdak | thanks kens | 12:33.04 |
| | url to file pdf | 12:34.01 |
| kens | SO you want the URL to appear as text in a PDF file ? | 12:34.16 |
| posdak | yes | 12:34.23 |
| kens | Well something like iTextSharp can create PDF files with text in them. | 12:34.43 |
| posdak | ok, I'll look for | 12:36.42 |
| | thanks | 12:36.54 |
| tor8 | posdak: do you want to print a web page to pdf? | 12:38.12 |
| posdak | no | 12:40.55 |
| | to file pdf | 12:41.06 |
| tor8 | what do you want the pdf file to contain? the text "http://www.example.com/" or the contents of the web page at http://www.example.com? | 12:43.05 |
| kens | lunches | 12:43.27 |
| posdak | contents of the web page at http://www.example.com | 12:46.06 |
| | my code is asp | 12:46.43 |
| tor8 | posdak: use a web browser, like internet explorer | 12:49.08 |
| posdak | Document document = new Document(PageSize.A4, 80, 50, 30, 65); PdfWriter.getInstance(document, new FileStream("Chap0707.pdf", FileMode.Create)); HtmlParser.parse(document, "Chap0702.html"); | 12:51.39 |
| henrys | oh meeting time. | 15:30.10 |
| kens | Yes indeed | 15:30.19 |
| Robin_Watts | henrys: Feeling better? | 15:30.33 |
| henrys | mvrhel_laptop: so that net bug is kind of alarming... hopefully it will be an isolated thing | 15:30.43 |
| | Robin_Watts: much yes. | 15:30.48 |
| Robin_Watts | net bug? | 15:30.57 |
| kens | .NET ? | 15:31.09 |
| henrys | I went running in shorts yesterday and thought about you guys skiing - uh oh, but it's a long way off. | 15:31.26 |
| kens | We shold go to New York, plenty opf snow there | 15:31.49 |
| rayjj | isn't Copper a bit higher ? | 15:31.56 |
| Robin_Watts | kens: few hills. | 15:31.57 |
| henrys | I don't think you have to worry. | 15:32.11 |
| rayjj | I hope not. | 15:32.19 |
| fredross-perry | hi all. | 15:32.25 |
| kens | The snow report says there's still plenty there | 15:32.25 |
| henrys | It's 75 degrees and gas is 1.65 a gallon, how long can that last? | 15:32.49 |
| rayjj | BTW, mvrhel_laptop I followed your advice and am coming in before the last flight in (to allow for delays/cancellation problems). I get in at 5:20 (if it's on schedule) | 15:33.55 |
| henrys | Robin_Watts: apparently a customer has grabbed mvrhel_laptop .NET stuff and his using it. I'm not sure if that was part of mvrhel_laptop's evil plan | 15:33.57 |
| Robin_Watts | henrys: Right, sorry .net, rather than net. I was being dim. | 15:34.16 |
| henrys | kens: I guess I should be doing support also, I only read the first clause in marcos sentence and didn't realize he'd be out all week. | 15:35.02 |
| kens | It'd be good if you take the US ones henry | 15:35.20 |
| | Otherwise they ahev to wait for me to wake up | 15:35.30 |
| henrys | kens: will do. | 15:35.34 |
| kens | Also, I have a nasty cold at the moment | 15:35.36 |
| mvrhel_laptop | rayjj: great | 15:35.38 |
| henrys | mvrhel_laptop: anyway I was thinking that could be assigned to fredross-perry if he is up on .net stuff so youi can get back to sot | 15:36.22 |
| mvrhel_laptop | henrys: I am going to look at it today. He shared his project with me | 15:36.25 |
| | it should not take long. | 15:36.32 |
| | the customer did tell me that the gsview project was working fine for him | 15:36.45 |
| | which uses the same call | 15:36.48 |
| henrys | fredross-perry: anything for the meeting, have any questions about your projects? | 15:37.12 |
| | Robin_Watts: what kind of compression do you get with SOT with the fonts. I know you strip tables and such. Do you know offhand? | 15:37.45 |
| fredross-perry | i hope to wrapup the gsview print dialog today, then back to iOS. | 15:37.46 |
| henrys | fredross-perry: great. | 15:37.57 |
| Robin_Watts | henrys: 50% | 15:37.58 |
| | (my dodgy memory says that stripping tables saves almost exactly 50% for the fonts we have) | 15:38.24 |
| henrys | wow... | 15:38.38 |
| jogux | strictly it's not compression. we drop parts of the fonts we don't support / use ;-) | 15:38.57 |
| henrys | I have been looking at WOFF and it does about 30% better than our romfs which is basically gzip. | 15:39.45 |
| Robin_Watts | WOFF ? | 15:39.54 |
| chrisl | Web Open Font Format | 15:40.18 |
| kens | Compressed OpenType essentially | 15:40.36 |
| Robin_Watts | henrys: We could do a similar stripping job on the fonts and remove the tables that none of our assorted font engines use. | 15:40.44 |
| henrys | I'm using raph's code on bithub tor8 are you familiar with that? | 15:40.51 |
| chrisl | My feeling is that WOFF will be quite slow to use | 15:41.33 |
| rayjj | henrys: we got good compression with lzma as well, but it slowed things down. Does WOFF use lzma ? | 15:41.35 |
| kens | I'm surprised that WOFF would compress that much better, since it only uses compress2 from zlib | 15:41.41 |
| henrys | I'm looking into this because we are getting nibbles from an embedded customer who wants to switch to URW but rom space is an issue. | 15:41.50 |
| Robin_Watts | Perhaps WOFF just has fewer tables in to start with ? | 15:41.59 |
| tor8 | henrys: bithub? | 15:42.03 |
| chrisl | henrys: for PCL? | 15:42.05 |
| rayjj | henrys: URW TT fonts or the PS ones? | 15:42.19 |
| henrys | he he github | 15:42.20 |
| rayjj | the TT fonts are quite a bit larger, iirc | 15:42.35 |
| henrys | both languages. | 15:42.40 |
| chrisl | WOFF would be no use for Postscript | 15:42.50 |
| kens | The WOFF fonts only include the sfnt data | 15:42.58 |
| rayjj | chrisl: we _could_ use those | 15:43.20 |
| henrys | freetype supports woff | 15:43.23 |
| Robin_Watts | kens: Right, so less data to start with, hence smaller. | 15:43.32 |
| chrisl | rayjj: no for Postscript | 15:43.33 |
| | s/no/not | 15:43.40 |
| tor8 | henrys: doesn't ring a bell, which project? | 15:43.43 |
| Robin_Watts | Stripping tables sounds like a plan here. | 15:43.45 |
| henrys | a google away: https://github.com/google/woff2 | 15:44.15 |
| tor8 | henrys: okay, that's the one I'm looking at | 15:44.34 |
| kens | Robin_Watts : that's why the WOFF fonts are smaller, just the sfnts | 15:44.36 |
| rayjj | chrisl: as long as it has the PS name table, we should be able to use it -- PS/PDF can use TTF fonts now | 15:44.36 |
| chrisl | rayjj: we have to use Type 1 for the standard fonts | 15:44.55 |
| henrys | woff is documented here: http://www.w3.org/TR/WOFF2/ | 15:45.07 |
| kens | Not sure what tables are included in the sfnt resoruce | 15:45.12 |
| tor8 | henrys: CFF in pretty compact, and doesn't need to be decompressed into memory before using | 15:45.45 |
| kens | Well that looks like it includes all the tables | 15:45.45 |
| henrys | why don't you guys have a look and we'll talk about it I thought you had already read about it. | 15:45.51 |
| kens | I've read about iut, yes | 15:45.59 |
| | But for GS it would slow us down, so never considered it | 15:46.13 |
| rayjj | kens: I thought the sfnt table was the one that had the outlines, and that you also need others (loca, glyf) to actually use the sfnt table | 15:46.22 |
| tor8 | embedding WOFF just doubles the RAM needed, if we need to store the compressed file in a ROMFS and then decompress it every time it's instantiated | 15:46.27 |
| Robin_Watts | henrys: Why bother with WOFF? If we can strip out tables we don't use from the existing fonts and get 30% saving, then we might as well stick with those, right? | 15:46.30 |
| kens | rayjj outlines are in the GLYF table | 15:46.33 |
| | The only proper way to compare sizes is to take a WOFF font, decompress it back to a TT, then store the TT in our romfs | 15:47.11 |
| tor8 | freetype is very smart with plain TTF, it doesn't need to allocated any dynamic memory to parse it at all | 15:47.14 |
| Robin_Watts | We have the code to do the stripping. | 15:47.20 |
| chrisl | There's too much Postscript out there that relies on being able to mess with the contents of the standard Type 1 fonts (not to mentioned our own PDF interpreter) - if we start using Truetype of WOFF instead, too many things wouldn't work | 15:47.33 |
| henrys | kens: that's what I did and it was 30 % smaller than romfs compression. but as Robin_Watts says we haven't done the table stripping, well I've done some. | 15:48.02 |
| rayjj | chrisl: true -- all the PS foo that sticks a Euro symbol in somewhere | 15:48.04 |
| tor8 | chrisl: will raw CFF fonts work for postscript as type1?+ | 15:48.07 |
| kens | henrys it looks like the space is gained by 'transforming' the big table s(loca nad glyf) so that they get better entropy encoding | 15:48.29 |
| | And are undoubtedly slower to decompress as a result | 15:48.40 |
| chrisl | tor8: Maybe..... | 15:49.03 |
| henrys | chrisl: this dependency on Type 1 is a problem on several fronts. Are we sure that issue is not going away as postscript fades. It would be great to switch everyone to cff or truetype for that matter. The UFST code works with Monotype fonts, right? | 15:49.26 |
| kens | henrys as long as GS is a PostScript interpreter, we cna't stop relying on the way PostScript works | 15:50.07 |
| tor8 | opentype (wasteful truetype SFNT wrapper around a CFF file) could get us the best of all worlds | 15:50.18 |
| chrisl | henrys: the UFST code works because I've added code to handled those cases | 15:50.18 |
| kens | Also, as long as GS' PDF interpreter relies on PostScript | 15:50.19 |
| rayjj | henrys: and UFST with PS is a problem | 15:50.29 |
| kens | If a customer is truly concerned about the romfs size the fist thing to do is throw out CMAPs and stuff | 15:51.18 |
| | Fonts are a comparatively small part of the romfs as I recall | 15:51.34 |
| rayjj | kens: the PDF interpreter can work with non-Type1 fonts since it doesn't do anything funky (at least that we can't fix) | 15:51.38 |
| chrisl | rayjj: UFST/Microtype is fine with Postscript, but UFST for any downloaded fonts is a no-no | 15:51.40 |
| | rayjj: Oh, think again! | 15:51.51 |
| kens | chrisl beat me to it :-) | 15:52.02 |
| henrys | which brings up URW - URW calls the fonts CFF fonts because they have "CFF encodings" ... to us I imagine they are type 1's with non standard encodings. | 15:52.14 |
| kens | If they are .PFB fonts they are not CFF fonts | 15:52.33 |
| chrisl | rayjj: The PDF interpreter, for example, messes with charstrings to make small caps fonts...... | 15:52.39 |
| kens | Regardless of what encoding they use | 15:52.41 |
| rayjj | well, the PDF interpreter manages to use TTF substitutes (for things like Arial, etc) so it can't be too reliant on having Type 1 | 15:52.57 |
| henrys | kens: I understand that. | 15:52.58 |
| chrisl | rayjj: if we have a TTF substitute we don't have to create a "synthetic" substitute | 15:53.28 |
| henrys | IMHO it would behoove us to remove Type 1 dependencies as chrisl has done with the UFST. | 15:53.44 |
| chrisl | henrys: the URW fonts say: "/Encoding StandardEncoding def" | 15:53.55 |
| kens | henrys I suspect that is not possible | 15:54.03 |
| chrisl | henrys: why? | 15:54.07 |
| kens | And I still stand by the point that as long as GS is a PostScript interpreter it has to be able to behave properly as a PostScript itnerpreter | 15:54.42 |
| tor8 | henrys: speaking of URW ... any word? | 15:54.46 |
| henrys | well there are 2 possible universes: pcl uses type 1 or postscript uses truetype both universes suck. | 15:54.49 |
| kens | Why ? We can have PCL use TrueType and PS use type 1 (etc) | 15:55.08 |
| chrisl | *Everyone* expects the standard Postscript fonts to be Type 1, if they are not, people complain.... | 15:55.24 |
| kens | But having PCL use type 1 seems like its more likely to work to me | 15:55.29 |
| henrys | I am not going to stand before a printer company squeezed on rom space and explain 80 duplicate fonts. | 15:55.36 |
| rayjj | kens: but for an embedded system we don't want to store both | 15:55.38 |
| Robin_Watts | kens: So if we ever ship a language switch thing, we have to ship both sets of fonts? | 15:55.42 |
| kens | Robin_Watts : at the moment, I guess so yes | 15:55.54 |
| | And if tyhat's not aceptable then its PCL that hsould use type 1 | 15:56.03 |
| chrisl | The two font sets don't fully overlap | 15:56.10 |
| kens | Becuse PCL does not give you the tools to mess with the fonts, which PostScript does | 15:56.16 |
| rayjj | kens: that makes sense | 15:56.30 |
| Robin_Watts | (Complete ignoramus here... is there a downside to type 1 over ttf?) | 15:56.48 |
| chrisl | As tor says, we might be better looking at CFF..... | 15:57.00 |
| kens | PostScript doesn't support TT, PCL doesn't support type 1 | 15:57.13 |
| henrys | kens, chrisl : I'm not sure that is the right call for other reasons. The entire world is going to CFF adobe doesn't ship type 1 anymore. I think we should at least look at the specific issues. | 15:57.20 |
| Robin_Watts | How does CFF help? CFF != type1 either, right? | 15:57.34 |
| kens | We can use CFF, we changed all the fontws over in out last employment to be CFF | 15:57.41 |
| | Robin_Watts : CFF is truetype containing 'sort of' Type 1 outlines | 15:57.57 |
| | excuse me talking nonsense | 15:58.08 |
| tor8 | henrys: if PCL can handle OpenType (with embedded CFF), then PS can use the embedded CFF as-is and PCL use the opentype truetype like tables for what it needs | 15:58.11 |
| kens | OTF can contain CFF | 15:58.12 |
| chrisl | But CFF is a Postscript font, and should be sufficiently Type 1 -like to not bugger up Postscript that relies on that stuff | 15:58.25 |
| kens | CFF is 'like' type 1, close enough to fake it from the users POV | 15:58.26 |
| Robin_Watts | ok, so CFF is "close enough to type1" that postscript programs are happy. | 15:58.32 |
| kens | Yes | 15:58.39 |
| henrys | tor8: right that's why I think CFF makes my life easier. | 15:58.44 |
| chrisl | It may need some tweaking, but yes | 15:58.44 |
| kens | Using CFF is not a problem, using TT is | 15:58.55 |
| Robin_Watts | And how hard would it be to make PCL use CFF ? | 15:59.01 |
| rayjj | henrys: so, as kens said, PCL should use the PS fonts (CFF) | 15:59.14 |
| kens | PCL doesn't use CFF it uses OTF which can be TrueType wrapped around CFF | 15:59.22 |
| | And yes, thanks rayjj :-) | 15:59.33 |
| tor8 | Robin_Watts: CFF is just a compact binary representation of a parsed Type 1 font | 15:59.36 |
| rayjj | for the built in fonts, it doesn't matter, downloaded PCL fonts may be TT, but that isn't the ROM issue | 16:00.12 |
| | otherwise UFST would be unworkable since it is FAR from TT | 16:00.28 |
| chrisl | thinks UFST is largely unworkable, anyway....... | 16:00.53 |
| tor8 | OTF is truetype but replaced the loca/glyf tables with an embedded CFF font in a table for the outlines | 16:00.53 |
| henrys | yes this is all about resident fonts. I assume we'll leave things as is for downloaded. | 16:00.59 |
| tor8 | so if we want one set of resident fonts for both PCL and PS, we could use an OTF | 16:01.48 |
| henrys | this is going past the meeting time. I'll be around today to talk about it. | 16:01.55 |
| rayjj | chrisl: it's good enough for PCL embedded fonts, and that's the competition when it comes to ROM size | 16:02.00 |
| henrys | Does anyone have more stuff for the meeting? | 16:02.02 |
| kens | Yes, I agree, if we want a combined set then it should be OTF | 16:02.04 |
| | With CFF outlines | 16:02.33 |
| Robin_Watts | That sounds like a task worthy of an entry on the workflowy. | 16:02.37 |
| tor8 | kens: I'm assuming it would be easy for the resident fonts to just ignore the OTF wrapper and let the PS have at the CFF as if it were a plain Type1 font? | 16:02.49 |
| henrys | tor8: I was thinking it would be good for you to give joann dates as you use your sabbatical (cc staff) so we know when you'll be out for long periods. Is that okay? | 16:02.52 |
| kens | tyor8 that's a chrisl question :-) | 16:03.03 |
| | tor8^^ | 16:03.14 |
| rayjj | mvrhel_laptop: I'll try to keep you out of it, but I am in color conversion hell with cust 532's (to me trivial) color differences that occur when we use pattern-clist. I may call (fair warning to not answer the phone ;-) ) | 16:03.16 |
| tor8 | henrys: okay. | 16:03.28 |
| chrisl | tor8: If that's not how it already works, then yes, it would be pretty straight forward to make it work that way | 16:03.31 |
| Robin_Watts | how long is a sabbatical in this case? | 16:03.39 |
| mvrhel_laptop | rayjj: thanks for the heads up | 16:03.42 |
| kens | I suspect it already works like that | 16:03.42 |
| henrys | Robin_Watts: I don't remember the deal what was the choice tor8 ? | 16:04.41 |
| kens | Wow, Helmut had a heart attack O.O | 16:05.02 |
| henrys | the 10 year incentive | 16:05.05 |
| chrisl | But fair warning, even switching to CFF, someone *will* complain! | 16:05.21 |
| tor8 | I was planning on splitting the sabbatical in two parts. 6 weeks around june this year and then next year. | 16:05.27 |
| Robin_Watts | So it's a quarter (12 weeks) then. | 16:05.39 |
| kens | chrisl , yes I remember a certain cusotmer complaining when we did that at GG :-) | 16:05.43 |
| chrisl | kens: exactly! | 16:05.54 |
| | And they *kept* complaining, over and over | 16:06.08 |
| rayjj | kens: well, as long as they aren't our customer now ;-) | 16:06.13 |
| tor8 | Robin_Watts: yes. and 12 weeks off at once would let you take over mupdf completely, so I can't do that! ;) | 16:06.25 |
| henrys | I'll be back after the SOT meeting. | 16:06.27 |
| kens | THey came back again ? I told them to get lost until they could show something other than a hand-crafted example | 16:06.32 |
| Robin_Watts | chrisl: Presumably we can provide different font sets. The original Type 1's and the CFFs. | 16:06.42 |
| | s/CFF/OTFs/ | 16:06.50 |
| kens | rayjj I'm pretty sure they aren't (thanksfully) | 16:06.51 |
| | Robin_Watts : I'd assume we would only provide one set | 16:07.05 |
| rayjj | tor8: yeah, you'd come back and wouldn't recognize the code because of the rewrite ;-) | 16:07.05 |
| chrisl | Robin_Watts: Oh, that sounds like a PITA..... | 16:07.07 |
| tor8 | rayjj: at least I'm confident he won't rewrite it in C++! | 16:07.23 |
| chrisl | kens: they came back at least twice after you left with the same complaint | 16:07.35 |
| kens | Oh good grief..... | 16:07.41 |
| | Silly, silly people | 16:07.45 |
| Robin_Watts | chrisl: I'd figured the OTF would be an automated (?) wrapping process from the Type 1s ? | 16:07.49 |
| kens | Its not that simple Robin_Watts | 16:07.59 |
| | First we'd need to convert the Type 1 to CFF | 16:08.09 |
| | THen wrap them up as OTF | 16:08.19 |
| chrisl | Robin_Watts: Just two sets of fonts adds extra work, extra testing, etc etc | 16:08.30 |
| tor8 | kens: the first step is a pretty mechanical transform isn't it? | 16:08.36 |
| | making up OTF tables is open to more choices | 16:08.48 |
| kens | tor8 I'm pretty sure I have code somewhere to do it | 16:08.53 |
| rayjj | for customers that are picky about needing the PS Type1 we have those to give them, but as long as PCL works with CFF a customer tight on ROM space can use those | 16:08.56 |
| kens | I'd prefer to have one set of fonts if at all possible | 16:09.12 |
| | Otherwise we open ourselves up to problems (which set of fonts are you using to reproduce this problem) | 16:09.28 |
| chrisl | We'd effectively double our testing requirements..... | 16:10.06 |
| kens | Which build would we put up on the download site ? | 16:10.34 |
| Robin_Watts | chrisl: We'd only test with OTFs. | 16:10.38 |
| kens | Then we should only ship the OTFs | 16:10.49 |
| | If someone wants something else then that's up to them | 16:10.59 |
| Robin_Watts | But we'd give customers the option of putting the Type 1s back if they really want. | 16:11.01 |
| chrisl | Robin_Watts: And then give Type 1's to some important customer? Hmmmmmm | 16:11.01 |
| kens | Yeah, how long before that comes back to bite us :-0) | 16:11.16 |
| Robin_Watts | we can say it's untested and unsupported. | 16:11.18 |
| | It's enough to shut an awkward customer up. | 16:11.29 |
| kens | Robin_Watts : and that means precisely nothing | 16:11.29 |
| | It won't shut any customer up | 16:11.38 |
| | It just means it gets punted to Miles and then back to us | 16:11.50 |
| | From my previous experiences I don't believe there is any reason not to use CFFs | 16:12.46 |
| henrys | as a goal I think we should look at font rom space for the ufst. If we can go to customers and tell them it's not going to be a big deal that would be best. | 16:12.58 |
| kens | While some customers may complain, they will be unable to find any real-world example which doesn't work | 16:13.07 |
| chrisl | henrys: I doubt we'll ever get close to the size of the microtype fonts, for equivalent font sets, unless we sacrifice performance | 16:13.59 |
| kens | Even then I don't think we'll get close to Microtype | 16:14.22 |
| | The total font size at the moment seems to be 1.44 Mb | 16:14.52 |
| | For PostScript fonts | 16:15.00 |
| | CMaps run at 6,9 Mb | 16:15.11 |
| | There's another 3Mb for our fallback CIDFont | 16:15.31 |
| henrys | I'll be back after the sot meeting. | 16:15.34 |
| chrisl | CMaps aren't an issue - UFST doesn't replace those | 16:15.40 |
| kens | Yeah but if the cusotmer wants to save space, that's where they should start trimming | 16:16.01 |
| chrisl | Yes, I suppose..... but again, you have to deal with them asking why this file doesn't work | 16:16.41 |
| rayjj | mupdf has a compressed CMap technique that we should port over | 16:16.42 |
| kens | chrisl yes, but that's the price that gets paid | 16:17.15 |
| | They won't save much on PS fonts no matter what we do compared to trimming the fallback font and CMaps | 16:17.39 |
| | Because even if we removed all the PS type 1 fonts it would only save 1.4 Mb | 16:18.06 |
| | uncompressed all these numbers) | 16:18.15 |
| chrisl | Huh, so the new URW fonts are 2.2Mb for the Type 1s, and bzip2 only squashes that to 2.1Mb.... | 16:18.37 |
| kens | Hmm, I'm a bit surprised that they compress so badly | 16:18.59 |
| | Is that starting from .pfb ? Might compress better if they were decoded first | 16:19.23 |
| rayjj | PFB's have eexec encoded CharStrings, don't they ? That messes up compression | 16:20.18 |
| kens | most fopnts have eexec encrypted charstrings | 16:20.31 |
| chrisl | Indeed, I was just going to say that | 16:20.32 |
| kens | And a quick check shows that these ones do | 16:20.45 |
| | So we could decrypt them before storing int he romfs that might save some space | 16:21.10 |
| rayjj | it's easy enough to un-eexec those | 16:21.13 |
| chrisl | I was just interested - I thought the Burrows-Wheeler transform might give more compression | 16:21.34 |
| kens | I guess there's not much there for ot to work with when its encrypted | 16:21.53 |
| | I presume it lowers the entropy too much | 16:22.03 |
| rayjj | at CalComp Peter wrote a PS program to take the fonts, decrypt them then bzip2 compress them | 16:22.12 |
| kens | Its trivial to write such a thing, even in C. I have an old app that decrypts fonts here somewhere | 16:22.39 |
| rayjj | it let us get the fonts into 512Kb which was what we needed | 16:22.41 |
| kens | I'd suspect we'de do better converting to CFF though | 16:23.05 |
| | And an OTF wrapper shouldn't be too large | 16:23.21 |
| | Though I;d think it should be possible to have the PCL interpreter just use the native CFF fonts | 16:23.52 |
| | Its not like PCL can investigte the fonts as far as I'm aware | 16:24.09 |
| chrisl | It almost certainly should be, and we have enough CFF interpreters floating around..... | 16:24.28 |
| kens | Yeah, pdfwrite has 2 I htink :-) | 16:24.40 |
| | Actually I think pdfwrite has code for converting type 1 fonts into Type 1C (CFF) | 16:25.12 |
| chrisl | Plus one in Postscript, one in C in the PS interpreter, and one in C in the XPS interpreter..... and two in Freetype (for now) | 16:25.33 |
| kens | Excellent, can't have too many interpreters..... | 16:25.47 |
| chrisl | So we can always write yet *another* one for inclusion in the graphics library :-) | 16:26.25 |
| kens | So it seems to me that if space is a problem we could convert all the required fotns to CFF, add whatever it takes to have the PCL interpreter use CFF fotns for the built-in ones (downloaded fonts don;t change) and we would have the smallest set of fonts we can reasonably get | 16:26.38 |
| rayjj | kens: makes sense to me | 16:27.10 |
| kens | Maybe we could just move one of the existing ones into the graphics library. The pdfwrite one that converts type 1 to CFF seems like a decent candidate. Or replace it with a graphics library one that can do the same thing | 16:27.24 |
| rayjj | as long as we have the same set of faces and glyphs, PCL won't care | 16:27.40 |
| kens | rayjj that was my (limited) unerstanding | 16:27.52 |
| chrisl | I think probably so, yes. That'll almost certainly come out smaller than using TrueType | 16:28.00 |
| rayjj | and XPS also won't care, AIUI | 16:28.22 |
| | (most fonts are embedded there) | 16:28.34 |
| kens | I think XPS doesn't use 'built-in' fonts anyway ? | 16:28.38 |
| chrisl | XPS has no "built in" fonts IIRC | 16:28.42 |
| rayjj | that's what I was not quite sure of. So we can ignore XPS -- good | 16:29.21 |
| kens | So the only stumbling block is that Henrys doesn't want to stick with a 'PostScript' format and would prefer TrueType/OpenType, even if it means the fonts are bigger ? | 16:29.26 |
| rayjj | henrys: isn't here to vote anymore ;-) | 16:29.46 |
| kens | Excellent! motion carried.... | 16:29.56 |
| chrisl | I must admit, I would be surprised if CPSI was shipping with Truetype fonts | 16:30.46 |
| henrys | you and your byzantine fonts I bet modern postscript rips are shipping with truetype... | 16:30.57 |
| rayjj | chrisl: It doesn't (at least the versions I have). | 16:31.21 |
| chrisl | henrys: Jaws and Harlequin both ship with Postscript fonts...... | 16:31.54 |
| henrys | rayjj: how old is the verson you have? | 16:32.26 |
| chrisl | But both can read Truetype fonts from disk | 16:32.30 |
| rayjj | chrisl: as GS can as well | 16:32.49 |
| henrys | truetype is quite compelling for us because we can do everything with truetype to include our new business | 16:33.19 |
| chrisl | rayjj: yeh, my point was that it's not due to lacking functionality that they stick with Postscript fonts | 16:33.22 |
| | henrys: I think it would be bad form to shoe-horn an inappropriate format into place just to fit in with SO | 16:35.40 |
| kens | TrueType for built-in fotns is not compelling for a PostScript itnerpreter | 16:36.20 |
| | And why do we care if the fonts for SOT are the same format as for GS ? | 16:36.32 |
| rayjj | kens: I agree with that. It's like the cart driving the horse. | 16:37.07 |
| Robin_Watts | SO can read type 1s and ttfs and otfs, I think. | 16:37.22 |
| | and probably CFFs too. | 16:37.36 |
| kens | well presumably it can read CFF as well then | 16:37.38 |
| | So we cna have them as CFF and everyone is happy | 16:37.48 |
| pedro_mac | it can - plus other proprietary formats like Bitstream | 16:38.03 |
| henrys | pedro_mac: you've done a compatiblity test sot with tt vs, type 2 | 16:38.40 |
| | ? | 16:38.41 |
| kens | If you insist on them being the same fonts for SOT we can easily turn the CFF fonts into OTF fonts | 16:39.21 |
| | THen the outlines are the same | 16:39.28 |
| pedro_mac | no (my âit canâ related to Robinâs comments but my typing is slower than kenâs ;) | 16:39.45 |
| kens | But as Robin_Watts pointed out earlier, the SOT fonts aren't 'full' fonts anyway, because he throws a lot of tables away, possibly ones which a PostScript interpreter *requires* | 16:40.04 |
| | I may be misunderstanding Robin's post of course | 16:40.37 |
| Robin_Watts | kens: My point was simply that the epage font system is pretty good at coping with different formats. | 16:41.00 |
| | I think we should do "the right thing" for gs/pcl, and SOT will fit in. | 16:41.13 |
| kens | Which is fair enough, but if you massage the fonts before shipping them, then whatever we use for a font format, you won;t be shipping the same fonts we do | 16:41.27 |
| Robin_Watts | the font requirements for SOT and gs are very different. | 16:41.28 |
| kens | Indeed | 16:41.35 |
| rayjj | the SO font market needs are for MS compatibility, not PS/PDF compatibility. I don't think it makes sense to try and force them together | 16:41.36 |
| Robin_Watts | rayjj: indeed. | 16:41.45 |
| kens | Do we use the URW fonts for SOT now ? I haven't been keeping up there | 16:42.19 |
| rayjj | AFAIK, SO has their own set of fonts that we inherited | 16:43.07 |
| | and Robin_Watts munged the metrics to solve some problems causing layout problems | 16:43.50 |
| kens | So why are we concerned about the fonts that ship with GS in regards to SOT ? I don;t think we can change the SOT fonts, as they require compatibility with fonts that we don't | 16:44.00 |
| pedro_mac | kens: weâre only using the URW dingbats fonts as far as I know | 16:44.06 |
| kens | doesn't see why the fonts used for GS need to consider SOT then | 16:44.25 |
| | Seems to me we *don't* want to use the fonts we use for GS with SOT | 16:44.42 |
| Robin_Watts | kens: I agree. | 16:44.49 |
| chrisl | Well, it was me that mentioned SOT, but I'm assuming that's what henrys meant by "our new business" | 16:45.03 |
| henrys | why the company would like to use 1 set of fonts instead of 2? | 16:45.03 |
| kens | Because the fonts are for different requirements | 16:45.19 |
| | And probably different font sets too | 16:45.27 |
| Robin_Watts | henrys: Why do you and sabrina have different sets of underwear? | 16:45.28 |
| rayjj | Robin_Watts: you are making an assumption | 16:45.49 |
| Robin_Watts | rayjj: haha! | 16:45.59 |
| kens | O.O | 16:46.06 |
| henrys | okay things are getting weird | 16:46.20 |
| Robin_Watts | sorry. | 16:46.25 |
| | superficially the requirements are similar, but when you look closely the needs are very different. | 16:47.19 |
| | I think 2 different font sets are entirely appropriate. | 16:47.36 |
| | Currently we have no crossover in the fonts we ship, right? | 16:47.52 |
| rayjj | probably less work than trying to make one set fit both needs | 16:48.03 |
| chrisl | henrys: it is worth identifying and taking advantage of cases where products have overlapping requirements, but it's not a good idea to decide we're going to use one set of fonts for everything, then hope to god we find a way to make it (sort of) work | 16:48.08 |
| Robin_Watts | SOT ships fonts that are compatible with the office fonts (and bends them to fit PDF etc). | 16:48.15 |
| henrys | you guys aren't thinking about the 135 build. There is huge overlap. | 16:48.25 |
| kens | What does htat have to do with SOT ? | 16:48.37 |
| Robin_Watts | henrys: Are you suggesting we'd ship the 135 with SOT ? | 16:49.00 |
| rayjj | henrys: the 136 font set ? | 16:49.06 |
| henrys | Robin_Watts: no | 16:49.22 |
| kens | retires in confusion | 16:49.39 |
| Robin_Watts | Then I'm as confused as kens. | 16:49.50 |
| henrys | I'm saying that if you look at a 136 build there are a large number of fonts common with SOT, whereas in the 35 it's isn't so many. | 16:50.23 |
| Robin_Watts | There are? | 16:50.45 |
| kens | But the requirements of the 2 products are quite different | 16:50.51 |
| | GS requires *PostScript* fonts which match the 135 font set (if we choose to ship it which is debatable) | 16:51.11 |
| rayjj | common by typeface name similarities ? | 16:51.14 |
| Robin_Watts | There are fonts that are graphically similar. They are not metrically identical, AIUI. | 16:51.33 |
| kens | SOT requires (AIUI) fonts which match a particular set of metrics matching certain Windows fonts | 16:51.44 |
| | The PS metrics may or may not match the WIndows font metrics | 16:52.09 |
| henrys | Robin_Watts: the pcl fonts were designed to match windows but drifted metrically. | 16:52.14 |
| kens | If they don;t then GS needs the PS ones and SOT needs the WIndows ones | 16:52.21 |
| | I;m not sure what PCL fonts have to do with this either, they aren't part of the 136 font set | 16:53.17 |
| | Another thing altogether | 16:53.28 |
| henrys | kens: the pcl fonts are a subset of the 136 | 16:53.49 |
| Robin_Watts | We have aspirations to ship a combined pcl/gs product, hence it makes absolute sense to try to amalgamate the 2 font sets. | 16:54.01 |
| kens | Well, if you say so. In that case we're covered by making them CFF fonts and making the PCL interpreer capable of reading CFF fonts | 16:54.17 |
| | WHich we already said..... | 16:54.48 |
| Robin_Watts | We don't have any such aspirations for sharing SOT and gs/pcl, so any amalgamation there would purely be driven by "it making our life easier" | 16:55.08 |
| | kens: indeed, not arguing that. | 16:55.17 |
| kens | Robin_Watts : I think we agree completely | 16:55.27 |
| henrys | kens: yes and now are discussing the virtues of one font type TT | 16:55.33 |
| kens | henrys no we aren't | 16:56.01 |
| | you want TrueType, the rest of us are unconvinced | 16:56.17 |
| Robin_Watts | and we *can't* ship identical fonts for SOT and gs, because the metric targets are different. | 16:56.21 |
| kens | Thewre is no reason for TT on GS/PCL | 16:56.25 |
| henrys | okay kens we aren't I am. | 16:56.43 |
| kens | Right | 16:56.47 |
| chrisl | TT would break GS - they just won't work | 16:56.57 |
| kens | And we are saying 'no, its a bad idea and has no benefits' | 16:56.57 |
| henrys | we get one delivery of fonts from URW. That single set is in the field for all products. That is a benefit to me. | 16:58.04 |
| kens | We can gvet font sharing between PS and PCL by using CFF, we can't use TT because it won't work with PostScript. we cannot share the fonts between GS and SOT so there is no point in worrying about that | 16:58.20 |
| chrisl | henrys: Not if it hampers the functioning of one or more of the products | 16:58.37 |
| kens | Its all very well to talk about PostScript disappearing, but at present it isn't and its the product generatign most of our revenue as far as I cna see, so it seems crazy to me to break it. | 16:59.19 |
| Robin_Watts | henrys: How about: We get one delivery of fonts from URW. We convert those to CFFs. We can use those in both gs/pcl. (And if we ever actually need to, in SOT too). | 16:59.51 |
| kens | Or if you insist, we cna convert the CFF to OTF | 17:00.19 |
| henrys | Robin_Watts: you can't cleanly convert to CFF that's another problem. | 17:00.24 |
| rayjj | PS disappearing is less likely than PCL going away | 17:00.34 |
| kens | There is no problem converting type 1 to CFF | 17:00.41 |
| | So get a type 1 dump. | 17:00.49 |
| chrisl | And TTF to CFF only loses hints - which we pretty much ignore anyway...... | 17:01.10 |
| rayjj | we have no definable need for TT | 17:01.11 |
| henrys | kens: there is a problem converting type 1 to tt contrary to popular belief. | 17:01.13 |
| kens | henrsy we are not talking about converting type 1 to TT | 17:01.25 |
| | We are talking about converting type 1 to CFF< and then, if required making the CFF into an *OPENTYPE* font | 17:01.45 |
| | OpenType fonts may contain CFF outlines | 17:01.56 |
| rayjj | which is what Adobe ships with Distiller | 17:02.06 |
| henrys | yes and I am talking about taking a TT deliverable from URW | 17:02.19 |
| kens | henrys and we're saying 'don't do that, take a type 1' | 17:02.31 |
| | Its still only one deliverable | 17:02.44 |
| | and ncna suit all purposes | 17:02.50 |
| rayjj | right WE DON'T NEED TTF | 17:02.50 |
| Robin_Watts | You say there is a problem converting Type1 to TT. Is there a problem converting TT to Type 1 ? | 17:03.09 |
| kens | Yes | 17:03.16 |
| rayjj | if URW wants to / can give us CFF, all the better | 17:03.24 |
| kens | If anythign its worse | 17:03.26 |
| Robin_Watts | ok, so we want a type1 deliverable from urw. | 17:03.35 |
| rayjj | or OTF with CFF outlines | 17:03.58 |
| | ? | 17:04.01 |
| kens | THat works too, we can pull the CFF otu easily | 17:04.24 |
| chrisl | Anything with Postscript outlines we can work with | 17:04.33 |
| rayjj | kens: good. That was a question, I wasn't sure | 17:04.44 |
| chrisl | (although I'd argue against Type 3!) | 17:04.50 |
| henrys | can someone tell me an example where CFF works and TT does not with ghostscript? | 17:05.03 |
| rayjj | I thought Type 2 was the one that was Type 1 with CFF | 17:05.12 |
| henrys | a specific example not capital letter shouting about what you want to do. | 17:05.24 |
| kens | henrys I can construct such a test case | 17:05.32 |
| rayjj | henrys: we have several examples in our comparefiles suite | 17:05.57 |
| chrisl | henrys: our PDF interpreter relies on being able to replace a charstring in a Postscript font in order to simulate a small caps font - that's one concrete case | 17:06.09 |
| henrys | and how was that test case fixed for monotype? | 17:06.13 |
| kens | dratted network, did I miss anything ? | 17:06.38 |
| kens | checks the logs | 17:06.42 |
| chrisl | For UFST we create a dummy charstrings dictionary which, if we're really using a microtype glyph we ignore, but we can use if it has been replaced | 17:07.16 |
| henrys | chrisl: and we can do that with TT as well right? | 17:07.35 |
| rayjj | yuck!! (IMHO) | 17:07.51 |
| kens | agrees totally | 17:07.57 |
| chrisl | henrys: no, because Type 42 already has a charstrings dictionary with contents specific to Type 42 fonts | 17:08.11 |
| kens | I don't see any benefit from going to TTF and I forsee much trouble | 17:08.12 |
| rayjj | henrys: what is so wondeful about TT ? | 17:08.13 |
| kens | We can do a single deliverable by going to CFF | 17:08.28 |
| | TTF gains us nothing as far as I can see | 17:08.36 |
| henrys | rayjj: oh jesus ... having one font set. | 17:08.38 |
| kens | Yes one CFF font set | 17:08.47 |
| | GS can use it SOT can use it, where is the problem ? | 17:08.56 |
| chrisl | mupdf can use it..... | 17:09.07 |
| rayjj | henrys: see what kens wrote: We can do a single deliverable by going to CFF | 17:09.08 |
| chrisl | What benefit does TTF have over CFF? | 17:09.23 |
| kens | Or even OTF | 17:09.30 |
| | With CFF otulines | 17:09.35 |
| rayjj | henrys: is there something else that you are looking for from TT ? | 17:09.53 |
| | TT has advantages IFF we were to use the hinting, but we don't do that, AFAIK | 17:10.42 |
| chrisl | Oh, crap, I have to go..... | 17:10.42 |
| henrys | I'd almost bet you won't get through the SOT tests with CFF, but that's an experiment to be done. | 17:10.54 |
| kens | TT doesn't really do hinting, not like PostScript does | 17:10.57 |
| | henrys wel;l we have concrete cases where TT fonts in PostScript won't work | 17:11.15 |
| henrys | I think TT is a more common, powerful format than CFF - if I had to pick a winner down the road I'd say TT... on an on I have a lot of reasons. | 17:11.31 |
| rayjj | kens: I thought that's what the "program" part does, but I don't really know | 17:11.41 |
| kens | rayjj its sort of supposed to be, but TT hinting is dreadful. | 17:11.54 |
| henrys | freetype is probably more cabable with TT - T1 was bolted on as an afterhought | 17:11.58 |
| kens | henrys CFF outlines are part of the OpenType spec, TT is dead, the future is OpenType | 17:12.10 |
| | henrys, not so | 17:12.21 |
| | FreeType has handled Type 1 for ever | 17:12.29 |
| Robin_Watts | Another random question: What fonts ship with acrobat reader? | 17:12.32 |
| kens | OTF | 17:12.36 |
| chrisl | henrys: The freetype CFF engine is from Adobe, so....... | 17:12.42 |
| kens | If it ships any | 17:12.43 |
| Robin_Watts | otf's it seems. | 17:13.03 |
| kens | Reader ships with two japanes fonts, both opentype fomrat | 17:13.09 |
| henrys | chrisl: that's another reason to go with TT | 17:13.09 |
| rayjj | Acrobat Pro (Distiller) includes OTF with CFF outlines | 17:13.16 |
| kens | No, its a reason to go with OpenType | 17:13.18 |
| chrisl | henrys: WHAT?? | 17:13.23 |
| kens | TrueType does not support CFF | 17:13.33 |
| | SO if you want to use the Adobe CFF engine you need to use OpenType, not TrueType | 17:13.50 |
| | Again, TrueType has been supreceded by OpenType, and OpenType includes CFF outlines as part of the specification | 17:14.11 |
| | Future proofing says OpenType, not TrueType | 17:14.21 |
| Robin_Watts | Reader 11 has AdobePiStd, 4xCourier, 4xMinionPro, 4xMyriadPro, all as otf. | 17:14.22 |
| henrys | kens: I am talking about using open type | 17:14.30 |
| kens | Henrys then please stop saying TrueType or TT | 17:14.42 |
| henrys | Robin_Watts: quadratics or cubic outlines? | 17:14.54 |
| kens | If you get OTF fonts with CFF outlines then we are happy | 17:14.56 |
| Robin_Watts | henrys: How can I tell? | 17:15.04 |
| rayjj | We agree on OTF with CFF outlines | 17:15.08 |
| kens | CFF outlines use cubics | 17:15.11 |
| | If you want to know if a font is TT or CFF otulines you have to open it and look | 17:15.45 |
| rayjj | (raph would prefer if it used b-splines ;-) ) | 17:15.57 |
| henrys | rayjj: no we don't - TT OTF is an option. | 17:16.19 |
| kens | By the way Reader also ships with three TYpe 1 fonts | 17:16.29 |
| henrys | I'd like to also use the same outlines with all products. | 17:16.37 |
| rayjj | right .PFB format | 17:16.42 |
| kens | henrys its the option we cna agree on | 17:16.44 |
| | We cannot agree on TrueType outlines | 17:16.58 |
| | The fonts shipped with reader have 'PostScript outlines' | 17:17.39 |
| | ie CFF | 17:17.43 |
| Robin_Watts | Ok, cubics. | 17:17.46 |
| rayjj | henrys: why would we prefer to get TT outlines ? We can get either from URW | 17:18.03 |
| henrys | rayjj: well first we should use 1 type I hope we can agree to that. | 17:18.31 |
| kens | If we are going to use one type, then it has to be CFF otulines | 17:18.48 |
| | so we go to OpenType fonts with CFF outlines, which is future proof, as its the current spec, cna be used by all products | 17:19.17 |
| henrys | my view is TT is more future proof than CFF but I confess CFF has huge advantage with PS and PD> | 17:19.49 |
| | PDF | 17:19.51 |
| Robin_Watts | henrys: It makes perfect sense to want to use a single type for gs/pcl. I don't think anyone is disagreeing with that. | 17:19.53 |
| rayjj | kens: and probably compresses better than the pfb fonts we have in gs/Resource/Font now ??? | 17:20.20 |
| kens | henrys, we aren'#t talking about TrueType, we are talking about OTF | 17:20.27 |
| | You can't say TT is more future proof than CFF because its already behind the times. OTF is future proof and includes CFF as part of the specification | 17:20.55 |
| henrys | I'm talking about OTF with TT quadratic curves vs. OTF CFF cubic curves. | 17:21.05 |
| kens | Then tha'ts not any more future proof than OTF with CFF outlines. | 17:21.25 |
| | They have equal status in the specification | 17:21.31 |
| | It would be another release of OTF before they could remove the support for OTF | 17:21.45 |
| | CFF* | 17:21.50 |
| | And by your reasoning we con't have to care about PostScript by then | 17:22.06 |
| rayjj | henrys: OK, so now you get down to a technical difference that can be argued. Which is BETTER cubic or quadrativ curve outlines | 17:22.07 |
| Robin_Watts | quadratics can be converted to cubics trivially. | 17:22.27 |
| rayjj | considers that a matter of religion | 17:22.30 |
| kens | isn't bothered either way | 17:22.43 |
| henrys | Robin_Watts: they cannnot the hinting is different ... | 17:23.06 |
| kens | From a technical perspective the hinting in CFF/type 1 is superior (when carefully created) to that available in TrueType | 17:23.09 |
| Robin_Watts | henrys: Right. How much hinting do we do? | 17:23.21 |
| rayjj | I can't get excited about which "looks better" since we've never had a single customer complaint caused by the shape of the curve (AFAIK) | 17:23.37 |
| kens | On anything 600 dpi or above hinting is pretty much irrelevant | 17:23.47 |
| rayjj | kens: as is curve shape | 17:23.59 |
| Robin_Watts | but do we actually do any hinting, ever ? | 17:24.03 |
| kens | On anything below, PostScript hinting is superior | 17:24.08 |
| | Robin_Watts : yes | 17:24.11 |
| Robin_Watts | OK. I did not know that. | 17:24.22 |
| kens | Both in TrueType and PostScript | 17:24.22 |
| | You can't avoid TrueType hinting exaclty, since its (more or less) built into the font program | 17:24.46 |
| | THat's a simplification, but mostly true | 17:24.55 |
| rayjj | Robin_Watts: when we get some funky TT fonts that misuse the pgm, we have to use the hints | 17:24.58 |
| Robin_Watts | yeah, SOT has some workarounds for fonts that require hints otherwise look very odd. | 17:25.18 |
| kens | With FreeType we always use the TT hints I believe (chrisl woudl know better) | 17:25.22 |
| henrys | Robin_Watts: no hints in SOT at low res? | 17:25.26 |
| rayjj | Robin_Watts: Dynalab, iirc. But URW doesn't do that kind of nonsense | 17:25.27 |
| Robin_Watts | henrys: No hints in SOT at all. We antialias. | 17:25.45 |
| henrys | yes hinting is enabled in ghostscirpt | 17:25.48 |
| kens | In any event, for built-in fonts this is not really a problem, as we expect the fonts to be of decent qulaity | 17:25.53 |
| | Essentially we have a choice of two outline types, CFF or TrueType. | 17:26.35 |
| | If we go with TrueType we will have problems in Ghostscript which will be difficult, possibly impossible, to overcome. | 17:26.55 |
| henrys | kens: and 2 hinting mechanisms one arguable superior to the other. | 17:27.09 |
| kens | If we go with CFF outlines all our products will work. | 17:27.10 |
| | henrys, yes CFF hinting is better | 17:27.18 |
| rayjj | has to go. bbiaw | 17:27.47 |
| kens | I am going to have to go as well, getting late here | 17:28.01 |
| henrys | kens:I thought TT hinting was more powerful. | 17:28.09 |
| kens | No, I don;t believe that is true, if anything its MS propaganda | 17:28.24 |
| | Type 1 fotns can have controls such as counters, which ensuyre that the spacing between horizontal features is consistent, which is difficutl (or impossible) to achieve with TrueType | 17:28.59 |
| henrys | I can agree with CFF if we take SOT out of the discussion. | 17:29.20 |
| kens | IME PostScript (T1 or CFF) hinting is better than TrueType | 17:29.21 |
| | henrys well you waon't get chris or me to agree to TrueType on Ghostscript | 17:29.42 |
| | We've had too much trouble with TT fonts | 17:29.52 |
| Robin_Watts | henrys: OK, so it sounds like we've reached an agreement on OTF fonts with CFF outlines for gs/pcl. | 17:30.40 |
| kens | I would say that well constructed fonts using either outline type are of adequate quality for all practical purposes | 17:30.55 |
| Robin_Watts | henrys: Why do you think that SOT will be unable to cope with OTF fonts with CFF outlines? | 17:31.04 |
| | or do you just think they will be too big? | 17:31.23 |
| | because we can't do our table stripping thing ? | 17:31.39 |
| kens | CFF fonts are not unduly large, as I recall they are around 30-50% smaller than an equivalent type 1 | 17:32.09 |
| | But I don't know how they would compare to your stripped TT font | 17:32.22 |
| henrys | Robin_Watts: I'm concerned there would be a customer expectation for truetype with windows-centric thing like an office app... I also know it will be work to look at all the changes that will be introduced by going from quadratices to cubics. | 17:32.30 |
| kens | I don't believe that a change from quadratic to cubic curves will be noticed | 17:32.54 |
| Robin_Watts | kens: ATS will notice it. | 17:33.21 |
| henrys | kens: it will be noticed by the regression tests | 17:33.34 |
| kens | Oh yeah, but I meant customer's not automated testing tools | 17:33.35 |
| | We get changes to fonts all the time when we alter the font rendering engine. Its a one-time hti right ? | 17:34.08 |
| Robin_Watts | henrys: I think most customers won't give a hoot what format font we use, as long as it looks reasonable. | 17:34.29 |
| | Also, a lot of the time, customers have their own fonts, and as long as we drive them OK, they are happy. | 17:34.53 |
| henrys | Robin_Watts: and dollars to donuts they are TT fonts... so they get to use our untested scaler ;-) | 17:35.40 |
| | assuming we move to cff | 17:36.28 |
| kens | Also, if we change the GS fonts to be TrueType, we will have the same level of work looking at all the automated GS tests which will be different as well. Selecting TT fonts doesn't get ius over that. And if we use different fonts (which the URW ones will be) then htey will *also* invoolve lots of diffs in the automated tests | 17:36.29 |
| Robin_Watts | henrys: You're assuming we move *completely* to cff. | 17:36.54 |
| kens | If the CFF rendering doens't work then it needs to be fixed | 17:37.16 |
| | And we are talking about the fonts we ship, so they *will* be tested | 17:37.30 |
| | Any other fonts are in the same position they are now. | 17:37.41 |
| | And as I said, if we change the existing fonts for URW TT fonts we will still (I presume) get a shed load of ATS diffs to look at | 17:38.04 |
| Robin_Watts | I am prepared to believe that there is some overlap between the current ttf fonts and the supposed single format copy of the 135 fonts, but I don't believe that the former is a subset of the latter. | 17:38.18 |
| | hence we'd still presumably be using some ttf fonts. | 17:38.27 |
| kens | For those fonts which we wouldn't get from URW, yes that seems right, we would still use whatever we have now | 17:38.58 |
| | Anyway, I really do have to push off, goodnight all | 17:39.47 |
| Robin_Watts | night kens. | 17:39.52 |
| henrys | Robin_Watts: if you stuck with TT's you'd be using the same scaler for almost everyting. I'd be very surprised to see many CFF outlines (type 2) in word and ppt documents, but I might be mistaken. | 17:42.35 |
| Robin_Watts | henrys: word and ppt documents don't have embedded fonts (AFAIK) | 17:43.03 |
| | henrys: All font outlines get converted to Wasp_Paths, and all get rendered using the same code. | 17:43.43 |
| | there is no hinting to worry about. | 17:43.54 |
| | hence, I'm not sure there is much of an issue. | 17:44.08 |
| | (yes,we might hit cases in the otf code where it falls over as it's been used less than the ttf code, but that's just a matter of fixing any bugs we find) | 17:44.47 |
| henrys | Robin_Watts: probably best to just treat sot separately. We do need gs/pcl on the same page though | 17:45.46 |
| Robin_Watts | yes. unarguably so. | 17:45.58 |
| henrys | from a PCL perspective TT is the clear choice, there is no support for CFF in the language. | 17:47.20 |
| Robin_Watts | henrys: How can the PCL language interact with a font? | 17:48.43 |
| | PS programs can get the outlines (and encodings?) of a font, right? | 17:49.15 |
| | does PCL have any facilities like that? | 17:49.25 |
| | I thought PCL could say "here is an embedded TT" and then use it for text, but that was about all? | 17:50.02 |
| henrys | Robin_Watts: I don't understand the distinction - you give PCL part of a truetype and a mapping and it uses the font with the encoding ... cmaps etc. What's difference are you point out? | 17:52.00 |
| Robin_Watts | You say "here is an embedded font", and then "using that font, display this text". | 17:52.41 |
| henrys | I use the same scaler for embedded and resident fonts. | 17:52.44 |
| Robin_Watts | Is that fair? | 17:52.46 |
| henrys | yes | 17:53.17 |
| Robin_Watts | so, why does it matter if we make *our* PCL capable of taking both ttfs and otfs ? | 17:53.45 |
| henrys | I'm merely saying that if PCL were standalone TT wouild be the obvious choice. | 17:53.53 |
| Robin_Watts | henrys: right. | 17:54.02 |
| henrys | why support 2 formats. | 17:54.08 |
| | ? | 17:54.09 |
| Robin_Watts | because otfs are smaller? (dunno if they are, but it would be a reason) | 17:54.36 |
| | or faster to use? (again, same proviso) | 17:54.45 |
| | or makes our life easier by only having to wrangle one set of fonts. | 17:54.59 |
| | http://blog.typekit.com/2010/12/02/the-benefits-of-opentypecff-over-truetype/ | 18:09.21 |
| | on average OT/CFF font files are 20% to 50% smaller than comparable TrueType fonts | 18:09.31 |
| henrys | Robin_Watts: yeah I was just reading that... his last paragraph picks up a few of my points in favor of tt | 18:10.29 |
| mvrhel_laptop | Robin_Watts: if you get a chance, can you look over the commits in my mupdf repos? | 18:10.42 |
| Robin_Watts | been around longer - who cares? | 18:10.50 |
| | better on AA'd environment - we don't care for gs and pcl, right? | 18:11.23 |
| | and SOT doesn't hint, so that benefit is lost. | 18:11.32 |
| | and windows/mac are invested in TT. Again, we don't care, cos we're handling them ourselves. | 18:11.53 |
| | mvrhel_laptop: Sure. | 18:12.03 |
| mvrhel_laptop | thanks! | 18:12.13 |
| henrys | Robin_Watts: that surprises me there are some asian fonts that I think you won't give acceptable renderings for without hinting. | 18:12.14 |
| Robin_Watts | the dynalab ones? | 18:12.35 |
| mvrhel_laptop | now I will go see what is going on with this .net stuff | 18:12.56 |
| Robin_Watts | mvrhel_laptop: first commit.... | 18:13.52 |
| mvrhel_laptop | starting from top or bottom? | 18:14.05 |
| Robin_Watts | I might have been tempted to move the blocks[kk].TextLines[jj].TextCharactersAdd(textchars) to after the catch. | 18:14.21 |
| | Thus removing the duplication. Unless that's the line that might have thrown ? | 18:14.39 |
| | starting from the bottom. | 18:14.56 |
| | probably not important. | 18:15.20 |
| henrys | oh god I'm old: https://lists.gnu.org/archive/html/freetype-devel/2003-01/msg00013.html | 18:15.38 |
| | I remember that dynalab nightmare | 18:16.10 |
| Robin_Watts | henrys: Right. We have a workaround in the epage font manager for the dynalab fonts. | 18:16.44 |
| mvrhel_laptop | Robin_Watts: no its the convert. I can do that | 18:17.37 |
| | lets me have fun with git trying to fix it ;) | 18:18.27 |
| Robin_Watts | otherwise all looks good. | 18:19.24 |
| | mvrhel_laptop: easiest way is to make the change, then commit it as a new commit called 'Fix'. | 18:19.50 |
| | Then git rebase -i HEAD~10 and move the 'fix' line down to just after where it's needed, and change it from 'pick' to 'f'. | 18:20.17 |
| mvrhel_laptop | right | 18:20.27 |
| | oh | 18:20.34 |
| | I did not know that f was an option. I was thinking that I would get them next to one another and then squash them | 18:21.02 |
| Robin_Watts | f is exactly the same as squash, except it discards the second commits message. | 18:21.26 |
| | (f = fix) | 18:21.53 |
| mvrhel_laptop | oh cool | 18:21.58 |
| | ah. I see. He is trying to open the file twice. Second one is giving him the -1 return | 18:55.29 |
| | hmm no that is not the issue | 18:57.07 |
| henrys | mvrhel_laptop: I was reading windows 10 will be the same across devices, is the desktop going away .. have you heard anything from your sources? | 19:00.18 |
| mvrhel_laptop | oh he has the path wrong too | 19:00.26 |
| | henrys: no the desktop is not going away. everyone I spoke with said that there really is not that big of a difference between 8.1 and 10 | 19:01.02 |
| henrys | those tiles really annoy me. | 19:01.28 |
| | I can't think I'm alone | 19:01.39 |
| mvrhel_laptop | I have gotten used to them. I really only use it as a means to get to my desktop apps quickly | 19:02.15 |
| | like a start menu | 19:02.21 |
| | ok. problem solved with the .net stuff | 19:02.33 |
| | he had the wrong path hardcoded for his file and he was opening the file twice | 19:02.52 |
| kens | henrys to answer your earlier comment, if PCL were the only issue then *clearlY* TrueType would be the way to go. If Ghostscript werethe onl;y issue then *clearly* PostScript is the way to go. However, you want to merge the 2 (I understand the reasonaing, and I'm not objecting). In that case we look at the capabilities of the languages. PCL effectively cannot interact with the font to any meaningful extent. PostScript, however, | 19:04.02 |
| | is a programming language, it is capable of readin, dissecting and altering the font in many interesting and varied ways. | 19:04.02 |
| | As such, it is important that our default fons behave as PostScript fonts for Ghostscript, whereas, as far as I understand it, it is not important to PCL that a font behave as a TrueType font, it simply has to behave as a font. | 19:04.36 |
| | This is why it makes much more sense to use a PostScript font for the combined package | 19:04.52 |
| | I am interested in Robin's finding that CFF OTF fonts are smaller than comparable TT fonts. | 19:05.33 |
| | That alone should make it important to use a CFF otuline font for the combined package rather than a TrueType outline | 19:05.54 |
| | I disagree with teh blog you quote as regards hinting, I don;'t find TT hints especially powerful or well implemented. A good TrueType or CFF font is at least as good IMO | 19:08.08 |
| | The problem from my point of view is that as the rasteriser, I don't want the font to tell me *exactly* where to put the pixels, as that interferes with drop-out correction for example. | 19:09.03 |
| | I'd rtather have the hints be exactly that, hints, not directives | 19:09.14 |
| | As for hand-made bitmaps, yech, how 20th century | 19:09.45 |
| | Again he declares that CFF outlines are smaller, so that surely should be an important point to consider. | 19:10.13 |
| kens | heads off again. | 19:10.29 |
| henrys | for the logs kens I think much of the article should be dismissed and we should look at other sources. The Adobe Typekit blog is not a good source for TT info. | 19:12.15 |
| Seq | Is there a way to get the ghostscript version when processing postscript? I can output "product" to return "GPL Ghostscript", but "revision" doesn't seem to be valid | 19:21.23 |
| | "revision" being in postscript language reference | 19:22.01 |
| henrys | revision works | 19:22.16 |
| | ^^^ Seq | 19:22.50 |
| Seq | yeah, actually. I just realized it's an int, and I'm trying to use it in concatstrings. | 19:23.12 |
| | I'm still coming up to speed on postscript, so I guess sometimes I guess I miss the simple things :p | 19:23.53 |
| mvrhel_laptop | Robin_Watts: so were the other commits ok? | 19:24.53 |
| Robin_Watts | mvrhel_laptop: Yes. | 19:25.08 |
| mvrhel_laptop | ok thanks | 19:25.22 |
| Seq | thanks henrys. `revision 5 string cvs` gets me what I was looking for. | 19:28.22 |
| henrys | Seq I don't see postscript programmers much anymore | 19:29.57 |
| | school thing? | 19:30.29 |
| Seq | No, work. | 19:30.55 |
| | Most of our source documents are pdfs. We've been using a third-party utility to do some conversions on it, but have had issues as new pdf revisions have come out | 19:32.57 |
| | basically, we'd like to just use upstream ghostscript, which typically supports whatever we see by the time we see it. | 19:34.05 |
| | The needs for this are pretty modest: Concat a bunch of pdfs, scale them, add a border and page count, and use pdfmarks to get bookmarks to key places in the final document | 19:35.12 |
| Robin_Watts | Seq: Who is "we" ? | 19:35.17 |
| | We (Artifex) are the developers of ghostscript. | 19:35.38 |
| | We release it for free, unsupported under the GNU GPL. | 19:35.59 |
| | We also provide both support contracts and commercial distribution agreements to those that need them. | 19:36.29 |
| | If you are happy to work unsupported/unwarrantied etc, and you comply with the GNU GPL then you are of course welcome to use it for free. | 19:37.01 |
| | But if you want support, or want to distribute it free from the strictures of the GNU GPL, we can help. | 19:37.25 |
| Seq | we're fine with the gpl currently. I've suggested support to my team, but I don't know the status of that yet | 19:38.27 |
| henrys | Robin_Watts: where is the compressor you use in sot I want to try it. | 19:44.12 |
| | ? | 19:44.15 |
| | for truetype fonts | 19:44.27 |
| Robin_Watts | looking. | 19:44.49 |
| | It's called font-ttconvert, but I can only find a binary at the mo... still looking. | 19:45.57 |
| | Ah, right. What platform? | 19:46.35 |
| | "scripts/linuxbuild.py font-ttconvert" should do it. | 19:47.11 |
| henrys | is it a simple c program I can compile? | 19:47.14 |
| Robin_Watts | henrys: no. | 19:47.36 |
| | it uses various bits of the epage tree, it seems. | 19:47.53 |
| henrys | oh lord | 19:48.00 |
| | I can't get a break today ;-) | 19:48.24 |
| | thanks though | 19:49.09 |
| Robin_Watts | wanna swap? :) | 19:49.33 |
| henrys | had this crazy idea he'd look at a 200 line C program and see what was going on. | 19:49.55 |
| Robin_Watts | well, if you just want to look at it... | 19:50.16 |
| | libraries/font/efont/ttconvert.c is the main file. | 19:51.03 |
| henrys | thanks I'll have a look. | 19:51.17 |
| Robin_Watts | hmm. That's fundamentally uninteresting though. | 19:51.32 |
| | libraries/font/efont/fromtt.c | 19:52.03 |
| | It's not brain surgery. | 19:52.36 |
| mvrhel_laptop | bbiab | 23:04.15 |
| | Forward 1 day (to 2015/01/28)>>> | |
IRC Logs