| | <<<Back 1 day (to 2012/06/17) | 2012/06/18 |
| kens | chrisl had a quick look at the bmpcmp for the files showing diffs. Most are the same as the test file in question, the text is shifted slightly 'up and right', bug692576.ps shows significant improvement though (as well as a problem). | 08:32.33 |
| chrisl | kens: yes, I noticed a few progressions, but rather more regressions :-( | 08:50.46 |
| kens | Well, I think it was actually my change I was testing | 08:51.02 |
| | The problem with your change is that it sets the text mode wrongly in the garphics state | 08:51.22 |
| | So it doesn't emit a /W or /DW entry in the font | 08:51.33 |
| | Mine does, but seems to get it wrong ins some sense | 08:51.43 |
| | I think its applying the shift twice (maybe) | 08:51.51 |
| | So I'm off debugging throgh the smaller file you created | 08:52.26 |
| | FWIW pdfwrite and Distiller simply produce a TrueType CIDFont with no wmode, so it defaults to 0. | 08:53.35 |
| | WHich is a whole lot simpler. | 08:53.47 |
| chrisl | IIRC, the wmode in the original file stems from the CMap | 08:54.17 |
| | It's possible the progressions I saw were in a different iteration of my experiments....... | 08:54.58 |
| kens | Hmmm... | 08:55.08 |
| | The Distiller CMap has no WMode, ours is a copy of the original, oso it has a WMode of 1 | 08:55.25 |
| | I winder what happens if I hack it to 0.... | 08:55.58 |
| chrisl | So in ours we have both a CIDFont with wmode 1 *and* a CMap with wmode 1? | 08:56.31 |
| kens | No, we have a CIDFont with no WMode and a CMap with a WMode of 1 | 08:56.47 |
| chrisl | Well, that is an accurate representation of the input...... | 08:57.20 |
| kens | Sure is :) | 08:57.28 |
| | AH, but if I hack the WMode to 0, it seems the result is better..... | 08:57.52 |
| | Well the spacing is correct that way, but its in the wrong place :-( | 08:58.25 |
| kens | thinks this whole thing is a tupid idea. | 08:58.42 |
| chrisl | Unfortunately, it's all perfectly allowable in the spec. | 08:59.19 |
| kens | chrisl where's the documentation on the use of WMode 1 with a font which has no vertical metrics ? I'm not convinced Acrobat is behabing the same way | 09:12.21 |
| chrisl | Er, good question...... | 09:12.55 |
| kens | Well its certainly doing 'something' different if I change the CMap WMode from 1 to 0. | 09:13.55 |
| chrisl | PLRM p332: "If a font contains only one set of metrics, the WMode parameter is ignored" | 09:17.24 |
| kens | Hmm, I wonder what the PDFRM says.... | 09:17.37 |
| | I'm not convinced its the same | 09:17.56 |
| chrisl | Probably nothing at all, since the font metrics in PDF are not reliant on the font content...... | 09:18.12 |
| kens | Not on the font stream, certainly | 09:18.41 |
| | But there are /W and /W2 widths arraysz | 09:18.50 |
| | Hmm, it seems only to say that the font and CMap WMode should be the same .... | 09:20.27 |
| chrisl | Does it? I thought it said CMap WMode overrides font WMode | 09:21.09 |
| kens | It says its defined by the CMap entry, so in a sense that's true. | 09:21.45 |
| | "Glyphs from a CIDFont can be shown in vertical writing mode. (This is selected by the WMode entry in the associated CMap dictionary; see Section 5.6.4, CMaps.) To be used in this way, the CIDFont must define the vertical displacement for each glyph" | 09:22.06 |
| | The default position vector and vertical displacement vector are specified by the DW2 entry in the CIDFont dictionary | 09:22.28 |
| chrisl | Yeh, in the PLRM it says that the CIDFont's WMode only applies when showing glyphs directly, and not via a CMap | 09:22.56 |
| | So, that's basically the same | 09:23.12 |
| kens | Except that the PDF manual indicates that we should have a /W2 array, and we don't | 09:23.30 |
| | Nor do we have a /DW2 | 09:23.41 |
| chrisl | The output I'm looking at does have both /W2 and /DW2 | 09:24.16 |
| kens | Really ? Mine didn't | 09:24.31 |
| chrisl | This is using master, no changes applied | 09:24.54 |
| kens | Ah, then that would make sense | 09:25.01 |
| | I was looking at the output from your and my changes | 09:25.10 |
| | master will output /DW2 because it thinks the font is vertical | 09:25.29 |
| | I think we need to maintain that, which my change doesn't do | 09:25.47 |
| chrisl | So, maybe what we need is DW2 and W2 with only "vertical" metrics in them? | 09:25.58 |
| kens | I think that is the case, yes | 09:26.06 |
| | We need to take the horizontal metrics and output them as vertical metrics | 09:26.26 |
| | But I think there's a wrinkle that pdfwrite tracks the current text position itself | 09:26.42 |
| | And I think its applying that wrongly | 09:26.50 |
| | WHich is why the text ends up in the wrong place | 09:27.00 |
| | But I'm not sure about that yet | 09:27.13 |
| chrisl | It has to track the current text position so it can update current point before returning to the interpreter | 09:27.26 |
| kens | Yes, but also so that it can accumulate text | 09:27.42 |
| | and apply relevant spacing PDF operators | 09:27.51 |
| | I have a feeling that its picking up the wrong information again somewhere | 09:28.41 |
| chrisl | I can't remember the format of the DW2 and W2 entries, but the ones I'm looking at aren't making much sense to me, just now.... | 09:28.47 |
| kens | They aren't that hard | 09:28.56 |
| | DW2 is an array of 2 numbers, W2 is an array of 3 numbers | 09:29.44 |
| chrisl | Right, it looks to me like all the metrics in DW2 and W2 are 0 | 09:29.46 |
| kens | Yes, because we need to store them in the right array in the text state, and I think we aren't. | 09:30.28 |
| | My change forced them into the horizontal array, btu that looks to be incorrect | 09:30.46 |
| | THey need to be in the vertical array | 09:30.58 |
| | Anyway, back to the debugger | 09:31.06 |
| chrisl | So, we're getting the vertical displacement wrong, which explains why we appear to get the wrong baseline | 09:32.01 |
| kens | I think this is the case, yes | 09:32.15 |
| | But we also get the horizontal wrong too. | 09:32.23 |
| | Well, that looks 'better'. | 09:36.32 |
| | No, vertical and horizontal displacement is incorrect | 09:37.15 |
| chrisl | kens: if it makes things easier, it's pretty easy to remove the CDevProc from the cut down file | 09:44.26 |
| kens | Tha'ts not causing me problems, understanding the spec however.... | 09:44.54 |
| | I think the vertical writing origina is (possibly) incorrect. | 09:45.09 |
| chrisl | I'm not sure we should be using the vertical writing origin..... | 09:47.23 |
| kens | If we're a vertical writing font ? | 09:47.34 |
| chrisl | But we're not, by my way of thinking | 09:47.51 |
| kens | We will be if we have a CMap with a WMode of 1 and a DW2 and W2 array in the font | 09:48.21 |
| chrisl | I meant in the source file | 09:48.52 |
| kens | Oh I'm looking at the PDF not the source | 09:49.04 |
| nlogax | You guys are awesome. Doing some direct PS work, and had a broken (and huge!) .eps file, that could not be included, but Preview.app managed to display it (after converting it to PDF) | 10:58.38 |
| tor8 | Robin_Watts: ping. | 10:59.28 |
| nlogax | Saved that and tried gs -sDEVICE=epswrite -sOutputFile=broken.eps broken.pdf, and not only does it work, it's 10 KB instead of 395 KB | 10:59.28 |
| Robin_Watts | tor8: chariots chariots | 10:59.39 |
| tor8 | Robin_Watts: eh? what's that from? | 10:59.51 |
| Robin_Watts | Portal2, PPT. Never mind :) | 11:00.03 |
| tor8 | Robin_Watts: hm, that reminds me I should take a look at that DLC thingy you showed | 11:00.25 |
| | Robin_Watts: the soft mask issue you and ray ran into, quick summary or pointer to discussion and fix? | 11:00.38 |
| Robin_Watts | tor8: quick summary... | 11:00.54 |
| | The way the pdf interpreter handles smasks, it redraws the smask for every object that is masked. | 11:01.38 |
| | alexcher pointed out that this is (at least partially) because in gs you need to give a bounding box for the smasked area before you draw the smask, and you can't easily look too much further ahead. | 11:02.37 |
| tor8 | right, so that was the pdf interpreter state getting cocked up? | 11:03.02 |
| Robin_Watts | Further, it doesn't remove the smask from being current, until the next smask has finished being drawn. | 11:03.15 |
| | which means that if you have any groups within the 'next smask' then the current smask will be applied to them. | 11:03.47 |
| | (where 'next smask' can actually be 'the current smask being rendered again') | 11:03.59 |
| | The fix is entirely within the pdf interpreter code (i.e. in the postscript). | 11:04.20 |
| tor8 | right. completely unrelated to anything xps then. | 11:04.40 |
| Robin_Watts | That's not to say that there isn't an underlying library flaw. | 11:04.46 |
| | Perhaps the library could be better structured to avoid this ever becoming an issue? I don't claim to have a clear enough view of the problem to know the answer. | 11:05.25 |
| | so, it's possible that xps is falling into the same pitfall, but I wouldn't like to bet on it. | 11:06.06 |
| tor8 | ohhh... it might be a clip state balancing problem in ghostxps that's causing weirdness here | 11:07.10 |
| | yes indeed, the clip mask survives the grestore! | 11:14.27 |
| Robin_Watts | tor8: Yeah. | 11:14.48 |
| | You need zpushextendedgraphicsstate and zpopextendedgraphicsstate too. | 11:15.15 |
| | (or whatever the non postscript versions of them are) | 11:15.23 |
| tor8 | so gsave/grestore have stopped saving/restoring clip state? | 11:15.38 |
| Robin_Watts | gsave/grestore have never touched smasks, AIUI. | 11:15.53 |
| tor8 | gs_gsave/gs_grestore that is | 11:15.57 |
| | not smasks, regular old clip masks | 11:16.04 |
| Robin_Watts | oh. not as far as I know. | 11:16.19 |
| tor8 | I've got a clip path that survives the grestore (or I've got unbalanced grestores) | 11:16.25 |
| | but only if there's a soft mask in the next (sibling) canvas element... | 11:17.23 |
| | and only if said soft mask is drawn using a tiling pattern | 11:19.25 |
| | this. is. weird. | 11:19.59 |
| Robin_Watts | sounds it. | 11:20.39 |
| tor8 | okay, it may well be the soft mask that's not being pushed/popped properly (since the first soft mask is affected by the clip) | 11:21.02 |
| | so it looks like my fix for 692513 exposes this bug instead... *sigh* now I remember why I love working with the ghostscript graphics library :) | 11:22.29 |
| Robin_Watts | paulgardiner: ping | 11:25.50 |
| | v1.4/ucm082348.pdf was the one remaining SEGV. And my fix for it was in pdf_js.c in field_getValue to cope with pdf_file_getValue returning NULL. | 11:27.26 |
| | I'll leave it to you to decide if that is the right fix or not. | 11:27.41 |
| kens | chrisl ,the reason your code works is because it emits neither a /W nor /W2 array (these are optional). As a result the file uses the actual font metrics, which is why it renders correctly. It looks like the regressions are (at least in part) for the same reason, instead of using a custom width, we end up with no /W or /W2 array, so we use the font width. But for these cases (all PDF files I think) the answer is then incorrect. | 11:55.40 |
| | If I supply either a /W or /W2 array, using the widths retrieved fro teh font, then the result is incorrect. | 11:56.05 |
| | I don't know why yet. | 11:56.11 |
| chrisl | kens: Hmmm, so the W2 array probably needs to have an offset to get from the vertical writing origin "back" to the horizontal writing origin? | 12:09.37 |
| kens | chrisl, maybe.... | 12:10.19 |
| | I'm a bit confused by the whole thing right now | 12:10.28 |
| chrisl | kens: well, let me know if you want me to look at it again | 12:12.06 |
| kens | chrisl I've got two very similar PDF files, woudl you mind taking a peek ? | 12:12.30 |
| | One has /DW and /DW2, one doesn't | 12:12.42 |
| | they render differently and I'd like an opinion on why | 12:12.51 |
| chrisl | Sure, can do | 12:12.58 |
| kens | the difference is vertical | 12:13.02 |
| | will email files now | 12:13.06 |
| | unimaginitively named fiels on the way now | 12:13.43 |
| chrisl | Okay, I'm going to grab a coffee before I look at them | 12:14.14 |
| kens | Not a bad idea | 12:14.23 |
| kens | goes to fetch a coffee too | 12:20.46 |
| | chrisl when I say those two files render differently, I mean that Acrobat displays them with the text at different y positions | 12:30.25 |
| chrisl | Yes, I got that - so do we, I'm relieved to note..... | 12:30.56 |
| kens | OK that's something I'd forgotten to test | 12:31.07 |
| | Can you tell me why ? | 12:31.13 |
| chrisl | Not yet. The metrics we read out the font are the same for both....... | 12:31.45 |
| kens | Yeah | 12:31.52 |
| | I'm really puzzled by the *first& glyph, because surely it should not apply any ,etrics before rendering, and yet it is differently positioned | 12:32.17 |
| chrisl | Oooh, but the metrics from the CDevProc are *very* different..... | 12:32.40 |
| kens | Urk, they are ? | 12:32.52 |
| | Oh dear.... | 12:32.59 |
| | That might explain a lot | 12:33.10 |
| chrisl | I would expect that given that we apply the PDF widths via the CDevProc, and the two files have different width arrays | 12:33.48 |
| kens | Oh *that* CDevProc :-) | 12:34.02 |
| | I was thinking of the original PostScript file.... | 12:34.12 |
| chrisl | That may explain why the two render differently, though | 12:35.05 |
| kens | Possibly | 12:35.14 |
| | I don't understand where the vertical offset comes form | 12:35.24 |
| | Do we apply a Metric before rendering the first glyph ? | 12:35.45 |
| | THat would seem odd. | 12:35.50 |
| chrisl | We have to apply metrics before rendering the first glyph, so we can setup the cache device | 12:36.31 |
| kens | But surely that should not change the origin ? | 12:36.52 |
| | Hmm, I suppose it might change the 'vertical' origin | 12:37.02 |
| | By moving teh current point to the verical origin first ? | 12:37.15 |
| chrisl | The coordinates of the origin are passed to CDevProc and setcachedevice2, aren't they? | 12:38.56 |
| kens | Don't know | 12:39.07 |
| chrisl | Hmm, no, but the bbox is. Actually, this is odd..... | 12:40.39 |
| kens | I'm glad I'm not the only one that's puzzled | 12:40.51 |
| chrisl | For out.pdf, the parameters going to setcachedevice2 for the first glyph are: {0, 0, 0.095703125, 0, 0.57470703125, 0.71728515625, 0, -1, 0, 0.87999999523162842} | 12:41.56 |
| | And for new.pdf, they are: {0.61100000143051147, 0, 0.095703125, 0, 0.57470703125, 0.71728515625, 0, 0.61100000143051147, 0.079999998211860657, 0} | 12:42.13 |
| | I can't see why the origin would be different, though...... | 12:43.23 |
| kens | THat's what's puzzling me | 12:43.35 |
| | I can understand w0x and w0y being different | 12:43.48 |
| chrisl | If everything was working correctly, I would expect them to be the same | 12:44.29 |
| kens | Well, I'm not sure that the values in the W2 array are 'right' | 12:44.59 |
| chrisl | Exactly, but the same glyph, in the same font, I would expect the horizontal *metrics* to be the same, regardless of the existence of vertical metrics, or the wmode | 12:45.46 |
| kens | Yes I guess W0x and w0y should be untouched | 12:46.42 |
| | w1x and w1y might reasonably be different | 12:46.55 |
| chrisl | Yes, I would expect the vertical metrics to be all zeros in one, and "something" in the other..... | 12:47.26 |
| kens | out.pdf should have all 0s for vertical metrics I think | 12:47.46 |
| chrisl | Of course, that rather depends how the pdf interpreter creates the custom CDevProc...... | 12:48.46 |
| kens | chrisl try changing the first /W2 entry from : | 12:57.32 |
| | To: | 12:57.32 |
| | W2[41[0 80 611] | 12:57.39 |
| chrisl | That renders the "F" closer to the correct position | 13:00.21 |
| kens | Indeed | 13:00.27 |
| | Which indicates (to me) that it *is* hte /W2 metric causing it to be drawn tehre | 13:00.44 |
| chrisl | Yep | 13:01.04 |
| kens | Of course this whole job is cimplicated by the fact that teh CTM is flipped vertically.... | 13:01.05 |
| | chrisl its teh 'position vector' that moves the glyphs | 13:20.58 |
| | THis is the second and third elements of the W2 array | 13:21.13 |
| | It defines the x/y offset of the vertical origin from teh horizontal origin | 13:21.28 |
| | SO 0,0 menas that teh vertical origin is the same as the horizontal origin | 13:21.45 |
| | The entries we are writing have a horizontal displacement but not a vertical displacement | 13:22.30 |
| | The reason the glyph moves *down* the page when we have a vertical displacement is (I think) because the CTM is vertically flipped | 13:23.09 |
| chrisl | Sorry, I had a phone call..... | 13:24.37 |
| kens | NP | 13:24.42 |
| chrisl | Yes, that's what I figured, I was just struggling to find *where* the numbers were coming from - but the inverted CTM would account for that, I think | 13:25.18 |
| kens | Yes I think so, and it is part of the problem too. | 13:25.35 |
| | Hmm, that can't be all of it | 13:31.54 |
| | If I set the displacement to 0 the glyph *still* comes out too high up :-( | 13:32.10 |
| chrisl | This is in new.pdf? | 13:34.44 |
| kens | Yes, I've been ahcking it | 13:34.58 |
| chrisl | Well, the original new.pdf you sent me, I get a vy value of 0.0 for all the glyphs already | 13:35.43 |
| kens | Yes, if I change that to be the 'width' of the glyph, then I see it move up and down | 13:36.10 |
| | Obviously that's not correct :-) | 13:36.17 |
| | I still can't see why the initial glyph is placed where it is. | 13:36.32 |
| | If I could solve that offset the code I have here would work I think. | 13:37.24 |
| chrisl | Well, the currentpoint is the same between both PDF files when we get to zshow()....... | 13:38.40 |
| kens | I know, but they sure don't render in teh same place.... | 13:38.54 |
| chrisl | No, and I *think* the currentpoint is different by the time we get to the end of show_proceed() | 13:39.41 |
| kens | I wish I knew why.... | 13:39.52 |
| chrisl | Right now I'd settle for "where".... | 13:40.13 |
| kens | same thing really :-) | 13:40.22 |
| chrisl | Hmm, no I have to retract that, the currentpoint is the same in both cases at the end of show_proceed() :-( | 13:50.58 |
| kens | :-( | 13:51.49 |
| chrisl | So, the first time we get a difference between the numbers between the two jobs is on the return from the CDevProc | 13:57.07 |
| kens | OK that suggests the CDevProcs is picking up values from 'somewhere', which implies the /W or /W2 array | 13:57.39 |
| chrisl | Aha, gx_show_text_set_cache() moves the current point in accordance with the vx and vy parameters | 13:58.19 |
| kens | Right. | 13:58.33 |
| | That seems reasonable | 13:58.40 |
| | Except that they are 0, so shouldn't be getting moved.... | 13:58.54 |
| chrisl | No, in neither case are the coordinates zero | 13:59.14 |
| kens | teh Vy should be | 13:59.35 |
| chrisl | In out.pdf, vx = 0 and vy = 0.87999999 | 14:00.09 |
| kens | That sounds wrong | 14:00.26 |
| | Actually, no maybe that is OK | 14:00.33 |
| chrisl | and in new.pdf: vx = 0.0799999982 and vy = 0 | 14:00.37 |
| kens | Yes, in new.pdf vy should be 0 | 14:00.45 |
| | vx is 'wrong' in that case mind you | 14:01.31 |
| | I don't see why vy is non-zero for out.pdf though | 14:02.07 |
| | There is no /W2 array, and no /DW2 | 14:03.02 |
| | Even DW is 0 | 14:03.17 |
| chrisl | No, I don't understand that, either. I wonder if we are rendering out.pdf wrongly, too...... | 14:03.44 |
| kens | That is possible, but.... | 14:03.58 |
| | Acrobat draws out.pdf differntly to new.pdf as well | 14:04.10 |
| | I'll export some tiffs | 14:04.25 |
| chrisl | In the absence of a DW2 value, we use the default..... | 14:06.09 |
| kens | Which is 1000 I guess. | 14:06.19 |
| chrisl | [ 880 -1000 ] | 14:06.28 |
| kens | Really ? | 14:06.33 |
| | -1000 makes sense | 14:06.48 |
| | This probably explains why the output is shifted even when we have no /DW2 | 14:07.12 |
| chrisl | page 437 in my PDFRM | 14:07.15 |
| kens | The default is not correct :-) | 14:07.19 |
| chrisl | If only...... | 14:07.54 |
| kens | Well, its not correct for this file I mean | 14:08.15 |
| | Acrobat and GS rendering match, so I guess we are using the same default. | 14:10.01 |
| chrisl | So, I think we're now certain that the W2 contents are wrong...... | 14:11.03 |
| kens | Well, sort of wrong. | 14:11.14 |
| | THey are incorrect, certainly but I'm not sure how to 'fix' them. | 14:11.29 |
| | Because the vertical axis is flipped, if we supply teh height of the glyph as an argument to /W2 then the top of the glyphs will allign, rather then the baslines. | 14:12.56 |
| chrisl | It's not the height, though, is it? I thought it was the offset from one origin to the other | 14:14.06 |
| kens | Yes, that's correct. | 14:14.18 |
| | I think the 'right' answer is to do what Acrobat does. | 14:15.02 |
| | Turn it back into a horizontal font. | 14:15.14 |
| chrisl | Well, as I said, I tried that at the Postscript level, and it really didn't work well. I'm also concerned with what might happen if we have a font with vertical metrics for *some* of the glyphs (although, anyone producing such should be shot!) | 14:17.17 |
| kens | yes that was a worry as well. | 14:17.30 |
| | But I cannot see a way to get 'correct' metrcs out for a vertical writing font | 14:17.50 |
| | It seems to me that Acrobat doesn't do the 'ignore the WMode if there are no vertical metrics' thing. | 14:18.27 |
| | If there are no verticla metrics it makes them up. | 14:18.40 |
| chrisl | No, it's not the same thing, though - the "ignore WMode without appropriate metrics" applies to *font* metrics, *not* PDF metrics - and we know they are not treated as equivalent..... | 14:19.51 |
| | (despite that the spec claims.....) | 14:20.11 |
| kens | Basically, you can't have 'no PDF metrics' | 14:20.35 |
| chrisl | Yes, so the condition should never apply. In PDF a WMode 1 font will *always* have vertical metrics. | 14:21.34 |
| kens | So they always override the font, so the situation can't arise... What you said :-) | 14:21.43 |
| | I'll go think about it some more | 14:22.27 |
| chrisl | Can you point me at somewhere in the scan_cmap_text() to set a break point to see the handling of the return from the CDevProc? | 14:23.02 |
| kens | Line 582 is where we exit to execute teh CDevproc | 14:23.49 |
| | Next entry to scan_cmap_text teh CDevProc will have been executed | 14:24.07 |
| chrisl | So, we then repeat all the processing up to that point? | 14:24.30 |
| kens | Yes | 14:24.37 |
| chrisl | <sigh> | 14:24.45 |
| kens | Having set some flag so we don't repeat the CDevProc | 14:24.47 |
| chrisl | I guess a proper state machine was just to difficult...... | 14:25.28 |
| kens | Well the whole tourine is horrible | 14:25.47 |
| | routine* | 14:26.15 |
| chrisl | kens: something interesting: in pdf_glyph_widths() we set the vertical metrics regardless of what we get back from glyph_info..... | 14:53.10 |
| kens | really ? That seems wrong | 14:53.25 |
| chrisl | By the time we return from calling the CDevProc, the font info we get back is gone | 14:54.05 |
| | It *may* be done that way for when we're running a PDF file | 14:55.40 |
| kens | Hmm, not sure. | 14:55.56 |
| | Its not doing any harm though | 14:56.02 |
| chrisl | If I stop that happening, the customer file converts (close to?) correctly | 14:57.26 |
| kens | I'm surprised..... | 14:58.02 |
| | I can't see why it makes a difference. | 14:58.55 |
| | Because we don't write the vertical widths. Hmm, or maybe that's the point.... | 14:59.17 |
| chrisl | In gdevpdtt.c, line 2662, I changed the conditional "if ((info.members & (GLYPH_INFO_VVECTOR0 | GLYPH_INFO_VVECTOR1)) != 0)" to "if (0)", and the customer file converts "convincingly" | 15:02.21 |
| kens | Hmm, I'll give that a try | 15:06.39 |
| chrisl | And with that hack, the text in the cut down test file renders in the same position as when converted by Distiller and exported to tiff by Acrobat....... | 15:09.04 |
| kens | Hmm, let me run some tests | 15:09.15 |
| | I wonder what that flag does.... | 15:09.57 |
| chrisl | I was just going to start looking | 15:10.14 |
| | Huh, that doesn't seem right....... | 15:12.39 |
| | kens: gdevpdte.c, line 706 | 15:13.09 |
| kens | ah.... | 15:21.36 |
| chrisl | So, we're ignoring that the font contains no (valid) Metrics2, and then relying on knowing that elsewhere..... | 15:22.18 |
| henrys | Did a triathlon yesterday with some brit friends and they brought one of your concoctions "Pimm's" for after the race, quite good, never had it before. | 15:26.06 |
| Robin_Watts | henrys: Ah. Filthy stuff. | 15:26.24 |
| chrisl | I don't think I've ever had Pimm's - a bit too much of the "garden party set" for me....... | 15:31.08 |
| Robin_Watts | chrisl: I'd say it tasted foul, but then, as a scot, you probably drink Irn Bru... | 15:31.58 |
| | henrys: In light of Guillaumes last mail, I've spend some time playing with the downscaler today. | 15:32.18 |
| chrisl | Robin_Watts: Ugh, no I hate that stuff..... | 15:32.31 |
| Robin_Watts | I now have 3:2 and 3:4 scalers working with tiffsep. | 15:32.37 |
| henrys | Robin_Watts:that might be best | 15:32.50 |
| Robin_Watts | What device is guillaume using? | 15:32.52 |
| henrys | he has reported problems against tiff but he may be developing his own. | 15:33.23 |
| Robin_Watts | tiffsep? Or some other tiff flavour? | 15:33.43 |
| | At the moment, it works on planar devices only. | 15:33.55 |
| | And it requires various changes in the device; all the devices to date assume that 'DownScaleFactor' is an integer they can use to divide width/height by to get the required output size. | 15:34.47 |
| | In order to shoehorn 3:2 and 3:4 in, I've used '32' and '34' respectively (and any attempt to use any other DownScaleFactor > 8 will get you a rangecheck) | 15:35.34 |
| | And devices now call gx_downscaler_scale(width, factor) to get the scaled width. | 15:35.59 |
| | but I've not pushed that through anywhere other than tiffsep. | 15:36.11 |
| | Perhaps I should drop him a mail, tell him what we're thinking, and ask for some example files we can render to get him examples of the quality etc? | 15:37.11 |
| | or, would you rather stay the point of contact? | 15:37.21 |
| henrys | I feel there is a loose end with our conversation which I want to clean up now then you can discuss the scaling issues with him as they come up. | 15:38.13 |
| Robin_Watts | ok. | 15:38.28 |
| henrys | chris you should probably stop work on gsprint - russel wants to host at ghostscript.com so I assume he can do everything we need with guidance. | 15:39.44 |
| | chrisl ^^^ | 15:40.07 |
| chrisl | henrys: Okay. I thought it looked pretty easy to sort out, there doesn't seem to be much to gsprint.... | 15:40.38 |
| henrys | I guess wisc is going away and he wants a new home. I do think it makes more sense that we all work together, think of all the arguments we'd miss if you just did it ;-) | 15:43.46 |
| chrisl | :-) Yes, like I said last week, all the directories where the actual downloads were hosted on wisc just disappeared a couple of months ago, with no notice at all | 15:44.45 |
| henrys | I am tempted to do the complete buyout now, or rather convince miles we should. | 15:46.32 |
| Robin_Watts | henrys: That only works if the bandwidth we have to work on it > bandwidth he spends working on it. | 15:47.05 |
| henrys | I don't know if upside of the work he does is worth being associated with his license and nag screen. | 15:47.52 |
| Robin_Watts | ok, psd devices updated too. | 16:00.02 |
| | Do I check this in, or hold it back for a bit? | 16:00.13 |
| henrys | I think any scaling improvement should be committed. | 16:02.59 |
| Robin_Watts | ok. | 16:03.08 |
| kens | Off till tomorrow, night all | 16:07.50 |
| Robin_Watts | night kens. | 16:08.13 |
| | I've got to take dog to vets, fetch helen etc in a mo. | 16:08.25 |
| mvrhel_laptop | good morning | 16:17.37 |
| Robin_Watts | mvrhel_laptop: Morning. How did the show go? | 16:18.53 |
| mvrhel_laptop | It was a bit disappointing due to the fact that it was very small | 16:19.18 |
| | Apparently, it was probably 1/3 the size it had been in the past | 16:19.45 |
| Robin_Watts | any idea why? recession? | 16:20.43 |
| | I gotta run. bbl. | 16:21.10 |
| henrys | mvrhel_laptop:did folks opt out or was there just a small number that registered in the first place? | 16:22.42 |
| mvrhel_laptop | henrys: apparently AIM pulled out from the show which was supposed to be a combination of AIM and info360 | 16:23.17 |
| henrys | I've grown against doing these shows... I think Scott, Miles and an engineer should just visit all the booths at each show. | 16:24.46 |
| | in this case you'd be done in half a day. | 16:25.40 |
| mvrhel_laptop | We did get a few interested small software companies come by and inquire about MuPDF. | 16:26.01 |
| | Who did not have a booth | 16:26.18 |
| | Luckily the show was only 2 days | 16:26.29 |
| henrys | that's good. | 16:27.23 |
| mvrhel_laptop | I am close to having anti-aliasing in place for tiffsep. Just need to do a bit of work in anti-aliasing. Got the default copy_alpha working and the clist. | 16:27.28 |
| | henrys: Customer #330 has thrown a somewhat tricky color issue that I need to look into after I get this anti-aliasing stuff wrapped up | 16:31.32 |
| henrys | so marcos determined the customer did need that and scaling wouldn't do it? | 16:31.40 |
| mvrhel_laptop | henrys: that was my understanding | 16:31.56 |
| | henrys: To solve this issue from Customer #330, I may need to create a demo device that makes use of an N-color device profile. | 16:35.03 |
| | Or I might be able to use tiffsep | 16:35.23 |
| | which will be my first approach | 16:35.37 |
| | actually, I think that makes more sense | 16:35.57 |
| henrys | mvrhel_laptop:and you have 2 bugs in the aging list other than the AA problem. | 16:40.16 |
| robin_watts_fone | miles has suggested us possibly doing an android show in December. | 16:41.34 |
| mvrhel_laptop | robin_watts_fone: yes I suggested that one | 16:42.41 |
| | when we were sitting around at the show this week | 16:42.48 |
| henrys | are you irc'ing while driving again? | 16:42.49 |
| robin_watts_fone | I suspect in that case there may be justification for us doing the show - its basically a developer conference so there might be lots of people that want to talk to us. | 16:43.01 |
| mvrhel_laptop | yes exactly | 16:43.12 |
| robin_watts_fone | waiting in the vets :) | 16:43.25 |
| mvrhel_laptop | henrys: ok I will look into those 2 before working on the #330 issue | 16:43.27 |
| | I am going to open a bug for the #330 issue | 16:43.36 |
| robin_watts_fone | but 4 days seems a lot. | 16:43.41 |
| mvrhel_laptop | those 4 days are not all with a booth | 16:44.05 |
| | I think some of those days are for courses etc | 16:44.13 |
| | the exhibitors I think are there for only 2 days | 16:44.27 |
| robin_watts_fone | ah. that makes a lot more sense. | 16:46.27 |
| | I get the feeling that we'd get a lot more licensees if they weren't all being scared off my Scotts huge list of questions. | 16:47.30 |
| henrys | it would seem robin_watts_fone would be a good candidate to be the technical rep for that show. | 16:48.05 |
| | robin_watts_fone:it sounds like Guillaume doesn't have a problem with scaling - he can do it himself he doesn't want to incur the penalty. | 16:50.17 |
| robin_watts_fone | would I need to wear a suit? | 16:50.33 |
| | vet. bbl. | 16:51.06 |
| henrys | robin_watts_fone:a minor negotiation point. | 16:55.09 |
| mvrhel_laptop | henrys: ok. So I need to test this AA fix for tiffsep to see if anything explodes | 16:59.09 |
| | is marcos back yet? | 16:59.19 |
| | that is I want to test -sDEVICE=psdcmyk with AA on for text and graphics | 17:00.31 |
| | and at least look for segvs | 17:00.51 |
| henrys | mvrhel_laptop:no I don't think he is back, but you can send him an email - I think he has a link but it is too slow for support. | 17:03.34 |
| mvrhel_laptop | ok. | 17:03.50 |
| | I may do a cluster push test as it is just to make sure nothing is really screwed up | 17:05.34 |
| henrys | we really should be able to get md5 sums for any device using the cluster. It seems like that wouldn't be hard. | 17:06.57 |
| mvrhel_laptop | henrys: the issue is that we dont have AA right now for psdcmyk, so as far as a rendering comparison we cant really do that | 17:07.38 |
| | all the md5s will be different | 17:08.02 |
| | for psdcmyk | 17:08.12 |
| henrys | buy you just want to test for crashes right? | 17:08.33 |
| mvrhel_laptop | yes | 17:08.37 |
| | basically, I want the psdcmyk device to be executed with -dGraphicAlphaBits=4 -dGraphicTextBits=4 | 17:09.41 |
| | oops | 17:09.51 |
| | -dTextAlphaBits | 17:10.00 |
| | u know what I mean | 17:10.09 |
| henrys | is psdcmyk run now? | 17:10.48 |
| | in the cluster? | 17:11.31 |
| | it is simple enough to set a device parameter in the startup postscript. | 17:13.07 |
| mvrhel_laptop | henrys: yes | 17:13.11 |
| | oh ok | 17:13.16 |
| | for that device only? | 17:13.49 |
| | oh I suppose I should do it for all | 17:14.03 |
| | an make sure nothing explodes | 17:14.09 |
| | s/an/and/ | 17:14.18 |
| | let me do this test first with my changes and no AA on | 17:14.53 |
| | ok that is started | 17:16.09 |
| | henrys: so, could you help show me where this "easy" setting can be done in the startup postscript? | 17:16.50 |
| henrys | oh gs_init.ps around 1182? | 17:19.51 |
| | sorry 1850 | 17:20.16 |
| | maybe easier to update the c code directly. | 17:22.17 |
| mvrhel_laptop | hehe | 17:22.24 |
| | yes, I could do that | 17:22.32 |
| | good point | 17:22.45 |
| henrys | specifically what is you set tab and gab to true in gsdparams.c | 17:24.06 |
| | s/is/if | 17:24.18 |
| mvrhel_laptop | oh even better than I was thinking | 17:24.47 |
| | let me try that once and do a test | 17:24.57 |
| chrisl | mvrhel_laptop: it should be pretty easy to have gs_init.ps set the device param | 17:27.26 |
| mvrhel_laptop | chrisl: easy for you amigo. deefeecult for me | 17:28.13 |
| | if you have a few lines of PS that I can stick in that would be fine | 17:28.41 |
| chrisl | mvrhel_laptop: I just want to check this before I give you a wild goose chase..... | 17:28.42 |
| | Okay, around line 2180, there's a line with "/vmreclaim where" on it...... | 17:31.00 |
| mvrhel_laptop | which file is this? | 17:31.22 |
| chrisl | gs_init.ps | 17:31.31 |
| mvrhel_laptop | ok | 17:31.36 |
| | found that | 17:32.01 |
| chrisl | Just above that is a comment, and then above the comment, you can add: | 17:32.04 |
| | systemdict /GraphicsAlphaBits 2 put | 17:32.11 |
| | systemdict /TextAlphaBits 2 put | 17:32.18 |
| mvrhel_laptop | ok that is easy enough | 17:32.50 |
| | thanks! | 17:33.02 |
| | let me do a test run with that | 17:33.07 |
| chrisl | Just double check the exact strings for the parameters - I always seem to get the capitalization wrong.... | 17:33.29 |
| mvrhel_laptop | ok | 17:33.41 |
| | chrisl: that did not work :( | 17:38.30 |
| chrisl | Huh, maybe it needs to be earlier in gs_init.ps, then - let me check | 17:39.02 |
| | mvrhel_laptop: it works for me, using ppmraw.... | 17:40.51 |
| mvrhel_laptop | let me try with ppmraw | 17:41.16 |
| chrisl | mvrhel_laptop: you are remembering that the init files are built into the exe? | 17:41.50 |
| mvrhel_laptop | huh | 17:42.04 |
| | I did not remember that | 17:42.16 |
| | since when? | 17:42.23 |
| chrisl | Er, years now? | 17:42.40 |
| mvrhel_laptop | heh | 17:42.43 |
| | hmm | 17:42.51 |
| chrisl | Or is it millenia..... | 17:43.21 |
| mvrhel_laptop | oh I probably never do changes in gs_init.ps | 17:43.40 |
| | only pdf_draw etc | 17:43.47 |
| | those are not build in are they? | 17:43.53 |
| chrisl | Yes, they are | 17:43.59 |
| mvrhel_laptop | that is weird | 17:44.06 |
| | I swear I recall doing changes in those and not having to to a full clean and rebuild | 17:44.27 |
| | but apparently I lost some neurons hanging out with Scott in NY | 17:44.41 |
| chrisl | You can use the -I option to prepend a directory to the search path, that's what I usually do | 17:45.10 |
| mvrhel_laptop | I do that when I run a script but I dont have that in the parameters in the visual studio command line | 17:45.42 |
| chrisl | You probably don't need a full clean and rebuild - there is something funky about the dependencies, so we pretty much always rebuild the romfs :-( | 17:46.49 |
| mvrhel_laptop | actually, I thought when you do a build in visual studio it rebuilds the romfs | 17:46.57 |
| | yes | 17:47.08 |
| | so I am not sure why I would be having this issue | 17:47.18 |
| | let me rebuild anyway and rerun with tiffsep and ppmraw | 17:47.29 |
| | ok still nothing with tiffsep | 17:49.27 |
| chrisl | Were the AlphaBits params removed from tiffsep when we found it wasn't working? | 17:50.36 |
| mvrhel_laptop | nor nothing for ppmraw | 17:50.53 |
| | chrisl: no | 17:51.02 |
| henrys | I was worried it would get overridden somehow in gs_init.ps, seemed like changing gsdparam.c guarantees it gets set. | 17:51.12 |
| chrisl | mvrhel_laptop: I think I made a mistake.... give me a sec | 17:52.38 |
| mvrhel_laptop | just ran with -dGraphicsAlphaBits=4 and that worked fine... | 17:53.00 |
| chrisl | mvrhel_laptop: okay, I see - I pointed you at the wrong place in the file, sorry | 17:53.40 |
| mvrhel_laptop | ok np | 17:53.47 |
| chrisl | So, look at line 1755 | 17:54.04 |
| mvrhel_laptop | ok | 17:54.24 |
| chrisl | it should have "defaultdevice" on it | 17:54.26 |
| mvrhel_laptop | yes | 17:54.32 |
| chrisl | So we put the two extra lines just after that..... | 17:54.46 |
| mvrhel_laptop | ok | 17:54.52 |
| chrisl | thus: | 17:55.06 |
| | defaultdevice | 17:55.07 |
| | systemdict /GraphicsAlphaBits 4 put | 17:55.09 |
| | systemdict /TextAlphaBits 4 put | 17:55.10 |
| | Fingers crossed....... | 17:55.23 |
| mvrhel_laptop | drum roll.... | 17:55.37 |
| | nope :( | 17:56.17 |
| | I am going to set a break point in gsdparam.c to see what is going on | 17:57.01 |
| chrisl | I, er, am confused...... | 17:57.05 |
| mvrhel_laptop | I am just going to make the change in gsdparam.c | 18:02.28 |
| | much eaiser | 18:02.34 |
| chrisl | Fair enough - odd that it didn't work, though - must be something in Windows...... | 18:03.15 |
| mvrhel_laptop | I have no idea | 18:03.36 |
| | ok. so the fix in gsdparam.c worked | 18:04.11 |
| | thanks for the effort though chrisl | 18:04.45 |
| chrisl | mvrhel_laptop: shame it didn't help..... :-( | 18:05.03 |
| mvrhel_laptop | it is probably my ineptitude in dealing with PS | 18:05.05 |
| chrisl | Or the already excessive complexity of gs_init.ps....... | 18:05.45 |
| | Okay, heading off for the night..... | 18:11.14 |
| mvrhel_laptop | bbiaw | 18:24.56 |
| Robin_Watts | henrys: Something to train for next year... The Big Horn Mountain 50. | 18:44.54 |
| | An old college friend just came in 2nd on it, 7:52:08. | 18:45.29 |
| | Finished with a BP of 78/60 and had to be given IV fluids etc. | 18:46.01 |
| henrys | Robin_Watts:I know folks that do races like that - I can't imagine doing it. Next big effort is going to be an ironman - well after the 1/2 iron man. | 20:04.03 |
| | 102F/39C and 9% humidity in my backyard. Not a good day for the firefighters. | 20:13.46 |
| nlogax | Are there any operators one can use within PostScript to observe memory usage? | 20:57.09 |
| | `vmstatus' perhaps :) | 21:05.03 |
| shelly | for the logs, Henrys, please can you check the email I sent you about the potential bug in the mmr code for jbig2dec | 23:16.35 |
| | Forward 1 day (to 2012/06/19)>>> | |
IRC Logs