| | <<<Back 1 day (to 2012/04/03) | 2012/04/04 |
| robin_watts_mac | mvrhel: Thanks. | 00:16.35 |
| | See you all in a more integer timezone! | 00:16.48 |
| mvrhel | ok. this is not working so well. after each of my high level rect fills, I get 4 fill pages occurring | 01:29.00 |
| | with the clist | 01:29.03 |
| | screwed up something | 01:29.08 |
| | I dont understand this. so the clist gets its initial fill pages and then a pile of hl rect fills during the writing phase. during the reading phase something is not quite right | 01:36.51 |
| | I must be missing some information about what band these rect fills occur in | 02:08.34 |
| | I have to say that the clist code takes the cake in being the most confusing section in ghostscript | 04:58.56 |
| | oh now I see | 05:01.10 |
| | the macro for set_cmd_put_op was a bit confusing stepping through the debugger | 05:13.27 |
| huzaifas | any idea how one could use color profile files .icc with ghostscript? | 06:21.41 |
| mvrhel | morning kens | 06:53.59 |
| kens | Morning Michael, you're up very late | 06:54.14 |
| mvrhel | spent the day fooling with clist tiff sep stuff. *just* now got it working | 06:54.26 |
| | time for bed now | 06:54.32 |
| | had a silly bug that took forever to find | 06:54.43 |
| kens | Not surprised ;-) Good news on the clist stuff though | 06:54.52 |
| mvrhel | yes. now I am hoping the rest of the work is just to clean up a few minor items | 06:55.14 |
| | one is to see if I can get the planar sep device to do the same rounding as the non planar one so that I can more readily find any diffs | 06:55.51 |
| | anyway have a good day | 06:56.04 |
| kens | goodnight Michael | 06:56.10 |
| oy | huzaifas: did you read the documemtation? | 07:05.27 |
| huzaifas | oy: yes, it says its new in ghostscript 9, but i can see icclib source files in ghostscript 8 as well | 07:06.07 |
| kens | has not caught up this far in the logs yet | 07:06.37 |
| oy | huzaifas: ICC support prior to 9.0 was not optimal | 07:06.43 |
| | if you want ICC conversio run smoothly switch to 9.x | 07:07.16 |
| | *conversions | 07:07.31 |
| huzaifas | ok | 07:07.34 |
| kens | I'm surprised Mvrhel didn't catch the ICC question since he did all the work. | 07:12.01 |
| | huzaifas: , oy is quite correct wheil you can use ICC profiles with versions of Ghostscript prior to 9.0 I would advise against it. | 07:12.31 |
| | Its tricky to do, requires the use of the UseCIEColor PostScript switch and will not in any event give results as good as the 9.0 series of relesaes. | 07:13.04 |
| huzaifas | ok | 07:14.47 |
| oy | kens: mvrhel will let me get away with my replay ;-) | 07:17.00 |
| kens | Certainly, like I sadi, the 8.x series was hard to use ICC profiles, and the result was not so good as can be achieved after Michael's work. | 07:17.44 |
| | And thanks for replying by the way. I'm still reading the logs | 07:18.17 |
| oy | np | 07:18.37 |
| kens | chrisl I see from the URL tkamppeter sent that the bounding boxes in Cairo seem to be improved. | 07:20.11 |
| | I'd be interested to see some output. However no sign of them not using transparecny when its not required. | 07:20.35 |
| | Also this insane use of forms and patterns persists. I must add the file I have here to the bug report ;-) | 07:21.02 |
| chrisl | Hmm, I'm surprised they've done anything about it - it had been reported (and ignored) a number of times! | 07:33.54 |
| kens | Me too, a hopeful sign perhaps. | 07:36.44 |
| | The bounding box will help of course, but not using transparency for opaque rendering would be even better. | 07:37.14 |
| chrisl | TBH, I reckon the bounding box thing will be a big help on a lot of the files we've had reported. | 07:38.16 |
| kens | Sure, assuming its really fixed. But not using transparency at all woudl be even better. | 07:38.46 |
| | Actually, I must look at the PDF file I have here and see which version of Cairo made it. | 07:39.04 |
| chrisl | I suspect that not using transparency will be a *much* bigger change for them :-( | 07:40.00 |
| kens | Perhaps, but it must be possible. They don't actually write any transparency objects, so they must know.... | 07:40.28 |
| | Sigh, custoemr #1 with a PCL-XL question about fonts being emitted as bitmaps type 3 | 07:41.06 |
| | So they've sent a nice file with three fonts in it, but only one of the actual font files. | 07:41.25 |
| | A single glyph in one font woudl have been enough | 07:41.50 |
| | Hmm, I wonder if pxldisasm works under mingw | 07:43.31 |
| | Ah, no Python. | 07:44.20 |
| chrisl | you should be able to get python for windows | 07:45.10 |
| kens | Yes, I have it, it doesn't work with pxldisasm | 07:45.50 |
| chrisl | Oh. Time to fire up that Linux VM...... | 07:46.19 |
| kens | Yes that's what I'm doing.... | 07:46.45 |
| | And answering Raed's latest dumb questions. | 07:46.56 |
| tkamppeter | kens, the Cairo fix is in Cairo 1.12, Ubuntyu Preciose will ship 1.10.2, and the Cairo guys say that the changes for the Bounding Boxes are to big to backport as a patch for 1.10.2. | 09:07.58 |
| kens | Yeah I read that Till | 09:08.18 |
| | I guess the file I have here is from an old version of Cairo | 09:08.28 |
| | Hmm.... | 13:09.53 |
| | My latest memory freeing stuff seems to work better than I expected. | 13:10.16 |
| | We were 'leaking' > 1000 blocks, now down to 309. | 13:10.42 |
| | Still seem to be leaking some CharProc data though :-( I thought I'd fixed all those... | 13:12.01 |
| paulgardiner | kens: would gstate->size being 0 in pdf_show_char be a likely cause of some text not being rendered? | 13:24.46 |
| kens | paulgardiner : whereabouts is this ? Can you give me a module and line number ? | 13:25.23 |
| | Are we talking about MuPDF ? I don't know much about MuPDF.... | 13:25.43 |
| paulgardiner | pdf_interpret.c Line 671 | 13:25.59 |
| kens | guesses this is MuPDF | 13:26.12 |
| | I'm afraid I know vert little about MuPDF, but I would expect that an empty gstate should just use whatever is in force at the time. | 13:26.43 |
| | But maybe that's what the gstate is supposed to contain, in which case rendering nothgin woudl not be a surprise. | 13:27.12 |
| paulgardiner | Ok thanks. I'll see what the value is for some of the text that does appear. | 13:28.15 |
| | Ah. That fact that I haven't defined a matrix in the xobject dict might explain the probem. Doh! | 13:31.19 |
| kens | :-) | 13:31.34 |
| chrisl | kens: I think the cairo bbox fix will solve all the viable to solve problems with the cairo output - we already look for "pointless" transparency before enabling the pdf14 device..... | 13:35.50 |
| kens | chrisl that's interesting. | 13:36.07 |
| chrisl | Yes, the problem files we've had reported actually *do* use transparency! | 13:36.43 |
| kens | Though I still think (based on some files I have seen) that it could still be improved by not putting stuff into forms needlessly and possibly some other improvements. | 13:36.46 |
| | chrisl well if they sue transparency they will be slow. I saw (your ?) comment about Acrobat taking nearly as long as we do. | 13:37.15 |
| chrisl | Yep, I suspect for that case, Acrobat is doing something very similar to us - there are images, and smasks involved. | 13:38.50 |
| kens | He, I ran a Memento test with an invalid filename, and it leaked 149 blocks and 562258 bytes. | 13:39.22 |
| chrisl | Seems a lot...... | 13:40.00 |
| kens | Don't know, but it puts the 300 blocks and 700k memory into perspective when running owl | 13:40.27 |
| chrisl | Was the invalid file name for input or output? | 13:41.14 |
| kens | input | 13:41.19 |
| chrisl | Hmm, strange - I thought maybe it just skipped out without cleaning up if the output couldn't be opened...... | 13:41.55 |
| kens | It will still write a (empty) PDf file | 13:42.20 |
| | Because we close the device. But since pdfwrite will not have done much, that's a pretty baseline figure. | 13:42.44 |
| | That represents teh caches and stuff that are setup once and never cleaned up | 13:42.59 |
| henrys | kens:if she uses the printer fonts when creating the pcl it should work okay. Sounded like they did have some control over how the pcl is created but I might be mistaken. | 14:28.05 |
| kens | henrys, at least one of the fonts isn' on the pritner. | 14:28.32 |
| | But I am not at all familiar with teh production of PCL from printer drivers. | 14:28.49 |
| | I can say why pdfwrite won't produce a TT-containing PDF file, btu that's about my limit ;-) | 14:29.32 |
| chrisl | If they've got control over the creation of the source, why go through PCL at all?!? | 14:32.16 |
| henrys | right advocrb won't work unless the driver found a good substitute probably not worth worrying about unless they push back. | 14:32.23 |
| kens | henrys, with the way the PCL is contructed its never going to be possible to make a 'searchable' PDF. | 14:32.56 |
| | We maybe could find a way to embed teh TTF, that's actually something in the PCL interpreter where we search for glyph names. | 14:33.24 |
| | But basically, not going to be searchable. | 14:33.42 |
| henrys | chrisl:I don't know their workflow but one possible scenario is the archiving printer jobs some of which wouldn't have postscript. | 14:34.49 |
| chrisl | henrys: I'd assumed they were working with either a legacy, PCL workflow that "just worked that way", or already archived files that needed converting to a more viable format - they haven't shown much willingness/ability to modify the workflow previously..... | 14:36.45 |
| kens | She did say she'd tried different settings on the printer driver, which suggests they are producing the PCL. | 14:38.38 |
| henrys | that was my read. | 14:40.10 |
| | anyway probably not very important unless they push back. | 14:40.28 |
| kens | Fair enough | 14:40.39 |
| | I'll wait for a reply | 14:40.44 |
| henrys | Raed ...lord... | 14:46.32 |
| kens | :-) | 14:55.09 |
| | Trying my patience.... | 14:55.15 |
| mvrhel | kens: thanks for answering the icc question last night. i did not even see the post for some reason | 15:43.35 |
| | distracted by the clist | 15:43.45 |
| kens | NP mvrhel, in fact oy answered it first :-) | 15:43.49 |
| mvrhel | thanks oy | 15:44.00 |
| oy | np | 15:46.21 |
| henrys | be in and out today -- birthday. | 15:47.39 |
| kens | happy birthday henrys | 15:47.59 |
| henrys | I think it should be a company policy your not allowed to work a full day on birthdays. | 15:48.24 |
| kens | :-) | 15:48.30 |
| henrys | thanks | 15:48.33 |
| mvrhel | happy birthday henrys! | 15:55.39 |
| chrisl | henrys: many happy returns! | 15:57.13 |
| mvrhel | argh. looks like I still have to add a bunch of stuff to the pdf14 device for the planar sep stuff... | 16:09.26 |
| henrys | thanks guys | 16:30.37 |
| kens | OK heading off for the evening, night all | 16:45.57 |
| mvrhel | henrys: good news | 17:14.14 |
| | I have the planar sep stuff working through transparency now AND it fixes bug 692961 | 17:15.06 |
| | and 692618 | 17:15.46 |
| henrys | mvrhel:wow that is good news. | 17:20.45 |
| mvrhel | bbiaw | 19:10.10 |
| Robin_Watts | Home again! | 20:28.55 |
| mvrhel | welcome back Robin_Watts | 20:59.16 |
| Robin_Watts | I'm off to bed. Have been up for far too long. But it's good to be back home. | 21:03.25 |
| | Forward 1 day (to 2012/04/05)>>> | |
IRC Logs