| | <<<Back 1 day (to 2014/02/05) | 2014/02/06 |
| Robin_Watts | which explains a lot of the formatting differences. | 00:00.06 |
| henrys | Robin_Watts: good news | 00:00.22 |
| | relatively | 00:00.29 |
| Robin_Watts | So, either we need to source new fonts with the correct metrics... | 00:00.43 |
| | or we need to retrofit the metrics to the existing fonts. | 00:00.52 |
| | The epage font engine has a mechanism whereby a set of metrics can be overlaid onto a font. | 00:01.19 |
| | it uses that to get exact matches for the pdf base 14 fonts. | 00:01.36 |
| | so I could look at using that. | 00:01.45 |
| henrys | Robin_Watts: have we verified the line advance is wrong on say an android device - are they hacked to work on a different resolution display perhaps? | 00:02.05 |
| Robin_Watts | but then I'd need to get the metrics for the relavent fonts from somewhere. | 00:02.12 |
| | henrys: We have not verified that. | 00:02.24 |
| | but the epage fonts don't do hinting, hence the metrics are the metrics. | 00:02.39 |
| | resolution shouldn't come into it. | 00:02.45 |
| henrys | Robin_Watts: okay | 00:02.53 |
| Robin_Watts | So, is it OK for me to write code to use (say) freetype to extract the metrics for the fonts from the windows ones? | 00:03.19 |
| | Does that count as copyright violation? | 00:03.30 |
| henrys | Robin_Watts: I do rather cringe at that but I can't imagine we'd get in trouble for it. | 00:05.20 |
| Robin_Watts | OK. | 00:05.46 |
| | So I'll try to see what happens when we put the proper metrics on top of the Artifex fonts. | 00:07.12 |
| | "proper" | 00:07.17 |
| henrys | Robin_Watts: do you have an example file that causes pagination to be incorrect? I have smart office on my android - the test file marcos posted doesn't fill the page so I really have no way to see if it is wrong. | 00:23.55 |
| | Robin_Watts: if not I can just edit this file. | 00:24.29 |
| | Robin_Watts: nvm the app is wrong also. | 00:31.31 |
| | Robin_Watts: I don't understand how they get away with this almost everything is wrong, because of something that looks like a straightforward thing to fix. I wonder if we're missing something. | 00:36.15 |
| kens | chrisl I just got a weekly regression report (UFST with make uproduct), and it only contains one line : | 08:37.18 |
| | compileFail: pcl6 | 08:37.18 |
| | I'm assuming this is because you changed the UFST version ? | 08:37.30 |
| chrisl | Could be. If that's all the information there is, it's not easy to tell | 08:45.57 |
| | Ah, it's because the make invocation is wrong | 08:47.11 |
| kens | OK I'll leave it to you and Marcos :-) | 08:56.11 |
| chrisl | The worry is that means that the PCL FAPI/UFST code hasn't been tested in the weekly tests at all :-( | 08:57.24 |
| kens | What, not even when it wasn't failing to compile ? | 08:57.43 |
| | I'm sure its the first time I;ve seen this error | 08:57.55 |
| chrisl | No, make uproduct would build the *old*, non-fapi based integration | 08:58.12 |
| kens | Oh.... | 08:58.18 |
| | THat isn't ideal | 08:58.25 |
| Robin_Watts | kens, chrisl: Font stuff if I may... | 10:14.21 |
| kens | OK | 10:14.26 |
| | I have time right now, good timing | 10:14.32 |
| Robin_Watts | It seems that by bundling the windows fonts into the ghostdocs thing, the layouts are MUCH closer. | 10:14.48 |
| kens | Not entirely surprising | 10:14.59 |
| | Word will use the WIndows dfont | 10:15.07 |
| | door, brb | 10:15.11 |
| Robin_Watts | so the existing ghostdocs fonts are clearly not clones, as we had been lead to believe. | 10:15.18 |
| | so, either we need to source whole new fonts... | 10:15.45 |
| kens | They are clones of the PostScript fonts, not the WIndows fonts | 10:15.56 |
| | Unless you mean different fonts | 10:16.04 |
| Robin_Watts | The ghostdocs fonts are not the artifex fonts. | 10:16.17 |
| kens | Oh, OK differetn fonts then | 10:16.30 |
| Robin_Watts | ...or we need to somehow enforce the proper metrics onto whichever fonts we use. | 10:16.59 |
| | The picsel font engine has the ability to force metrics on a font (as that's what it does for PDF fonts) | 10:17.28 |
| kens | Hmm, enforcing metrics is usually not good. As teh designs may not be the same, so you risk character positioning problems | 10:17.34 |
| Robin_Watts | yes, it relies on the metrics being 'close'. | 10:17.59 |
| chrisl | I assume these are Truetype fonts? | 10:18.01 |
| kens | I was assuming that too | 10:18.08 |
| Robin_Watts | The picsel fonts are ef1's. | 10:18.10 |
| | the windows ones are .ttf or .ttc. | 10:18.23 |
| kens | I assume the ef1 is a pixsel format ? | 10:18.35 |
| | Picsel* | 10:18.41 |
| Robin_Watts | picsel or EFF, yes. | 10:18.47 |
| kens | Could we use the Artifex TT fonts ? | 10:19.05 |
| chrisl | You can probably use fontforge to extract metrics from the Windows fonts | 10:19.17 |
| Robin_Watts | My plan is to use the artifex TT fonts, and to overlay the correct metrics onto them. | 10:19.23 |
| kens | Hmm, so they don't match either ? | 10:19.34 |
| Robin_Watts | chrisl: Right. I was planning to extract the metrics using Freetype, but if fontforge can do it nicely... | 10:19.53 |
| | kens: I was assuming that they wouldn't match. | 10:20.05 |
| kens | Or you can use ttfdump | 10:20.07 |
| Robin_Watts | OK, ttfdump sounds good. | 10:20.21 |
| kens | Robin_Watts : might be worth checking, but the easiest way is probably to take both sets of metrics anyway | 10:20.28 |
| Robin_Watts | assuming that gives me a table I can work with. | 10:20.33 |
| chrisl | What format does the picsel code expect the metrics to be in? | 10:20.39 |
| kens | ttfdump writes the TT tables in ascii human-readable form | 10:20.49 |
| Robin_Watts | a custom compressed format, I believe. | 10:20.58 |
| chrisl | Of course, why use a standard format? :-( | 10:21.18 |
| Robin_Watts | I fear it may be my own custom compressed format, cos it was implemented for PDF, so I suspect I was involved. | 10:21.19 |
| kens | :-) | 10:21.26 |
| Robin_Watts | Failing that it would either be paulgardiners, or daves format :) | 10:21.37 |
| kens | chrisl bear in mind that phoes are still limited resoruce devices | 10:21.44 |
| | So minimum resource use is still important | 10:21.58 |
| | Robin_Watts : ttfdump dumps *all* the tables in a TT font | 10:22.33 |
| Robin_Watts | where can I get ttfdump front ? | 10:22.53 |
| kens | Depending what you need it may be easier just to write a custom tool to extract metrics, its not hard | 10:22.54 |
| Robin_Watts | s/front/from/ ? | 10:23.08 |
| kens | Er,, the net ? Or I cna send you a copy | 10:23.09 |
| chrisl | kens: I wouldn't have thought there was much to gain over compressed pfms, tbh | 10:23.34 |
| kens | who knows, I haven't thought about it :-) | 10:23.52 |
| Robin_Watts | kens: I see the link. | 10:23.55 |
| chrisl | Robin_Watts: it's easily installable on Linux, probably OS X too | 10:23.55 |
| Robin_Watts | kens: I see a ttfdump from microsoft ? | 10:24.12 |
| kens | Its an old MS tool yes | 10:24.22 |
| | I've been using it for years | 10:24.38 |
| Robin_Watts | ok, so it's the right one. perfect. ta. | 10:24.40 |
| chrisl | Oh, I was thinking of ftdump..... | 10:24.45 |
| kens | but like I say it dumps *everything*, if all you need are the metrics, it may be easier to write a C program to get what you need, I could kock one up in a couple of hours. TTF is not hard | 10:25.25 |
| | s /kock/knock/ though in some senses both are probably true | 10:26.04 |
| Robin_Watts | kens: If I was going to write code, I'd probably use freetype to extract the metrics cos that way it wouldn't be tied to ttf. | 10:26.04 |
| chrisl | kens: depends if you need the metrics "hinted" or not..... | 10:26.24 |
| kens | PS metrics and TT metrics are somewhat different | 10:26.26 |
| Robin_Watts | This also makes me wonder if hinting comes into play during layout. And kerning. | 10:26.51 |
| kens | Excepting the mad usage of 'hinting' in TT dn't have thought it made much difference | 10:27.01 |
| | Robin_Watts : I would say that, except for the stupid things some people do with TT 'hintin'g it isn't relevant | 10:27.22 |
| | And I very much doubt that any layout app uses hinted outlines | 10:27.34 |
| chrisl | Robin_Watts: I thought the picsel code didn't do hinting? | 10:27.46 |
| Robin_Watts | chrisl: It doesn't. | 10:27.54 |
| | but I think it may do kerning. | 10:28.01 |
| chrisl | kerning is/should be separate from glyph metrics | 10:28.24 |
| kens | Yes | 10:28.29 |
| | you need kerning tables for that | 10:28.36 |
| Robin_Watts | And if word lays out "AVAVAVAVAVAVAV" without kerning, it's going to get a wider string than if it kerns it. | 10:28.39 |
| kens | Yes | 10:28.44 |
| Robin_Watts | which will affect line breaking points. | 10:28.47 |
| kens | But that's not hinting... | 10:28.55 |
| | layout apps *must* use kerning, but I doubt they think about hinting | 10:29.09 |
| Robin_Watts | OK, so ignore hinting. | 10:29.12 |
| kens | hinting *shouldn't* make much difference to the sizes of a glyph | 10:29.24 |
| Robin_Watts | kens: So... presumably that means metrics alone are not enough. | 10:29.29 |
| | I need kerning data too. | 10:29.36 |
| kens | mertrics are only part of the problem for a layout app | 10:29.41 |
| | In terms of printing, we don't need to worry about kerning because hte layout app moves the glyphs | 10:30.07 |
| | for layout you need kerning certainly | 10:30.15 |
| Robin_Watts | But we are doing the layout. | 10:30.17 |
| kens | Also H&J | 10:30.19 |
| | oh and tables of word breaking points (I forget the proper term) | 10:31.02 |
| Robin_Watts | Word files get text strings, and ghostdocs has to lay those strings out. | 10:31.15 |
| chrisl | The "kern" table is optional in TTFs, and is often missing (at least, in the PS/PDF world) | 10:31.15 |
| Robin_Watts | to give paragraphs. | 10:31.31 |
| kens | Robin_Watts : yes, the layout engine is supposed to consult the kerning tables first to determine word lengths | 10:31.39 |
| Robin_Watts | Right, so the kerning stuff *is* an issue for us. | 10:31.55 |
| kens | then it looks at teh justification to see if ti can fit the words to the line length | 10:31.59 |
| | Robin_Watts : yes, sorry didn't mean to be confusing, I'm agreeing there | 10:32.12 |
| Robin_Watts | so, purely overlaying metrics will not solve the problem :( | 10:32.31 |
| kens | Just mentioing that we don't usually deal with this, because we're at the print end, so we don't have a lot of experience here | 10:32.37 |
| Robin_Watts | I need to overlay metrics and kerning information. | 10:32.48 |
| kens | Yes | 10:32.52 |
| | kerning is important | 10:33.00 |
| chrisl | You may only need the kernel data | 10:33.26 |
| kens | I'msure word will use kerning tables | 10:33.27 |
| chrisl | kerning.... | 10:33.31 |
| Robin_Watts | while I think it's OK to steal the metrics from a font so we can ensure compatibility with it, stealing more and more data gets dodgier :( | 10:33.54 |
| | chrisl: I am not familiar with how kerning data is held. | 10:34.07 |
| chrisl | kerning is just another metric, really | 10:34.14 |
| kens | I would say that kerning info is part of the metrics | 10:34.17 |
| | LOL chrisl beat me to it | 10:34.26 |
| | In fact I think pfm files have kerning info | 10:34.34 |
| | kerning tables are pairs | 10:35.51 |
| | of glyphs. THey trell you how much tro move glyh b when its preceded by glyph a | 10:36.06 |
| | and in which direction | 10:36.15 |
| Robin_Watts | ok, so we have 'default' metrics, and a set of adjustment exceptions. | 10:36.52 |
| kens | Yes, that's right | 10:36.58 |
| | and they are font-specific too, because the sahpe of the glyphs matters | 10:37.18 |
| | shape* | 10:37.23 |
| Robin_Watts | yes. | 10:37.29 |
| | ok, that's given me enough to go on for now. Thanks guys. | 10:38.29 |
| kens | No problem | 10:38.34 |
| Robin_Watts | So chrisl points out the PCL fonts were chosen by HP to be a close match to the windows ones. | 11:04.59 |
| | Do we have a list anywhere of which PCL fonts should correspond to which windows ones etc? | 11:05.22 |
| kens | Its why I was wondering if we could use those | 11:05.22 |
| Robin_Watts | kens: yeah, bear with me if I'm being slow here. | 11:05.42 |
| kens | Its a complex area :-( | 11:05.53 |
| | I don't have such a list BTW | 11:06.00 |
| Robin_Watts | Ok, next stupid question then... where are the Artifex PCL fonts kept? :) | 11:12.00 |
| | Presumably it's the urwfonts set? | 11:13.28 |
| | http://www.ghostscript.com/GhostPCL.html | 11:13.38 |
| | Apparently 9.07 is the last stable release of GhostPDL. | 11:13.48 |
| | and are we really sending people to wisc to download the fonts? | 11:14.26 |
| kens | umm no idea ? | 11:15.02 |
| Robin_Watts | well, we aren't cos wisc doesn't work any more, but... | 11:15.29 |
| | oh, d'uh. how did the urwfonts directory get there ? :) | 11:20.12 |
| kens | I guess chrisl put it there ? | 11:20.38 |
| Robin_Watts | kens: yeah, my point was that it's been there for ages, and i'm too blind to have noticed it :) | 11:20.58 |
| kens | I must have one too, hadn't realised | 11:21.13 |
| Robin_Watts | http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html <- useful. | 11:40.17 |
| chrisl | Robin_Watts: As you're finding, this is a bit of a minefield - probably what prompted Adobe to add the Widths/W array hacks to the PDF spec, | 11:52.52 |
| kens | lunch, back i a bit | 12:13.21 |
| henrys | Robin_Watts: they're are in the tree ghostpdl/urwfonts | 13:33.08 |
| Robin_Watts | henrys: yes, I have them. | 13:33.21 |
| | Just got a Nexus 7 in the post (for my mother in law). | 13:33.32 |
| | Very nice. | 13:33.37 |
| | henrys: It's not clear to me which of those fonts are PS equivalents, and which are PCL. | 13:34.24 |
| henrys | Robin_Watts: yes that's what I have | 13:34.29 |
| Robin_Watts | and further, which ones match which. | 13:35.32 |
| henrys | Robin_Watts: they are just truteype fonts there is nothing "PCL" about them. They do have some extra characters that PCL is interested in. | 13:35.34 |
| Robin_Watts | chrisl said that the PCL fonts were picked to be matches for the windows ones. | 13:36.35 |
| | Or is he talking about the character availability rather than the metrics ? | 13:36.57 |
| henrys | we got urn's "stock" fonts Nimbus mono is courier etc, then requested "full" glyph sets and that satisfied some of pcl's missing character problems | 13:40.30 |
| Robin_Watts | henrys: So the task ahead of me now is to find which URW font best matches each of the windows fonts. | 13:41.18 |
| henrys | Robin_Watts: use the names | 13:41.36 |
| Robin_Watts | and to then investigate if it's possible to retrofit the metrics (possibly including kerning data) from the windows fonts to the URW ones. | 13:42.02 |
| | 'names' ? | 13:42.06 |
| henrys | there is a table in pcl to go from nimbus whatever to courier for example. | 13:42.21 |
| | Robin_Watts: I assume you want to replace the "courier" in smart office with our courier. Is that right? | 13:44.03 |
| Robin_Watts | So, if I ttfdump NumbusMonL-Bold.ttf for example... nowhere in there does it say "Courier" | 13:44.09 |
| | henrys: Smart Office has a fontmap file that says "for this name, use this font" | 13:44.40 |
| | so "Courier" is set up to map to "blah.ef1" | 13:44.59 |
| | and I want to set that up so that "Courier" maps to "URWNimbusMonoL.ttf" or something | 13:45.29 |
| henrys | Robin_Watts: right and the best I can offer you there is pl/plftable.h | 13:45.31 |
| Robin_Watts | AH! | 13:46.07 |
| | So that's a mapping from PCL font names -> URW names. | 13:46.22 |
| henrys | yes | 13:46.55 |
| | PCL font names are the same as windows names. | 13:47.20 |
| Robin_Watts | Oh, bargain. | 13:47.31 |
| henrys | the "standard" names | 13:47.48 |
| Robin_Watts | http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html | 13:49.26 |
| | That lists the "normal" fonts. | 13:49.34 |
| henrys | I do wonder if it wouldn't be better to tweak the metrics in existing fonts with font forge. | 13:49.59 |
| | ? | 13:50.00 |
| Robin_Watts | We don't have equivalents for: Comic Sans, Georgia, Impact, Lucida, Palatino Linotype, Tahoma, Trebuchet, Verdana... | 13:51.31 |
| henrys | Robin_Watts: correct nothing from the microsoft release | 13:52.21 |
| Robin_Watts | So... we're kinda stuffed. | 13:52.43 |
| | MS office files will generally use MS office fonts. So to match the appearance/layout of such files we need matching fonts (or at least fonts that we can bend so they mostly match) | 13:53.49 |
| henrys | Robin_Watts: so am I being a layout snob when I'm concerned that no file can possibly be correct with smart office. Is the audience only interested in content? | 13:54.02 |
| kens | It can't use avaiable TT fonts ? | 13:54.41 |
| Robin_Watts | kens: and which fonts do you expect will be available on a handheld device? :) | 13:55.05 |
| kens | Robin_Watts : sure, but I would have allowed other fonts just in case. | 13:55.35 |
| Robin_Watts | kens: The font engine can pick up fonts from lib directories, yes. | 13:55.41 |
| tor8 | Robin_Watts: mupdf uses the URW fonts and maps them to the base 14, you can get started by looking at that mapping. | 13:55.44 |
| kens | OK so that answeres henrys question | 13:55.55 |
| | it can be correct if you supply the correct fonts | 13:56.07 |
| Robin_Watts | tor8: PDF/PS mappings are of little to no interest for office docs. | 13:56.09 |
| tor8 | but I suspect the PCL mapping table is more complete | 13:56.09 |
| norbertj | hello henrys | 13:56.38 |
| Robin_Watts | kens: I would not like to promise that it's perfect, but I suspect it'll be a hell of a lot better. | 13:56.39 |
| tor8 | Robin_Watts: we have a fairly big set of windows font name aliases and how they map onto the URW fonts, is what I meant | 13:56.40 |
| Robin_Watts | but we need to figure out what we are shooting for here. | 13:56.47 |
| | If we want to offer people a "perfect or close to it" solution, then we need to have a solution for these fonts. | 13:57.04 |
| kens | OK so maybe not perfect, but a lot better, and maybe 'good enough' | 13:57.25 |
| | If people want a good solution they need to provide the4 'correct' fonts | 13:58.00 |
| Robin_Watts | If we want to offer an "as good as you can expect with mismatching fonts" solution, then we're in good shape. | 13:58.08 |
| henrys | Robin_Watts: the immediate market is mobile printing so layout really does matter for us. I understand folks might just need contact, but that's not our current target customer base for this. | 13:58.08 |
| tor8 | paulgardiner: so, I have accessors up and running in libjs! | 13:58.13 |
| kens | SO either run on WIndows, or copy windows fonts or source replacements | 13:58.22 |
| henrys | s/contact/content | 13:58.29 |
| Robin_Watts | henrys: OK, so what's the way forward? | 13:58.31 |
| norbertj | henrys: on my memleak. When is the pcs->font_dir freeed? I see in pcfont-do_reset() in the pcl_reset_initial that it is allocated. But I can't see when it is released (i.e. in pcl_reset_permanent. | 13:58.35 |
| paulgardiner | tor8: nice | 13:58.47 |
| Robin_Watts | kens list seems resaonable. | 13:58.56 |
| tor8 | paulgardiner: I expect to tackle integrating it into mupdf next week | 13:58.58 |
| henrys | norbertj: it isn't I intended it to be a one time allocation | 13:59.01 |
| Robin_Watts | I don't believe we can say "run on windows". | 13:59.15 |
| | kens: The target for Picsels stuff was generally that it would be bundled on a phone (or similar), so we'd know the font availability up front. | 14:00.11 |
| paulgardiner | tor8: let me know if you run into any weirdness with the api | 14:00.15 |
| Robin_Watts | and the fontmap file would be constructed to do the best it could with what was there. | 14:00.26 |
| henrys | Robin_Watts: I must have missed something, you asked yesterday if you could look at windows metrics, and I assumed the next step was change the smart office metrics. | 14:00.41 |
| Robin_Watts | The font engine is supposedly capable of just picking up fonts from a dir, but the test-shell isn't really set up for that. | 14:00.50 |
| henrys | Robin_Watts: how did we get to urw fonts | 14:00.57 |
| | ? | 14:00.58 |
| norbertj | henrys: so everytime that pcl_reset_initial is done, it is allocated. I.e. this is also done by the passThrough_init (which does an initial/permanent/initial) | 14:01.07 |
| Robin_Watts | henrys: I spoke to kens/chrisl about the problem this morning to get their thoughts on the best way to extract metrics. | 14:01.31 |
| henrys | norbertj: yes that is the bugs | 14:01.36 |
| | norbertj: regression actually | 14:01.44 |
| Robin_Watts | During the course of that conversation, it became clear to me that we'd probably have to get the kerning data out too. | 14:01.58 |
| norbertj | henrys: then I would make the priority again blocking i.s.o. major. | 14:02.12 |
| Robin_Watts | and chrisl then said that the urwfonts were intended to be a match to the windows ones. | 14:02.30 |
| henrys | Robin_Watts: oh I can just read the logs, I'm sorry, I should have looked | 14:02.35 |
| Robin_Watts | hence it made me wonder if those were a better starting point. | 14:02.51 |
| | I'm prepared to use whatever set of fonts is required to get us the best match. | 14:05.16 |
| | but as fonts are not my forte, I've been canvassing opinions etc before I start. | 14:05.33 |
| Robin_Watts | grabs lunch. bbs. | 14:06.54 |
| henrys | norbertj: I'll probably get to it sometime today anyway so the status doesn't much matter | 14:07.53 |
| norbertj | henrys: excellent. | 14:09.04 |
| juschz | hi everyone, i'm new here. | 14:11.27 |
| | are the guys who worked on mupdf for android, on this channel ? | 14:14.51 |
| kens | yes | 14:15.03 |
| | (that's not me I hasten to add) | 14:15.40 |
| juschz | in fact, i use mupdf activity for a long, and made and implement some few features. Just want to know if you are interessed by talking or pull-requesting it ? | 14:17.25 |
| kens | Robin_Watts : tor8 ^^ | 14:18.43 |
| | tor8 ? | 14:20.42 |
| henrys | Robin_Watts went to lunch kens | 14:21.51 |
| kens | yeah I remembered, which is why I pinged tor | 14:22.02 |
| | guess he's afk too | 14:22.07 |
| juschz | you're located in California ? | 14:25.47 |
| kens | No all round the world | 14:25.55 |
| juschz | really ? which countries ? | 14:26.11 |
| kens | Artifex the company is headquartered in California | 14:26.18 |
| | US, UK, Sweden and Japan | 14:26.30 |
| juschz | nice | 14:26.52 |
| henrys | hmm the epage fonts look anonymous looking inside the font, no copyright etc. | 14:34.56 |
| chrisl | That's unusual..... | 14:37.52 |
| Robin_Watts | chrisl: .ef1 may be a proprietary format. | 14:41.15 |
| | and the fonts are usually bundled in an app. | 14:41.26 |
| | and bytes cost memory. | 14:41.35 |
| chrisl | What if you embed them? | 14:41.37 |
| Robin_Watts | chrisl: embed them as in PDF export? | 14:42.11 |
| chrisl | Yes | 14:42.16 |
| Robin_Watts | PDF export was only added within the last year or so. | 14:42.23 |
| chrisl | Oh, okay | 14:42.44 |
| Robin_Watts | and presumably it exports them as a standard type. | 14:42.49 |
| | certainly it wasn't a consideration when they were first done | 14:42.57 |
| chrisl | Yeh, with no copyright | 14:42.58 |
| norbertj | henrys: I found that pcli is freeed in pcl_impl_deallocate_interp_instance, But the pcli->pcs->font_dir ??? | 14:44.35 |
| tor8 | juschz: I believe paulgardiner (and/or Robin_Watts) are the ones to talk to about the android app | 14:45.55 |
| Robin_Watts | juschz: On irc it's generally best to ask your question, rather than to ask to ask your question, due to the lags involved. | 14:46.42 |
| kens | Robin_Watts : ghe did | 14:46.57 |
| | see logs | 14:47.00 |
| juschz | :) | 14:47.11 |
| Robin_Watts | sorry. I missed that. | 14:47.13 |
| | Yes, we're always interested in such things. | 14:47.25 |
| | Can you give more details please? | 14:47.30 |
| | paulgardiner is the guy to talk to really, but he often doesn't work fridays. | 14:48.06 |
| paulgardiner | I'm lurking | 14:48.23 |
| kens | Robin_Watts : I htink its Thursday today ;-) | 14:48.35 |
| juschz | Yes of course. can we talk using private conversation ? | 14:48.41 |
| chrisl | Oh thank god, I thought I'd lost a day, there..... | 14:49.02 |
| Robin_Watts | kens: this must be a thursday. I could never get the hang of thursdays. | 14:49.10 |
| kens | LOL | 14:49.17 |
| henrys | the important thing is the paulgardiner doesn't think it's friday, doesn't much matter for the rest of you. | 14:49.58 |
| paulgardiner | Thankfully I knew. | 14:50.37 |
| Robin_Watts | juschz: You can use a private conversation if you must, but it means that only 1 person can hear you. Where possible we try to work in the open, so everyone knows what's going on. Unless there are commercial sensitivites of course... | 14:50.40 |
| paulgardiner | Possibly I will forget that it is tomorrow too. | 14:50.51 |
| Robin_Watts | it is never tomorrow. That's kind of the defining characteristic of tomorrows. | 14:51.20 |
| | Although it's never yesterday either, which could be confusing. | 14:51.40 |
| henrys | norbertj: between your bug and what you are saying I'm a little confused where I should direct my attention, I can just look for leaks with C706? | 14:52.45 |
| Robin_Watts | chrisl: Do we have a postscript program or something to do contact sheets for fonts? | 14:58.54 |
| kens | I haveone somewhere | 14:59.08 |
| Robin_Watts | So I can print out the different fonts, and do a visual check | 14:59.13 |
| | kens: And will it cope with ttfs etc? | 14:59.25 |
| kens | Robin_Watts : it does fonts in the interpreter | 14:59.39 |
| | So whatever the interpreter deals with | 14:59.50 |
| Robin_Watts | ok. | 14:59.56 |
| chrisl | I've generally found a hundred plus pages of characters of limited use..... | 15:01.11 |
| norbertj | henrys: in our controller we call the pl_main() for processing a job (e.g. pcl) then do a return to caller, which then can call pl_main() for processing another job (e.g. xps). So we require a correct cleanup of all memory allocations. | 15:01.16 |
| Robin_Watts | chrisl: I was thinking that I'd just compare A-Za-z0-9 and punctuation etc. | 15:02.01 |
| norbertj | One of them is the font_dir allocated in the pcs. And the C706 just showed it for me. | 15:02.04 |
| kens | Robin_Watts : my program does *all* the glyphs in the font | 15:02.20 |
| Robin_Watts | http://www.typetester.org/ | 15:02.24 |
| kens | for all fonts | 15:02.25 |
| chrisl | Robin_Watts: yes, but *all* the fonts known to Ghostscript installation can be a large number | 15:02.52 |
| norbertj | as long as we process pcl jobs we stay in the pl_main, but then I also see leakage between jobs (esp. with the C706) | 15:02.59 |
| henrys | norbertj: yes there are assumptions of one time allocations. I think the only way to safely leave pl_main.c c and clean everything up is to use the chunk allocator to free everything directly I don't know if you can do that. | 15:05.16 |
| | norbertj: should be straightforward to add if it's not there already | 15:05.56 |
| norbertj | henrys: e.g. by using the gs_memory_chunk_dump_memory() to walk everything, and then free the chunks etc. | 15:07.13 |
| kens | Robin_Watts : I have file called fontsheets .ps can't seem to find my own one | 15:07.45 |
| henrys | norbertj: I'll ask ray to implement something for you? | 15:07.47 |
| Robin_Watts | kens: thanks. | 15:07.57 |
| henrys | norbertj: and I'll look at leaks in C706 | 15:08.06 |
| kens | Do you want it ? | 15:08.06 |
| norbertj | henrys: ok | 15:08.17 |
| Robin_Watts | please. | 15:08.24 |
| kens | OK | 15:08.30 |
| norbertj | henrys: when looking ac C706 leaks, try to send the job # times and see if/whether there memory is growing. | 15:09.10 |
| kens | Robin_Watts : if its not good enough let me know what you want and I'll throw something together | 15:09.23 |
| henrys | norbertj: I would be horrified if you actually saw passthrough in a customer job. What a mess HP got itself into with that. | 15:10.06 |
| norbertj | henrys: ;)yup | 15:10.43 |
| chrisl | henrys: just shutting down a chunk allocator instance should free all the memory allocated by that instance | 15:11.17 |
| henrys | chrisl: I see chunk_free_all() where is that called from? | 15:12.42 |
| chrisl | henrys: gs_memory_chunk_release | 15:13.00 |
| tor8 | Robin_Watts: FontForge has some font comparison stuff | 15:14.22 |
| chrisl | henrys: gs_memory_chunk_release -> chunk_free_all -> chunk_mem_node_free_all_remaining | 15:14.39 |
| norbertj | henrys; called in fapi_ft.c fapiufst.c and gxclthrd.c | 15:15.35 |
| henrys | so I guess I'll just add that to plmain before we finish. | 15:16.27 |
| | norbertj: it might be difficult to get C706 memory clean the way things are done. | 15:17.47 |
| | norbert I wonder if passthrough shouldn't require exiting plmain to be safe. | 15:19.00 |
| chrisl | henrys: could you fire off a new chunk allocator for the passthrough PCL instance? | 15:19.10 |
| norbertj | henrys: and release at pxpcl_release | 15:20.20 |
| henrys | chrisl: probably a good idea. | 15:20.22 |
| | I imagine snippet mode and font mode would still leak and we can't free memory there state is shared. | 15:21.42 |
| | let me see how hard it is to clean up C706 | 15:22.24 |
| norbertj | henrys: for your info. I added a gs_memory_chunk_dump_memory() in pl_main, just before pl_main_cursor_open(), so when sending multiple jobs I see the mem usage. | 15:35.03 |
| henrys | norbertj: right and you should see the "usual stuff" cache entries, one time allocations etc. so I am adding chunk release call to pl_platform_dnit() | 15:41.49 |
| norbertj | It grows with each C706 job approx. 0.8MB; This is without leaving the pl_main()-loop | 15:42.27 |
| Robin_Watts | A Memento build might show it nicely. | 15:46.20 |
| henrys | norbertj: yes in gdb you can just put a breakpoint at the end of the main loop and do p gs_memory_chunk_dump_memory(mem) to see the culprits | 15:46.22 |
| Robin_Watts | If you have a Memento build, then you can do: Memento_listNewBlocks() | 15:47.35 |
| | and that will list the new blocks that are still extant from the last time around. | 15:47.48 |
| | If you're in gdb or MSVC you can even call that function from the debugger. | 15:48.06 |
| norbertj | Robin_Watts: I'm on VS2012,how do I call? | 15:48.44 |
| Robin_Watts | Alt-Ctrl-Q to bring up the quick watch window | 15:49.19 |
| | Then in there type Memento_listNewBlocks() and hit return | 15:49.36 |
| | and you should get stuff spewed to the console window. | 15:49.50 |
| | but it relies on you having build with -DMEMENTO | 15:49.58 |
| henrys | Robin_Watts: yes I can use what I said without rebuilding so it seemed best. | 15:50.37 |
| Robin_Watts | henrys: sure. | 15:51.08 |
| norbertj | Robin_Watts: yes, that works (for gs_memory_chunk_dump_memory(mem)), so I have now to compile with Memento ;) | 15:52.00 |
| Robin_Watts | norbertj: Memento is a useful tool for all sorts of reasons, so it's worth having in your armory (but I'm biased, cos I wrote it :) ) | 15:52.58 |
| | It checks for overwrites of freed blocks etc, so it does slow apps down. You don't want to *always* be using a memento build. | 15:53.52 |
| | but it allows you to do things like "Run this program until the nth allocation" | 15:54.20 |
| henrys | norbertj: based on what I'm seeing here I think we might be stuck with exiting plmain for passthrough without a radical undertaking. | 15:54.22 |
| norbertj | Robin_Watts: ;) I used UMDH to get detect leaks from the running program. Just dumping before and after a job, and then comparing. | 15:54.41 |
| Robin_Watts | and then "Run until this block is freed" etc. | 15:54.42 |
| norbertj | It gives nice stacktraces of the calls to malloc that are not freed. | 15:54.58 |
| Robin_Watts | Memento tracks memory leaks too. And it lists the blocks that have leaked by allocation number. | 15:55.37 |
| | so you can rerun with "Memento_breakAt(n)" to stop where the block is allocated. | 15:55.57 |
| | See gs/base/memento.h for more info. | 15:56.27 |
| norbertj | I will have a closer look at that. | 15:56.40 |
| henrys | chrisl: I wish some of these memory "client names" were better "bytes" is not useful vs. say "cached_fm_pair" | 16:02.02 |
| chrisl | henrys: I try to make them useful. I think there are a lot of cases where there's indirection so there can't be better ones | 16:03.11 |
| Robin_Watts | henrys: Memento_label(....) :) | 16:04.36 |
| henrys | the memento salesman! | 16:05.14 |
| chrisl | Robin_Watts: does that use the FILE and LINE macros? | 16:05.15 |
| Robin_Watts | If you change allocations from x = malloc(size) to be x = Memento_label(memento(x), "An informative label"); then the label is set. | 16:05.39 |
| | chrisl: FILE and LINE don't pass through the gs allocation things nicely. | 16:05.52 |
| | bah. let me type that again. | 16:06.15 |
| | If you change allocations from x = malloc(size) to be x = Memento_label(malloc(size), "An informative label"); then the label is set. | 16:06.25 |
| chrisl | If we have to change the allocations, then we'd be as well putting a sane tag in the existing code | 16:07.12 |
| Robin_Watts | chrisl: True. | 16:07.49 |
| | Hmm. I should put some Memento_labels in the allocator code to use the supplied tags. | 16:08.22 |
| | That way the memento leaked block reports etc would be prettier more of the time. | 16:08.49 |
| henrys | Robin_Watts: from what I see your memento changes have broken the client name stuff: i.e: | 16:11.18 |
| | #ifdef MEMENTO | 16:11.20 |
| | #define LOCAL_CNAME cname | 16:11.21 |
| | #else | 16:11.22 |
| | #define LOCAL_CNAME "chunk_mem_node_add" | 16:11.23 |
| | #endif | 16:11.24 |
| Robin_Watts | henrys: where is that? | 16:12.08 |
| | gsmchunk.c | 16:12.40 |
| | How do you figure I broke it? | 16:13.10 |
| henrys | Robin_Watts: yes I'm trying to debug where all the allocations are coming from and you've changed all the names as seen the heap allocator to "chunk_mem_node_add" | 16:13.50 |
| | s/seen/seen from/ | 16:14.06 |
| Robin_Watts | http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=42c6f088344544b5e854899e4126e0d3ec4ee496;hp=ebc8452e68710ace66b3acca4d1701bfa6f59143 | 16:14.48 |
| henrys | I want to put a break on gs_heap_alloc_bytes() and see the original came. | 16:14.53 |
| | s/came/cname | 16:15.03 |
| Robin_Watts | Before my change, chunk_mem_add was always using "chunk_mem_node_add" | 16:15.26 |
| | After my change, non memento builds still used "chunk_mem_node_add", but memento builds used a better cname. | 16:15.52 |
| henrys | Robin_Watts: oh excuse me, why wasn't fixed for the regular build? | 16:15.57 |
| Robin_Watts | because I didn't want to slow down normal builds? | 16:16.10 |
| | I should probably have just fixed it for the normal build :( | 16:16.43 |
| henrys | Robin_Watts: oh certainly not your fault, you made progress, I wonder why ray did that? | 16:17.15 |
| | ray_laptop are you around? | 16:18.53 |
| ray_laptop | henrys: in your commit 82fc3bd you removed setting the GX_COLOR_INDEX_TYPE in the CFLAGS. This breaks the display device | 16:19.38 |
| | henrys: yes, I am here :-) | 16:19.54 |
| henrys | ray_laptop: I'm sure the GX_COLOR_INDEX_TYPE will repeatedly break things as long as it is exists. I'll have a look. | 16:20.36 |
| ray_laptop | henrys: huh ? | 16:21.23 |
| henrys | norbertj: I think we are going to need a flag that indicates passthrough happened and you'll have to exit. I don't imagine being able to clean this up manually. | 16:22.33 |
| | exit plmain.c that is, once I add the chunk free routine. | 16:23.00 |
| ray_laptop | currently a gs build doesn't have /DGX_COLOR_INDEX_TYPE="__int64" | 16:23.01 |
| Robin_Watts | ray_laptop: I think henrys was making the point that it's an accident waiting to happen. | 16:23.30 |
| henrys | Robin_Watts, ray_laptop ignore my random rantings | 16:24.51 |
| | chrisl_away saw ray_laptop wrote CFLAGS and he left the building | 16:26.39 |
| ray_laptop | henrys: I am going to put back the code you removed from msvc.mak and ask you or chrisl to review the patch. | 16:27.04 |
| | henrys: it doesn't make sense to have USE_LARGE_COLOR_INDEX=1 then ignore it (IMHO) | 16:27.51 |
| henrys | git.ghostscript.com won't let you search for a commit number how annoying | 16:28.31 |
| Robin_Watts | commit number? | 16:28.42 |
| ray_laptop | henrys: I just use git log and then use / to plug in the commit # | 16:29.14 |
| | (hash) | 16:29.23 |
| henrys | well on a repo git status 82fc3bd works fine | 16:29.49 |
| Robin_Watts | http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=82fc3bd | 16:30.19 |
| henrys | I was complaining about the web interface - the box says "commit" you'd expect if you put in a hash it would go to it. | 16:30.21 |
| Robin_Watts | yes, that is a pain. I click on a "commit" link, then replace the hash in the URL with the one I want. | 16:30.53 |
| henrys | ray_laptop: well we just moved that logic to msvclib.mak | 16:31.50 |
| ray_laptop | henrys: msvclib.mak is not used by msvc.mak -- they are both "top level" makefiles | 16:32.26 |
| henrys | ray_laptop: my memory is shaky about this. | 16:32.42 |
| ray_laptop | henrys: I think the logic is needed in both | 16:32.44 |
| henrys | ray_laptop: really should send it to chrisl_away I really don't want to duplicate stuff like that, but I guess he'll see it anyway. I thought he reviewed this patch. | 16:33.39 |
| | ray_laptop: Indeed I did think you source msvclib.mak seems like you must at some point. | 16:34.13 |
| | s/source/sourced | 16:34.34 |
| Robin_Watts | msvc_top.mak includes msvclib.mak | 16:35.15 |
| | But only in the non PSI case. | 16:36.23 |
| henrys | ugh, I'm sorry ray_laptop you had to spend time on that. | 16:37.54 |
| ray_laptop | henrys: no problem. git bisect found the commit for me. | 16:39.36 |
| henrys | can somebody refresh my memory about this, do we need this option anymore? can we just make in uint64_t in the code? | 16:40.03 |
| ray_laptop | Robin_Watts: msvc_top is not used by gs only builds | 16:40.11 |
| henrys | s/make in/make it/ | 16:40.39 |
| | bb in 30 minutes | 16:41.30 |
| ray_laptop | BTW, there is some wrong code in base/gxcindex.h if GX_COLOR_INDEX_TYPE is not defined, it does: typedef ulong gx_color_index_data; | 16:41.59 |
| | even though the ARCH_SIZEOF_GX_COLOR_INDEX is 8 | 16:42.58 |
| Robin_Watts | henrys: I thought there were 2 arguments with this stuff. 1) Not all compilers have a 64bit int type (or at least, they don't all agree on what it is called - uint64t or unsigned long long etc). | 16:47.10 |
| | 2) On some platforms that do have it, there is a speed penalty associated with it; why take the hit in having the color index as a 64bit int, when you're only ever working in 24bits at most? | 16:47.54 |
| | hence why it's configurable. | 16:48.11 |
| ray_laptop | cust 532 is an example of the latter. The PPC gets a speed penalty with 64 bits. | 16:49.28 |
| | OK. Now -dDisplayFormat=16#a0800 works with the display device. And the output is different to both the psdcmyk output and the psdcmykog output :-( | 16:55.52 |
| | and the tiffsep device is different to the other 3 :-( | 16:59.31 |
| kens | Are any of them correct ? | 16:59.55 |
| ray_laptop | kens: how can I tell ? | 17:00.41 |
| kens | check it with Acrobat ? Or I can get an opinion form another PS interpreter | 17:01.01 |
| | What;s the file ? | 17:01.05 |
| ray_laptop | 29-07I.PS | 17:01.12 |
| kens | OK just a moment | 17:01.20 |
| ray_laptop | in tests_private/ps/ps3cet | 17:01.24 |
| kens | Yeah I think I have it | 17:01.34 |
| | Err, OK which o fhte 9 pages now ? | 17:02.31 |
| ray_laptop | kens: the thing is that it only does this misbehavior with deviceN devices. With "normal" CMYK or RGB it's fine | 17:02.43 |
| kens | Well I can use another rip with a devicen device. | 17:03.18 |
| ray_laptop | page 1 is the same on all devices (as expected). It's page 2 through 9 that get screwy | 17:03.22 |
| kens | OK | 17:03.31 |
| | Does it depend what inks are available in the DeviceN device ? | 17:04.16 |
| | THe invocation looks mad | 17:04.24 |
| ray_laptop | for example, the psdcmyk device looks reasonable for page 2 and 3 showing the black channel as expected. The display device (with -dDisplayFormat=16#a0800) has those blank | 17:05.28 |
| kens | Well given that its affecting the /Separations array I might expect peculiar results with a DeviceN device (or indeed a separating device, even though it sets /Seaprations to false) | 17:06.13 |
| Robin_Watts | kens: That file is device dependent, right? So do we care that different devices do different things? | 17:06.45 |
| henrys | Robin_Watts, ray_laptop christ my iPhone is 64bits ... | 17:06.46 |
| kens | Robin_Watts : yes, its all device dependent | 17:06.58 |
| Robin_Watts | I mean, the display device doesn't support separations, so all bets are off. | 17:07.29 |
| | The psdcmykog device only supports its own colorants so likewise. | 17:07.47 |
| kens | ray_laptop : the other rip throws a configurationerror | 17:07.59 |
| | WHich seems kind of reasonable to me | 17:08.11 |
| Robin_Watts | henrys: Why should we allocate 64bits for a colorindex in the clist for a mono laserprinter? | 17:08.30 |
| henrys | if that's the argument we should have a bit color index option | 17:10.08 |
| kens | THe other rip does work with pages 4-9 | 17:10.11 |
| ray_laptop | Robin_Watts: the display device with -dDisplayFormat=16#a0800 _does_ support separations | 17:10.34 |
| | kens: define "work" | 17:10.44 |
| kens | ray_laptop : it doesn'tr throw an error ;-) | 17:10.55 |
| henrys | Robin_Watts: but the direct answer is so that I don't break the code again. | 17:10.59 |
| kens | I'm just looking at the actual output now | 17:11.02 |
| Robin_Watts | henrys: Do we not support a char there? :) | 17:11.13 |
| ray_laptop | kens: what does the output look like ? | 17:11.14 |
| kens | ray_laptop : ^^ | 17:11.22 |
| | page 4, RGB and gray bars have content in the black channel, so does the K gradient | 17:12.09 |
| ray_laptop | kens: sorry I was typing when your message popped up | 17:12.10 |
| kens | page 4, the blue and cyan bars appear in the cyan plate | 17:12.48 |
| ray_laptop | kens: it didn't create a Gray separation then did it (as the psdcmyk device does) ? | 17:12.57 |
| kens | It has a black separation | 17:13.08 |
| | But the ink sin the DeviceN device are fixed | 17:13.19 |
| | CMYKOG | 17:13.45 |
| | SO it doesn't make a gray separation no | 17:14.01 |
| | THe output looks 'sensible' in as much as the marked plates might reasonably have those inks form a conversion from source space into CMYKOG | 17:15.13 |
| henrys | Robin_Watts: do any of your sources know where the fonts came from? Did piscel hire a font designer? | 17:16.04 |
| ray_laptop | kens: OK, so it sort of sounds like our psddcmykog device (once my fix is applied) | 17:16.14 |
| Robin_Watts | They came from EFF. | 17:16.16 |
| | The Electronic Font Foundry. | 17:16.22 |
| kens | ray_laptop : I would expect so, it is a CMYKOG device | 17:16.28 |
| Robin_Watts | a buy called Eduard Poor, if memory serves. | 17:16.30 |
| | s/buy/guy/ | 17:16.37 |
| kens | There is a different DeviceN driver for Light cyan and magenta I could try but I doubt it would be more interesting | 17:16.49 |
| henrys | Robin_Watts: makes sense given the extensions on the filenames | 17:17.16 |
| Robin_Watts | .ef1 may stand for 'epage font 1' | 17:17.35 |
| | in fact: http://ghostscript.com/~regression/epage-docs/font/internal/efont1.html | 17:18.10 |
| | ooh. | 17:19.22 |
| | so there is a ttf to ef1 converter. | 17:19.37 |
| | I could use that on the urw fonts and pickle in the new metrics maybe. | 17:20.33 |
| kens | LOL todays weekly UFST regression is *huge* | 17:20.43 |
| henrys | kens has a strange sense of humor ;-) | 17:21.08 |
| ray_laptop | kens: OK. Thanks. The job does the fountains in CIEBasedABC, then in DeviceGray, DeviceRGB and DeviceCMYK, so I suppose that psdcmyk is sort of reasonable in making blank pages, but I think it should not be generating the CMYK planes | 17:21.23 |
| Robin_Watts | henrys: I think that's entirely reasonable. | 17:21.32 |
| | I've only spent 1 day looking at fonts, and I can feel my mind going already. | 17:21.43 |
| henrys | Robin_Watts: curious what happens if I try opening one of these babies in fontforge | 17:21.50 |
| kens | ray_laptop : yes indeed I checked the job contents. all the inks which don;t have a named separatin shoujld be converted to the DeviceN space (via a dveice space if neccesary) | 17:22.04 |
| Robin_Watts | henrys: I suspect different headers etc? | 17:23.15 |
| ray_laptop | kens: I don't follow. A device that doesn't support adding named separations (fixed inks) should convert the colors how ? | 17:23.29 |
| henrys | Robin_Watts: I'm failing to see what is different other than missing tables but⦠the open in font forge as a TT | 17:23.35 |
| kens | ray_laptop : IMO you cna treat a DeviceN device as a separating device with named inks (normally including a set of device inks) | 17:24.09 |
| Robin_Watts | henrys: oh, well, fair enough then :) | 17:24.27 |
| kens | Any colour space which is not the DeviceN space needs to be converted | 17:24.31 |
| Robin_Watts | That makes then a lot more use then, I guess. | 17:24.36 |
| | s/then/them. | 17:24.45 |
| kens | So the device needs to know how to convert device spaces into its flavour of DeviceN | 17:25.02 |
| | If the ink is present in teh DeviceN, obviously it doesn't need converted | 17:25.20 |
| ray_laptop | right which is what the device ICC profile is for | 17:25.23 |
| kens | SO for a DeviceN CMYKOG device I would expect CMYK to print only on those plates | 17:25.44 |
| | Gray, RGB and CIE would be converted into DeviceN by the device, so it may mark any or all of the plates | 17:26.10 |
| ray_laptop | so if a device has fixed inks, it ignores SeparationOrder ??? | 17:26.16 |
| kens | I don't believe it *ignores* it | 17:26.28 |
| ray_laptop | kens: what should it do with separation order ? | 17:26.46 |
| kens | But if it doesn't match the available inks then that would seem a good time to throw a configurationerror | 17:26.48 |
| | Let me grab the PLRM | 17:27.04 |
| | "Legal element | 17:27.50 |
| | values are the process colorant names implied by the process color | 17:27.50 |
| | model (see Process Color Model on page 422), as well as any additional | 17:27.50 |
| | colorant names declared by the SeparationColorNames parameter. | 17:27.50 |
| | The presence of any other names will result in a configuration | 17:27.50 |
| | error." | 17:27.50 |
| | And for SeparationColorNames: | 17:29.00 |
| | "The DeviceN process color model | 17:29.01 |
| | (LanguageLevel 3) has no such implicit colorant names; all device | 17:29.01 |
| | colorants in that model must be declared explicitly in | 17:29.01 |
| | SeparationColorNames. The DeviceN entry in the output device dictionary | 17:29.01 |
| | (see Section 6.4, Output Device Dictionary) defines the allowable | 17:29.01 |
| | sets of process colorants for the DeviceN process color | 17:29.01 |
| | model." | 17:29.02 |
| | So SeparationColorNames must match the device (retrieved from the output device dictionary) | 17:29.53 |
| | and SeparationOrder may not contain any inks not in that array | 17:30.10 |
| | So if you do /Red in a CMYKOG device that should be a configurationerror | 17:30.29 |
| ray_laptop | kens: OK, so it seems that our tiffsep device is getting it right. | 17:30.40 |
| kens | At least that's what a first preusal suggests | 17:30.45 |
| ray_laptop | and psdcmyk is wrong in creating separations that haven't been set in the SeparationColorNames | 17:31.32 |
| kens | Yes I'm sure that's incorrect | 17:31.41 |
| Robin_Watts | henrys: WIndows won't recognise them as being .ttfs. | 17:32.03 |
| kens | You definitely shouldn't produce any separations except the ones the device is capable of | 17:32.04 |
| henrys | Robin_Watts: are you sure it isn't file extension nonsense | 17:32.28 |
| | ? | 17:32.29 |
| Robin_Watts | I just renamed them all to .ttf | 17:32.40 |
| ray_laptop | kens: well, the psdcmyk device is capable of creating any separations (up to 10 + CMYK) | 17:32.41 |
| kens | ray_laptop : Technically a DeviceN device sholdn't be able to create arbitrary separations | 17:33.10 |
| | It shoudl name the separations it is capable of, and you cna't use any others | 17:33.27 |
| henrys | Robin_Watts: probably windows requires a particular table that isn't present in these fonts. | 17:33.42 |
| | Robin_Watts: linux is fine with them | 17:33.56 |
| Robin_Watts | yeah, fontforge on windows loads them OK. | 17:34.20 |
| ray_laptop | kens: gs_epsf.ps sets SeparationColorNames from the DSC %%DocumentCustomColors contents | 17:35.25 |
| kens | ray_laptop : Ick | 17:35.34 |
| | I understand the reasoning, but the spewc assumes that a device has specific inks | 17:35.51 |
| | WHich is reasonable for a real world printer | 17:36.00 |
| ray_laptop | but for PDF we don't -- I think that's why we just add separations for psdcmyk automatically | 17:36.09 |
| kens | SO if you allow aribtrary separationsto be created automagically, then al;l bets are off really. | 17:36.31 |
| | As Robin_Watts said, its all device dependent anyway | 17:36.44 |
| Robin_Watts | henrys: OK, if I "generate fonts" from within fontforge I get something that windows is happy with. | 17:36.49 |
| ray_laptop | kens: for a rip creating separations for a press, we need to | 17:36.56 |
| kens | ray_laptop : One would assume you know what inks are onyour press in advance | 17:37.25 |
| | DeviceN is not intended for CNYK+spots | 17:37.37 |
| | CMYK | 17:37.40 |
| | Its intended for colour models other than the standard process spaces | 17:37.59 |
| | If you want CMYK+spots then use that, not DeviceN | 17:38.14 |
| henrys | Robin_Watts: well you can change the width - select all - set width and set a % - pretty ham fisted. | 17:41.56 |
| | Robin_Watts: it may be best to hand this off to chrisl_away but I was hoping not to get other down the epage hole just yet. | 17:43.29 |
| Robin_Watts | henrys: At the moment, I'm looking to find the best visual matches for each windows font. | 17:43.56 |
| ray_laptop | I think our pdf_main.ps should be setting the SeparationColorNames, not just the PageSpotColors count | 17:44.08 |
| kens | That sounds reasonable | 17:44.21 |
| Robin_Watts | But trying a global scaling sounds a good idea, before applying the correct metrics. | 17:44.37 |
| kens | If you want to set up teh device to handle the named inks | 17:44.40 |
| henrys | Ideally we want to write a font forge script to change the metrics based on some set of fonts we think correct | 17:44.42 |
| Robin_Watts | Well, the fonts supplied with Windows are 'correct', right? | 17:45.10 |
| ray_laptop | that way we can change the psdcmyk device to only output the correct separations and throw errors for others | 17:45.10 |
| | and I have to make the psdcmyk device throw configurationerror as the tiffsep device does | 17:45.53 |
| kens | ray_laptop : I do believe that one should throw configurationerror for unrecognised inks | 17:45.55 |
| ray_laptop | kens: agreed. | 17:46.12 |
| kens | Erro thje psdcmykog one | 17:46.16 |
| | Oh dear its late, my typing is deteriorating | 17:46.35 |
| Robin_Watts | That would remove the nasty read/set to zero/reset done in the psdcmykog device. | 17:46.45 |
| kens | Its hte OG device I'm thining of yes | 17:47.28 |
| | teh psdcmyk one maybe should allow extra separations, its debatable | 17:47.56 |
| ray_laptop | I did confirm that setting -c "<< /SeparationColorNames [ (Cyan) (Magenta) (Yellow) (Black) (Gray) ] >> setpagedevice" with the tiffsep device adds a Gray component (that is blank as expected) | 17:49.58 |
| | Robin_Watts: I agree. | 17:50.21 |
| kens | That seems like its correct | 17:50.26 |
| | OK I have to run, goodnight all | 17:50.41 |
| ray_laptop | Robin_Watts: I didn't commit that yet | 17:50.50 |
| | but the tiffsep device is NOT correct in that all pages after page 3 only have the Black Separation | 17:52.29 |
| | what a mess. I should just leave it for mvrhel, but I guess I'll be nice :-) | 17:53.02 |
| | Robin_Watts: was it you that made genarch.h do the 'copy_existing_file' ? If so, this broke the commented assumption in gxcindex.h since it ignores the default in genarch.c | 18:09.02 |
| | w.r.t GX_COLOR_INDEX_TYPE | 18:09.21 |
| Robin_Watts | ray_laptop: possibly. | 18:09.36 |
| | Is that to avoid regenerating stuff if it hasn't changed? | 18:09.55 |
| | where are you looking? | 18:10.13 |
| ray_laptop | base/gxcindex.h line 59 | 18:10.50 |
| | the problem is that the canned arch/windows-x86-msvc.h has ARCH_SIZEOF_GX_COLOR_INDEX | 18:12.11 |
| | and that doesn't correspond to ulong. | 18:12.28 |
| Robin_Watts | where is "copy_existing_file" ? | 18:12.30 |
| ray_laptop | in genarch.c | 18:12.40 |
| Robin_Watts | Oh, I see. So I've change genarch so that as well as it's old way of working, it can now be invoked with a canned arch file that it will just copy. | 18:14.03 |
| | That does sound like the kind of thing I might have done for the sake of cross compiling. | 18:14.16 |
| ray_laptop | I'm thinking that I should change gxcindex.h to #define GX_COLOR_INDEX_TYPE to either uint32_t or uint64_t depending on the ARCH_SIZEOF_GX_COLOR_INDEX | 18:14.36 |
| Robin_Watts | ray_laptop: Except not all compilers offer uint64_t. | 18:15.07 |
| ray_laptop | (to prevent this sort of problem) | 18:15.10 |
| | but we define one iirc | 18:15.28 |
| | in base/stdint_.h | 18:16.22 |
| Robin_Watts | ray_laptop: If we have to have a #define, then wouldn't it be best to have that define be the type to use? (i.e. GX_COLOR_INDEX_TYPE="unsigned long long" or something? | 18:16.53 |
| | Because we can always get the size from that? | 18:17.03 |
| | oh, but not when cross compiling, if we need the size in a host tool :( | 18:17.16 |
| | IF we always define one, then yes, that seems reasonable. | 18:17.29 |
| | OOh! | 18:43.06 |
| ray_laptop | Robin_Watts: ??? | 18:43.47 |
| Robin_Watts | I just found loads more fonts hidden in the huge tar file of picsel stuff we got. | 18:44.01 |
| | Including the original electronic font foundry .ttf files and a nice list of "this font is equivalent to this". | 18:44.27 |
| | Visually the glyphs are REALLY good clones. | 18:44.42 |
| | It's just the metrics are off. | 18:44.49 |
| | so if I can fix the metrics, we should be golden. | 18:44.56 |
| ray_laptop | Can someone please review my patch for the display device (msvc.mak)? http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=7889b2f42405628b1a98ba2df7f02de01a2a7be6 | 19:20.06 |
| | oops. I forgot to add the lib.mak change | 19:22.46 |
| | OK, this one has all the changes: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=c72bc4c9513db628062790252f1535eb7bc83609 | 19:24.25 |
| | BTW, I tested the gxcindex.h change _without_ the msvc.mak change and that works OK | 19:25.27 |
| Robin_Watts | looks plausible. | 19:26.08 |
| ray_laptop | Robin_Watts: thanks. The concern I have is that it is still possible to have the ARCH_SIZEOF_GX_COLOR_INDEX not match the sizeof(GX_COLOR_INDEX_TYPE) since the makefile macro may not match what genarch sets into arch.h | 19:30.39 |
| Robin_Watts | ray_laptop: Well, there is something hacky we can do for that... | 19:31.06 |
| | static int dummy[ARCH_SIZEOF_GX_COLOR_INDEX - sizeof(GX_COLOR_INDEX_TYPE) + 1]; | 19:32.02 |
| | actually, better: | 19:32.25 |
| | http://www.pixelbeat.org/programming/gcc/static_assert.html | 19:34.21 |
| | We can use that to get us a compile time assert macro. | 19:34.30 |
| | Then we can compile time assert that ARCH_SIZEOF_GX_COLOR_INDEX == sizeof(GX_COLOR_INDEX_TYPE) | 19:35.00 |
| ray_laptop | Robin_Watts: but the pre-processor can't do sizeof | 19:41.35 |
| Robin_Watts | Indeed. | 19:42.04 |
| ray_laptop | or is the trick that the enum is evaluated at compile time ? | 19:42.08 |
| Robin_Watts | but we aren't relying on the preprocess to do sizeof there. | 19:42.15 |
| | exactly. | 19:42.21 |
| | Or, perhaps cleaner: | 19:44.37 |
| | enum { ARCH_SIZEOF_GX_COLOR_INDEX__must_equal__sizeof_GX_COLOR_INDEX_TYPE == 1/!!(ARCH_SIZEOF_GX_COLOR_INDEX == sizeof(GX_COLOR_INDEX) }; | 19:45.48 |
| | cos if that fails, you'll get a meaningful(ish) error message | 19:46.50 |
| | Hmm. I missed a ). | 19:47.02 |
| ray_laptop | Robin_Watts: that (corrected for the missing ) and s/== 1/= 1/ ) gives "expected constant expression" | 20:16.46 |
| Robin_Watts | That is a constant expression. | 20:17.37 |
| | 1/!!(1) = 1/1 = 1 | 20:18.02 |
| | sizeof(GX_COLOR_INDEX_TYPE) sorry. | 20:18.27 |
| ray_laptop | Robin_Watts: OK. This works: enum { ARCH_SIZEOF_GX_COLOR_INDEX__must_equal__sizeof_GX_COLOR_INDEX_TYPE = 1/(ARCH_SIZEOF_GX_COLOR_INDEX == sizeof(GX_COLOR_INDEX_TYPE)) }; | 20:24.34 |
| Robin_Watts | ray_laptop: You've removed the !! | 20:25.13 |
| ray_laptop | it compiles OK when they are equal, and if not gives "expected constant expression" | 20:25.15 |
| Robin_Watts | but that's OK in this case, I guess. | 20:25.37 |
| | in general !! is a nice trick for forcing a boolean value to be 0 or 1 rather than 0 or non-zero | 20:26.03 |
| ray_laptop | Robin_Watts: why the not not ? | 20:26.03 |
| Robin_Watts | !!x = 0 iff x =0, 1 otherwise | 20:26.43 |
| | Interesting. | 20:27.31 |
| | Comparing the EFF fonts side by side in fontforge with the MS ones, the 'widths' all look the same (assuming I'm not being confused) | 20:28.19 |
| | but the kerning data differs. | 20:28.28 |
| ray_laptop | and does the code use the kerning ? | 20:34.22 |
| Robin_Watts | I believe so. | 20:37.08 |
| | But I can't see how to read/edit the vertical spacing for the font in fontforge. | 20:37.32 |
| henrys | Robin_Watts: I have an errand to do but I can poke at that later if you'd like. | 20:39.01 |
| Robin_Watts | henrys: I'm happy to burble along for a while longer, but then this is all new to me. It's possible that someone else could spot something obvious far faster. | 20:40.04 |
| | You can grab peeved:/home/robin/sauce/resources/fonts/eff.tgz | 20:41.04 |
| | and look in electronic.font.foundry/truetype/wgl4/ | 20:41.29 |
| henrys | Robin_Watts: okay I'll be back a bit latter and I'll read the logs, then look at the fonts | 20:41.32 |
| Robin_Watts | electronic.font.foundry/readme.txt says what corresponds to what. | 20:42.03 |
| toothrot | is this channel publicly logged? | 20:53.46 |
| | sorry | 20:53.50 |
| | it's in the topic, not sure how i missed that | 20:53.59 |
| | now everyone can look in the logs and see what a tool i am | 20:54.35 |
| | i'm coming back to my possible bug report about the way blocks of text are grouped: http://imgur.com/a/BW6xM | 20:59.54 |
| | to clarify: i'm relying on positions of text in some instances, so the places where text is grouped together across lots of whitespace is causing an issue (in regards to moving from poppler, that is) | 21:05.00 |
| Robin_Watts | toothrot: What's the problem here? | 21:14.07 |
| | oh, so it's the lines at the top? | 21:14.32 |
| toothrot | right, poppler does it too (towards the bottom) | 21:15.32 |
| Robin_Watts | toothrot: I'd assume that you're getting a single line, but as 2 spans ? | 21:16.57 |
| | going once... | 21:18.47 |
| toothrot | i'm here.. | 21:18.55 |
| | asking what i'm getting in poppler? | 21:19.08 |
| Robin_Watts | No. | 21:19.13 |
| | In MuPDF, when you get a line that has BLAH BLAH FOO BAR | 21:19.33 |
| | I'd assume that that's a span with BLAH BLAH then another span in the same line with FOO BAR | 21:19.51 |
| toothrot | i think you are right, let me go back and see how many spans there are within the line. | 21:20.56 |
| Robin_Watts | In that case you can split for yourself if there is a big gap between the spans. | 21:22.37 |
| | I'm about done for the night. | 21:22.45 |
| toothrot | got it, i'll take a look and offer more info at a later date if needed. | 21:23.07 |
| | thanks for the suggestion/time. | 21:23.12 |
| Robin_Watts | If you are seeing the big gap within a single span, then open a bug on bugs.ghostscript.com and I'll have a look. | 21:23.20 |
| | or I'll be back tomorrow morning :) | 21:23.42 |
| toothrot | right, have a good night | 21:23.45 |
| Robin_Watts | you too. | 21:23.52 |
| | Forward 1 day (to 2014/02/07)>>> | |
IRC Logs