| | <<<Back 1 day (to 2013/10/14) | 2013/10/15 |
| mvrhel_laptop | marosw: you there? | 00:27.27 |
| | marcosw | 00:27.33 |
| | bug 694707 is fixed now. but I did not know how you wanted to handle it. also it would be good to add that file to the regression testing | 00:28.12 |
| | the fix resulted in no changes in the cluster push | 00:28.30 |
| | it occurs only in an odd case with various isolated / non-isolated transparency groups | 00:28.54 |
| | now back to mupdf again | 00:29.12 |
| | henrys: so the meeting is at 7:30 PDT tomorrow? | 00:29.23 |
| | until 8:15 | 00:29.28 |
| henrys | mvrhel_laptop: yes | 00:29.51 |
| | did you read the logs about lcms? | 00:30.03 |
| mvrhel_laptop | henrys: yes. I made a comment above about it | 00:33.08 |
| henrys | then I should read the logs ;-) | 00:33.22 |
| mvrhel_laptop | :) | 00:33.59 |
| | done for the night I think. I need to get over this cold | 00:34.18 |
| kens | Robin_Watts: , paulgardiner, tor(n), can one of you reply to this please ? | 07:12.17 |
| | http://stackoverflow.com/questions/19372802/how-can-change-color-drawing-of-mupdf | 07:12.18 |
| kens | remembers Paul is away | 07:12.40 |
| sebras-work | kens: tor(n)..! you echo my thoughts. :) | 07:13.16 |
| kens | Hmmm. chrisl, what's our position re GPL when using a DLL ? Is that 'linking' ? | 07:15.24 |
| | ie does it invoke the viral nature of the GPL ? | 07:15.41 |
| chrisl | kens: I believe it does, yes. | 07:17.38 |
| kens | chrisl, its OK I followed the SO thread and it looks like its not relevant, sorry. | 07:17.59 |
| chrisl | NP | 07:18.31 |
| kens | Sybase PowerBuilder not only uses GS to create PDF files, it only works with 8.71 apparently.... | 07:19.00 |
| chrisl | Yeh, I think I knew that - IIRC, I found a topic on their forum to that effect a while back | 07:19.43 |
| kens | I actually commented on it at the time, but I'd forgotten about it | 07:20.03 |
| chrisl | But I thought they exec'ed the executable, rather than link to the DLL..... | 07:20.36 |
| kens | Yes, exactly. There was a new post with the same problem, but wttering about the DLL which had me chasing my tail for a moment | 07:21.14 |
| chrisl | It might be worth pinging Miles, although I'm sure he'll have made contact before | 07:22.21 |
| Micha` | tor7: Good morning! Say, is it you who introduced commit 3c559928 (Set /Parent entry when inserting a page into the page tree)? | 08:51.48 |
| sebras-work | Micha`: tor7 is indeed the committer. why are you asking..? | 08:57.01 |
| Micha` | Because I can't make it to work :-) It seems that it always creates cycles in the page tree. In fact, in pdf-page.c:573, shouldn't "pdf_dict_puts(page->me, "Parent", page_ref)" read "..., parent)" ? | 09:01.56 |
| | --- note it *does* work with this change, but it may not be the intended behavior. | 09:02.25 |
| sebras-work | Micha`: I'm reviewing tor7's patch and it looks alright to me. I thik page_ref is correct. he means to set a /Parent entry in the page dict which is added as far as I understand. | 09:16.38 |
| tor7 | Micha`: yes. let me take a look. | 09:17.06 |
| sebras-work | ah.. no. I take that back. | 09:17.18 |
| | page->me is the current page of course. | 09:17.25 |
| | yes, it probably should be parent. d'oh... :-P | 09:17.35 |
| tor7 | Micha`: this code is fairly untested, the code to use it hasn't really been exercised (or implemented in some cases) | 09:18.22 |
| | Micha`: does it work if you make the change in pdf_dict_puts to use parent instead of page_ref? it looks like it ought to. | 09:20.08 |
| Micha` | tor7: It does indeed. | 09:20.26 |
| tor7 | Micha`: the one thing this code doesn't do is create a nice well balanced page tree | 09:20.32 |
| | and it requires an existing page tree to work with | 09:20.47 |
| Robin_Watts | or in fact, any page tree if there isn't one to start with :) | 09:20.49 |
| Micha` | Yes, I'm looking forward to that :-) Creating a PDF from scratch would be great. | 09:21.07 |
| tor7 | so it can't create a page tree from scratch, it's only really useful for minor page removals or insertions as it stands | 09:21.13 |
| | it's on the todo list, but at a very low priority (since we don't have an immediate need for it ourselves) | 09:21.41 |
| Robin_Watts | tor7: Couple of things on robin/master when you get a mo. | 09:22.08 |
| tor7 | basically, it should be possible if you (a) handle the fz_throw TODO case of an empty page tree | 09:22.10 |
| | and then optimise it by doing a rebalancing function you can call at the end | 09:22.26 |
| Micha` | For the moment, I only plan to edit PDFs, hence I do not start from scratch, so I'm fine :) | 09:23.23 |
| tor7 | Micha`: pdfclean has a function to rebuild the page tree (but it makes one flat page tree, not good for performance) when you ask it to drop pages | 09:23.35 |
| Micha` | Robin_Watts: Did you see my comment about the empty contents? | 09:23.46 |
| tor7 | and I believe the pdfwrite device has some of its own page tree creation | 09:23.58 |
| Robin_Watts | Micha`: I did, but I haven't had a chance to investigate it. | 09:24.02 |
| tor7 | there's a few other things you need to create a valid PDF file from scratch, like the Catalog | 09:24.15 |
| Micha` | Robin_Watts: No problem. | 09:24.43 |
| | tor7: Ah, yes, I see... | 09:24.59 |
| tor7 | Micha`: the plan is to (eventually) migrate both of them to this new page tree editing API you've found | 09:25.27 |
| Micha` | I see. What is the current status of the (#if 0)'d code in pdf-write? | 09:27.46 |
| tor7 | Robin_Watts: what's the fix in draw-device.c with blendmode & FZ_BLEND_MODEMASK about? I don't remember having a bitmask for the blend mode... | 09:28.08 |
| Robin_Watts | tor7: For the gstate the blendmode has ISOLATED and KNOCKOUT bits. | 09:28.36 |
| tor7 | oh! | 09:28.48 |
| | right. | 09:28.50 |
| Robin_Watts | so that was a silly typo on my part. | 09:29.01 |
| tor7 | Robin_Watts: the four commits on robin/master LGTM | 09:29.38 |
| Robin_Watts | ta. | 09:29.44 |
| | Pushed. | 09:30.29 |
| | Micha`: Yesterdays fix is now in the golden repo. | 09:30.41 |
| tor7 | Robin_Watts: two small fixes on tor/master | 09:32.48 |
| Robin_Watts | both look fine. | 09:33.18 |
| tor7 | Robin_Watts: also: grrr. lazy ass delivery bastards. the package would have arrived yesterday if they hadn't been too lazy to get out of their delivery van to ring the doorbell. | 09:33.51 |
| Robin_Watts | what? They pulled up outside and honked? | 09:34.18 |
| | or they rang the mobile? | 09:34.38 |
| tor7 | in 90% of times they're supposed to deliver, they take a look and say, eh fuck it. mark it as "undeliverable, the person wasn't at home. couldn't reach." with no attempt at doing so. no phone call, no door bell, no nothing. | 09:34.57 |
| Robin_Watts | I've heard similar complaints from other people that live in cities. | 09:35.33 |
| tor7 | I got the paper slip with the swedish side tracking number and then at 13:42 -- tried to reach, couldn't. | 09:35.35 |
| | yeah. it's pretty much standard practice. load it up on the van for delivery, make the rounds to the easy to get to places, and then back home to the depot. | 09:35.58 |
| | annoying as hell though, if you live in the city... | 09:36.09 |
| | most people probably don't even know, since they go to work at an office.... | 09:36.24 |
| Robin_Watts | Living in a village I've never had a problem. Of course the fact that I'm home all day everyday means that they mostly know they can drop parcels here for anyone in the street who is out... | 09:36.42 |
| tor7 | yeah. I was surprised how fast the package arrived to you. | 09:37.37 |
| Robin_Watts | me too. Google Play said "usually dispatched within 2 days", then the receipt said "will be dispatched in 5 days time", then it arrived 2 days later. | 09:38.20 |
| Micha` | Robin_Watts: Thanks for the commit! But we may have missed something: "pdf_dict_puts(page->me, "Contents", obj);" should read "pdf...(..., page->contents);" right? | 09:53.32 |
| paulgardiner | kens: Thanks for spotting the question on stackoverflow. I've answered it. (Not quite off on vacation yet). | 09:53.54 |
| kens | Ah, thanks paulgardiner | 09:54.06 |
| Robin_Watts | paulgardiner: Have fun. | 09:54.17 |
| | Micha`: Urm... why? | 09:54.54 |
| paulgardiner | Off Thurs morning, so hopefully will be working most of today and some of tomorrow | 09:54.57 |
| Robin_Watts | Micha`: Damn. Yes. | 09:56.11 |
| Micha` | Robin_Watts: Ah! :-) | 09:56.20 |
| Robin_Watts | tor7: 2 more small fixes on robin/master then. | 09:57.30 |
| | Micha`: Thanks again. | 09:57.34 |
| Micha` | You're welcome. | 09:58.46 |
| paulgardiner | tor7: there are also some iOS commits on paulg/master | 10:00.05 |
| Robin_Watts | fts_17_1700.pdf has a JPX image in it that doesn't render properly in mupdf, but does in gs. | 11:03.14 |
| | One for shelly? | 11:03.21 |
| | gs whinges about it though. | 11:03.53 |
| kens | whinges how ? | 11:05.02 |
| | and in what way renders improperly ? | 11:05.12 |
| | need to go look atg wife's computer, brb | 11:05.36 |
| chrisl | Robin_Watts: IIRC, mupdf doesn't support SMaskInData (or whatever it's called), so it could be that. There are also some colour space heuristics (ahem, hacks!) in the gs interface code, so it could be that | 11:10.06 |
| | Robin_Watts: Indeed, at least one of the images in fts_17_1700.pdf has "/SMaskInData 1" | 11:13.51 |
| flojpg | hello world; i've a simple question for you all -> i've an application which provide text to GS using stdin. Is it possible to add a balise in the original text permiting to "inform" GS that it have to change the font (clearly, i want the same font but bold) | 12:21.22 |
| kens | Ghostscript doesn't consume text (at least not directly), it consumes PostScript or PDF> Whatever is driving GS must be supplying one of those (most likely PostScript). You can change the font in PostScript using the setfont or selectfont operators | 12:22.52 |
| flojpg | ok thanks for your help | 12:23.48 |
| | i'll try this | 12:23.52 |
| Robin_Watts | chrisl: ah, thanks. | 12:24.54 |
| Micha` | In fact, I don't see anything in the PDF spec directed to written annotations. Ink annotations seem to be used | 12:38.41 |
| | oops. | 12:38.45 |
| | Let me finish that. | 12:38.50 |
| | Ink annotations seem to be used for freehand circling or underlying, and then for typing a note. That's not the same as plainly hand writing a note, plus the Ink type is not really robust --- no color change can be made during a note, for instance. ezpdf has handwritten notes, on Android at least, and it relies on a Stamp annotation for which it defines an appearance. This I consider hacking the spec --- plus, cl | 12:45.33 |
| | icking the annotation opens an empty (typed) note, and this seems useless. So as I'm still planning on making a PDF annotator (with handwritten notes), am I right in thinking that the cleanest way would be to have one form XObject spanning the whole page containing the scribbles, possibly depending on an OCG? | 12:45.33 |
| | Boy, rcirc could do a better job at splitting messages... | 12:46.00 |
| Robin_Watts | paulgardiner is the expert on annotations. | 12:50.44 |
| | I thought there were text annotations too? | 12:51.11 |
| | oh, but you want handwritten? | 12:51.17 |
| Micha` | Precisely. | 12:53.02 |
| Robin_Watts | I think for handwritten, when you want to leave the possibility for other people to edit it later, you need ink. | 12:54.11 |
| Micha` | I have a tablet with a pen, and I feel that no software handles scribbling on the PDF smoothly enough (I currently use an excellent software called LectureNotes, but it requires the PDF to be rasterized, which is no good for PDF books). | 12:54.33 |
| Robin_Watts | For handwritten when you want a fixed appearance that will never change, stamp will do the job. | 12:54.35 |
| Micha` | With ink annotations, every time the user changes transparency, color, or thickness, a new annotation should be created. Plus, I don't feel it is the intended purpose of Ink annotations. | 12:56.08 |
| | Also, Stamps do not seem to be intended for this. Can a viewer discard the /AP and redo the rendering based on the annotation type? | 12:57.36 |
| kens | Acrobat (almost) always does so | 12:58.44 |
| | Which I think is a really, really bad idea | 12:58.56 |
| paulgardiner | kens: Really?! That does souns a bad idea. | 12:59.25 |
| | kens: is that for annotations in general, or just certain ones? | 13:00.17 |
| kens | paulgardiner : Acrobat *defintely* does this, we have a number of cases where we ahve a 'bug' because our annotations do not match what Acrobat displays. Yet we render teh appearance stream faithfully. It cna be shown (by extracting the appearance stream) that GS is drawing the AP the same as Acrobat, so clearly Acrobat is ignoting the AP stream. | 13:00.59 |
| Micha` | Well... As far as I can see in the specs, it is not prohibited to do so. | 13:01.03 |
| kens | Micha` : Yes, but if I am a content creator, and I go to the effort of creating an AP stream so it looks the way I intend, I would probably be p*ssed off if the viewer decided it knew better and drew something 'like' what I intended. | 13:01.50 |
| Robin_Watts | tor7: Another fix (making 3) on robin/master | 13:02.15 |
| kens | paulgardiner : Acrobat ignores AP streams 'most' of the time, there seems no rhyme or reason. CHris and I suspect that the annotation renmdering was done by different people, and sometimes they decided they knew best and just rendered the content, and sometimes they decided to honour the creator's decision | 13:03.12 |
| Robin_Watts | chrisl: Turns out that SMaskInData doesn't matter for that file. It was an openjpeg 1 vs 2 thing. | 13:04.14 |
| | Possibly we should be adopting openjpeg 2 now? | 13:04.24 |
| Micha` | kens: And you'd be right to be pissed. But if it is specs-compliant, the problem may lie more in the specs. | 13:05.01 |
| paulgardiner | I'm sure I've seen many places in the spec where it explicitly states that the AP takes precedence if present | 13:05.36 |
| kens | Micha` : I don't say its not spec compliant (and the PDF spec is very poor), I'm just saying that in my opinion its a very bad idea | 13:05.42 |
| Micha` | Agreed. | 13:05.52 |
| kens | FWIW one of the reasons Marcos had trouble with a (huge) PDF file recently was that the bug was a missing AP stream, and whenever Marcos edited teh PDF file and saved it, Acrobat quietly added an AP stream for him. | 13:06.49 |
| | paulgardiner : an 'easy' way to test is to create a PDF file with one of every annotation type, then nobble the AP streams so they all point to the sma stream, eg a black box, and see what the viewer makes of it. | 13:07.46 |
| paulgardiner | Micha`: I haven't yet fully understood why an Ink annotation (or collection of several) is wrong for your application. | 13:08.14 |
| Micha` | Table 164, on the AP line, specifies: "Individual annotation handlers may ignore this entry and provide their own appearances." | 13:08.16 |
| paulgardiner | kens: I had noticed that Acrobat ignored the AP for a signature annotation when information from the signature was missing, but then displayed it when the rest of the information was in place. I guess that's one case that could be deemed sensible. | 13:10.19 |
| kens | paulgardiner : yes, possibly, but I've seen it ignore perfectly valid annotations with AP streams too | 13:10.50 |
| paulgardiner | Micha`: Oh yes. Clearly the spec allows it. Perhaps it does make sense for some types of annotations (e.g., text annotations), where you might want your app to use a consistant icon to show where one might open up a hidden note. | 13:17.16 |
| Micha` | paulgardiner: It is not wrong per se, but there are three reasons why I'm not sure it is the optimal choice. First, an annotation, AFAIU, is foremost an access to a typed note. My use do not fit this intention as I do not want typed notes; obviously I could just disregard that, but I'd rather conform to the spirit of the specs. Second, when I take notes on a paper, I have half a dozen different pens, hence I will | 13:17.21 |
| | have at least that many Ink annotations. Third, and a consequence of Second, when erasing, I will have to go through all the Ink annotations to find the points to erase. This may overload the process (though I'm not sure). If I go for an OCG'd form XObject, I will have to consider only one object at a time. | 13:17.21 |
| paulgardiner | Yes. Might be best. And you more easily guarantee getting the same results in other viewers. | 13:19.32 |
| Micha` | paulgardiner: Thanks a lot for the advice. Your hindsight is very much welcome as I did not have a clue what an OCG was a few hours ago :) | 13:27.46 |
| paulgardiner | Micha`: No problem. Glad we could help. | 13:28.57 |
| Robin_Watts | So, when did we decide the meeting time was today? :( | 14:08.07 |
| | oops. :) instead of :( | 14:08.12 |
| kens | AIUI 4:30 pm uk time, one meeting | 14:09.11 |
| Robin_Watts | Running through the fts cases for the svg device has been interesting. I've found a few things that mupdf gets wrong. | 14:14.53 |
| | tiling patterns being one of them. I hate it whenever I have to make changes in this stuff. | 14:15.39 |
| kens | patterns are horrible | 14:16.21 |
| paulgardiner | Wasn't it 7:30 to 8:15 EST | 14:21.33 |
| kens | Err, is that 3:30 UK time then ? | 14:22.54 |
| paulgardiner | Yeah. I may be misremembering though | 14:23.13 |
| henrys | yes 5 minutes | 14:24.25 |
| kens | ah thanks henrys | 14:24.33 |
| henrys | PST paulgardiner | 14:26.26 |
| paulgardiner | Ah. That would explain the trouble I was having making it come to 3:30 | 14:27.15 |
| henrys | I just added research MS Office solutions to the agenda. | 14:29.39 |
| kens | henrys on the 'GS->Languages' item, I have added teh ramfs code, and closed #693363 | 14:30.33 |
| paulgardiner | henrys: I've been mainly continuing work on the iOS app this week, but I have started looking at libreoffice this afternoon. | 14:31.23 |
| henrys | At Chicago Print there has been a booth next to us with guys doing PDF -> Word and other formats. I would think that would be more popular than it is. | 14:31.27 |
| | kens:super | 14:31.42 |
| | kens:but I must have missed the commit message somehow - I do try and keep up with everything. | 14:32.23 |
| chrisl | henrys: and I'm done with 694519 | 14:32.23 |
| kens | henrys let me look for the commits | 14:32.38 |
| paulgardiner | On the iOS front I have form filling working but without javascript of course | 14:33.10 |
| henrys | chrisl: that I did see, I've marked the 2 done on the agenda | 14:34.03 |
| kens | ramfs b5472ea6bf6925023febdeab12be9dbd83e811f1 d97571b56d7c740e7d6aeee064313b96048a5667 | 14:34.07 |
| | 29ed18f26f78d3e737b5e73452b1aa1a90088144 | 14:34.08 |
| chrisl | henrys: thanks | 14:34.20 |
| mvrhel_laptop | kens: did you see that I fixed the xps trans issue you found. that was an interesting one | 14:34.26 |
| paulgardiner | And I've just realised that checkboxes probably now work, but I haven't tested them :-) | 14:34.29 |
| henrys | chrisl: my suggested solution to yesterday's bug was sent as a patch to the 9-1 customer did you see it? | 14:34.34 |
| kens | mvrhel_laptop : yes I saw you had fixed it, thanks for that! | 14:34.39 |
| chrisl | henrys: I saw the mail, I didn't look at the patch - I'll look now | 14:34.55 |
| kens | Bug 693363 was commit 9c13e3b9e735ba119f58c751a51fc55efef15a0c | 14:35.03 |
| henrys | chrisl: I didn't test gs ;-) | 14:35.14 |
| | chrisl: but what could possibly go wrong ? | 14:35.28 |
| chrisl | henrys: it really shouldn't affect gs | 14:35.37 |
| kens | henrys probably want to remove the RAM I/O device from 'someday projects' too | 14:36.33 |
| mvrhel_laptop | marcosw: did you see my comment about 694707? | 14:37.00 |
| henrys | kens:yes | 14:37.02 |
| chrisl | henrys: did you actually check if using 64 bit color indices carried a performance penalty? I'd be a little surprised if that was still the case | 14:37.13 |
| | henrys: the patch looks okay - assuming it tests out with GS, of course :-) | 14:38.16 |
| henrys | marcosw:how do you feel about me taking Mac Pro off a bit - I'm thinking of using windows on it. 801 is going to have more questions and they report probably on both. | 14:38.29 |
| | chrisl: last I check there was significant penalty yes. 10 to 15 % if I remember correctly. | 14:39.08 |
| | on certain files only. | 14:39.24 |
| Robin_Watts | chrisl: I cannot think of a platform on which 64bit wouldn't be a cost. | 14:39.44 |
| chrisl | Robin_Watts: I'd have thought platforms with native 64 bit support would be fine | 14:40.48 |
| Robin_Watts | chrisl: The cost will be lower there, sure, but there is still more overhead in loading/saving to memory. | 14:41.20 |
| henrys | Robin_Watts, chrisl as you guys can see from the include file we've tried quite a few experiments with color indices. | 14:41.23 |
| | chrisl: I do wonder if there is some optimizations we could do that would make the overhead insignificant | 14:43.43 |
| | paulgardiner: how is iOS? | 14:44.03 |
| chrisl | henrys: it may be that we're copying structure contents around, when passing a pointer would be more efficient. | 14:44.28 |
| paulgardiner | henrys: Have reflow and form filling working. Still have javascript integration, signature support and printing to add. | 14:45.07 |
| | Sorry and annotations | 14:45.29 |
| henrys | paulgardiner: wow moving right along. It can't be as painful as we thought | 14:46.01 |
| paulgardiner | although there's a fair crossover between annotations and form filling (because of partial updates) that's now done | 14:46.16 |
| henrys | Robin_Watts: I don't know if your read my message to 801 but you might be a good candidate for that project if they say yes. I guess ray could do it also. | 14:47.12 |
| Robin_Watts | I hadn't spotted anything. Let me check again now. | 14:47.38 |
| henrys | tor7:how's GL? | 14:47.59 |
| | mvrhel_laptop: finally back to mupdf? | 14:48.37 |
| Robin_Watts | henrys: The device with different resolutions per plane. Scary. | 14:48.54 |
| mvrhel_laptop | henrys: I am hoping to. kens dropped an ICC question on me that I will look at real quick and then I will fix my threading issue in the windows app | 14:49.30 |
| kens | 2 ICC questions :-) | 14:49.38 |
| mvrhel_laptop | had a nice discussion with Robin_Watts last week about my issues | 14:49.40 |
| Robin_Watts | for some definition of nice. | 14:50.08 |
| mvrhel_laptop | kens: oh yes 2 questions ;) | 14:50.09 |
| | I will look at those this morning | 14:50.16 |
| kens | THanks :-) | 14:50.20 |
| henrys | mvrhel_laptop: well I'm glad you've discussed your issues with somebody ;-) | 14:50.38 |
| mvrhel_laptop | ha | 14:50.49 |
| paulgardiner | henrys: yeah. I like the structure that Tor created, now I understand it better, and the new stuff is fitting in quite naturally. | 14:51.18 |
| henrys | paulgardiner: oh good where is the mighty tor7? | 14:51.55 |
| | any other meeting business? | 14:53.16 |
| paulgardiner | I don't know. He was here earlier... slightly worrying. | 14:53.16 |
| kens | I don't have anything else today | 14:53.35 |
| henrys | I guess marcosw and ray forgot about the new meeting time and will show up at the hour. | 14:54.02 |
| kens | Possibly tor7 as well | 14:54.18 |
| paulgardiner | I have some worries about libreoffice, but I need to get a better understanding of it before I'll no if they are legitimate worries. | 14:54.45 |
| | s/no/know/ | 14:54.56 |
| henrys | libreoffice is C++? | 14:55.18 |
| paulgardiner | yes. | 14:55.40 |
| Robin_Watts | In case anyone has missed the lcms2 discussions, it seems we have a way forward that Marti is happy with. If anyone wants to chime in, feel free to read the discussion in the logs. | 14:55.57 |
| paulgardiner | The oox part is fairly small, but the whole thing is huge | 14:56.01 |
| Robin_Watts | libreoffice is C++ and MPL, so that sounds pretty good - if we can extract just the bits we need. | 14:56.15 |
| henrys | hmm LGPL? | 14:56.19 |
| paulgardiner | I have yet to work out how selfcontained the oox part is | 14:56.28 |
| Robin_Watts | It's dual MPL and GNU GPLv3. | 14:56.34 |
| henrys | Robin_Watts: ah right | 14:56.41 |
| kens | Robin_Watts : I read the discussion, but there's nothing I cna usefully say | 14:56.58 |
| mvrhel_laptop | kens. so where is 247-05.ps? | 14:57.00 |
| paulgardiner | Most of what I've looked at so far is MPL | 14:57.01 |
| | but I haven't sussed whether it pulls in any LGPL stuff. | 14:57.16 |
| kens | mvrhel_laptop : ther original file ? Its in tests_private soemwhere | 14:57.16 |
| | Its one of the QL test files | 14:57.25 |
| mvrhel_laptop | I can't seem to find it | 14:57.28 |
| ray_laptop | good guess, henrys | 14:57.29 |
| kens | give me a second | 14:57.29 |
| | Actually I htink that should be 247-05.ps | 14:57.55 |
| | Indeed it shold be | 14:58.05 |
| paulgardiner | The whole oox directory looks to be MPL | 14:58.15 |
| Robin_Watts | paulgardiner: I thought the whole thing was both MPL and GNU GPLv3. I didn't think that there were different components in different licenses, but maybe I misunderstood. | 14:58.33 |
| kens | mvrhel_laptop : /home/marcos/cluster/test_private/comparefiles/247-05.ps | 14:59.00 |
| mvrhel_laptop | oh compare files | 14:59.05 |
| | ok | 14:59.07 |
| | sorry | 14:59.12 |
| kens | NP | 14:59.15 |
| paulgardiner | Yeah. I was just going to add the proviso "If I'm understanding how the licencing works" | 14:59.27 |
| kens | And ineed there is a 245-07 in there | 14:59.40 |
| henrys | chrisl: do do you want me to take care of the patch? | 14:59.52 |
| chrisl | henrys: if you don't mind, yeh. | 15:00.32 |
| henrys | chrisl: will do. | 15:00.44 |
| chrisl | Thanks | 15:01.16 |
| paulgardiner | Robin_Watts: many of the files mention only MPL. I don't know whether they are infected with LGPL by being collected with files that mention LGPL | 15:01.32 |
| henrys | I do wish we had windows testing. Compiling with different color index values would have revealed a crash in pcl immediately. | 15:01.51 |
| paulgardiner | Clearly if you build something from a collection of MPL and LGPL files then it's LGPL, but I don't know what happens if you pull out just MPL files and use only those. | 15:02.32 |
| mvrhel_laptop | kens: ok so 245-07.ps | 15:02.44 |
| kens | yep | 15:02.48 |
| mvrhel_laptop | got that one | 15:02.54 |
| kens | OK I htink I sent you a cut down file for the other problem | 15:03.07 |
| chrisl | henrys: would it have shown on Unix, too? Maybe we should have 32bit color indices in the weekly tests? | 15:03.15 |
| paulgardiner | I cannot at this stage tell if the oox part will build without pulling in all the huge number of libraries that make up libreoffice/core | 15:03.16 |
| ray_laptop | henrys: windows also uses 64-bit color_index | 15:03.17 |
| mvrhel_laptop | kens: yes. thank you | 15:03.34 |
| kens | NP | 15:03.38 |
| henrys | ray_laptop: due to a bug in pcl part of the code would be 32 and part 64 if built with 64, that easily preventable stuff with good testing. | 15:04.40 |
| kens | mvrhel_laptop : I forgot a point, for the second ICC question, you need to use -sDEVICE=pdfwrite -dPDFUseOldCMS=false | 15:06.59 |
| mvrhel_laptop | ah ok | 15:07.05 |
| | thanks | 15:07.08 |
| ray_laptop | henrys: right, but we can build with 32-bit color index on unix no or windows, tight ? | 15:07.08 |
| mvrhel_laptop | I have to head out right now. I will be back in about 30 minutes | 15:07.40 |
| henrys | chrisl: we have eliminated recursive make of the library makefile in gcc, I wish we could do that in msvc, it is much simpler. | 15:09.04 |
| | chrisl: but indeed it should be tested. | 15:09.13 |
| sebras-hotel | paulgardiner: wouldn't that MPL file still be MPL? I mean that was the original license. the fact that MPL happens to be compatible with LGPL doesn't change the license of the file per se..? | 15:09.28 |
| | paulgardiner: otherwise BSD-people would complain even more about GPL... :) | 15:09.46 |
| Robin_Watts | sebras-hotel: I think the worry is that the MPL stuff might build upon GPL stuff. | 15:09.59 |
| | so we'd need to reimplement the GPL layers in order to use it. | 15:10.14 |
| | http://www.kickstarter.com/projects/117421627/the-peachy-printer-the-first-100-3d-printer-and-sc | 15:11.00 |
| paulgardiner | Both issues were worries of mine, although your interpretation sebras-hotel was the one that seemed most likley to me | 15:11.14 |
| Robin_Watts | Interesting. A 3d printer for $100. | 15:11.15 |
| henrys | ray_laptop: we can build with 32 or 64 on windows and unix. | 15:11.26 |
| chrisl | henrys: there are recursive make calls in ugcc_top.mak - but they are fairly sane ones, unlike the msvc ones | 15:11.36 |
| sebras-hotel | Robin_Watts: ah, to make a commercial license viable? (I seem to recall that MPL would allow this, just like BSD) | 15:11.46 |
| tor7 | henrys: oh, meeting's earlier rather than later? | 15:11.57 |
| henrys | ray_laptop: have a look at what I just emailed 801 - it might effect you anyway, so worth the read. | 15:12.04 |
| tor7 | I ran out to pick up the chromebook so I'd be ready for the meeting... oops. | 15:12.16 |
| henrys | tor7:new meeting time is 7:30 PST | 15:12.28 |
| Robin_Watts | sebras-hotel: Indeed. Without a commercial license we wouldn't be interested. | 15:12.35 |
| tor7 | henrys: have you switched from DST yet? | 15:12.52 |
| | henrys: GL has clipping, going to take a break from that and see if we can render in CMYK | 15:13.02 |
| sebras-hotel | Robin_Watts: no of course not, and GPLv3 written by someone else and not dual licensed under BSD or similar would make it a problem. | 15:13.10 |
| Robin_Watts | henrys: That device sounds interesting. I'd be happy to have a look if you wanted me to. but then if ray particularly wanted to do it, I wouldn't fight for it :) | 15:13.15 |
| ray_laptop | henrys: OK. | 15:13.46 |
| henrys | Robin_Watts: what they have now is going to be very slow - I mean copying all that data… lord | 15:14.24 |
| chrisl | Are the two resolutions guaranteed to be easy integer multiples? | 15:15.32 |
| henrys | we've had experiences where customers have released products we didn't want to be associated with I'd like to avoid that. | 15:15.49 |
| Robin_Watts | chrisl: I would assume a fixed 2:1 ratio. | 15:16.08 |
| henrys | chrisl: yes it looks to be strictly 300 and 600 | 15:16.11 |
| Robin_Watts | henrys: Presumably this is a planar device ? | 15:16.24 |
| ray_laptop | henrys: right, it's better to render things directly. | 15:16.32 |
| Robin_Watts | Do we have any history of having devices with different resolutions? Cos I bet that will break all sorts of assumptions in clist etc. | 15:17.07 |
| ray_laptop | henrys: but I'm not sure about a render device that has different res per plane (all but black at half res) | 15:17.36 |
| chrisl | Postscript has no provision for that, so I doubt there's history | 15:17.59 |
| ray_laptop | Robin_Watts: the clist would need to be at 600 dpi, then the buffer device (special memory device) would convert the coordinates | 15:18.25 |
| henrys | Robin_Watts: I thought we could just do copy_color, fill_rectangle and the low level stuff and skip pixels why change the res? | 15:18.37 |
| Robin_Watts | henrys: That will play hell with halftoning etc. | 15:18.57 |
| ray_laptop | the clist needs to maintain a single res. | 15:19.01 |
| | Robin_Watts: they are contone | 15:19.09 |
| henrys | Robin_Watts: there is no halftoning | 15:19.21 |
| | full color | 15:19.26 |
| Robin_Watts | OK, so patterns. | 15:19.29 |
| | We just had a bug where a pattern had alternate lines empty. | 15:19.35 |
| chrisl | IIRC, someone like Scitext (kens do you remember?) did something like that - 600dpi for line art, and 300 dpi for contone | 15:19.43 |
| ray_laptop | Robin_Watts: patterns and all bitmaps in the clist would be at 600 | 15:19.52 |
| Robin_Watts | and because at certain resolutions we picked the empty lines, the pattern would disappear at certain resolutions. | 15:20.03 |
| ray_laptop | Robin_Watts: patterns are inherently resolution independent (at least in PDF), | 15:20.48 |
| kens | chrisl it was Dwight I think, but the output format was Scitex, CT/LW | 15:20.58 |
| | ray_laptop : not whenyou render them | 15:21.13 |
| ray_laptop | in PS you can write stuff that uses tricks to make stuff resolution dependent | 15:21.19 |
| Robin_Watts | ray_laptop: Tell that to the bug we were just looking at! | 15:21.20 |
| ray_laptop | kens: no, I meant the definition of the patten in the PDF is not aware of the device re. | 15:21.38 |
| kens | ray_laptop : correct | 15:21.45 |
| henrys | Robin_Watts: well it would be no different than what they have now. | 15:21.50 |
| kens | But when you redner the pattern, the resolutiopn becomes important | 15:21.57 |
| Robin_Watts | henrys: Well, at the moment they are downsampling, right? So taking an average? | 15:22.08 |
| henrys | which I assume they are satisfied with but that may be a badd assumption | 15:22.13 |
| ray_laptop | Robin_Watts: there's lots of cases where images, using the "center of pixel" rule cause dropout | 15:22.18 |
| Robin_Watts | Are you proposing we do that too? | 15:22.30 |
| henrys | Robin_Watts: they are not they are skipping | 15:22.30 |
| Robin_Watts | oh, ok. | 15:22.36 |
| | What happens when we do 'getbits' ? | 15:22.54 |
| | We'd have to pixel double up again. | 15:23.02 |
| ray_laptop | seems like a 'darkest of the source pixels' would be better | 15:23.15 |
| chrisl | kens: was Dwight's the only RIP that supported the Scitex device, then? | 15:23.44 |
| kens | chrisl the only Jaws one I remember | 15:23.55 |
| ray_laptop | Robin_Watts: presumably they would request the planes, and the color planes would be at the lower res | 15:24.30 |
| Robin_Watts | ray_laptop: How would they request the planes? using getbits? | 15:24.48 |
| | No mechanism in getbits to signal that planes are at different res. | 15:25.01 |
| henrys | Robin_Watts: correct they've added that to our code already so easy enough to use what they have. | 15:25.40 |
| ray_laptop | henrys: I haven't looked at that bit of hackery, do they convert to chunky pixels or separate planes (or line interleave) | 15:25.44 |
| Robin_Watts | henrys: They've added what to our code already? | 15:26.07 |
| henrys | ray_laptop: all chunky | 15:26.08 |
| | Robin_Watts: and indicator at the beginning of each buffer what resolution it is. | 15:26.27 |
| Robin_Watts | At the moment I would imagine that they 'getbits' chunky pixels, and then downscale certain planes. | 15:26.41 |
| | or maybe 'getbits' planar planes, and downscale. | 15:27.02 |
| | They won't be changing our internal represenations at all so far, right ? | 15:27.17 |
| henrys | Robin_Watts: actually what they do is a bit different from what I said - they know the black data is 600 and the rest is 300 - they pickle in the width of each line when the copy not sure why that is necessary. Probably easiest for you guys to read the code it is fairly straightforward, hell I understand it ;-) | 15:29.53 |
| Robin_Watts | henrys: Where can I get a copy of the code? | 15:30.16 |
| | I suspect that everything they currently do is 'post-getbits'. | 15:30.28 |
| | Which is an infinitely sensible place for it, IMHO. | 15:30.38 |
| ray_laptop | henrys: since you were doing it, I just haven't bothered (working on cust 532 issues) | 15:30.39 |
| | Robin_Watts: yes, except they are rendering at 600 and processing every pixel -- which isn't great for performance | 15:31.24 |
| Robin_Watts | The only way you'd get significant benefits to doing stuff *pre* getbits, is if you could arrange for the original copy_mono/copy_color etc calls to be at the lower res. | 15:31.25 |
| ray_laptop | Robin_Watts: but I agree that it's *nicer* | 15:31.35 |
| Robin_Watts | Otherwise you're having to downscale on every device call. | 15:31.43 |
| henrys | marcosw posted the ftp location somewhere I'll look. | 15:32.03 |
| ray_laptop | Robin_Watts: well, copy mono for black wouldn't have to do anything | 15:32.11 |
| Robin_Watts | ray_laptop: No, I disagree. I think that it's going to far faster to process everything at 600dpi then downscale just once at the end. | 15:32.14 |
| ray_laptop | and black text is the common case | 15:32.31 |
| | I'm sure that's why they have black at higher res -- for text (particularly small CJK fonts) | 15:33.07 |
| Robin_Watts | ray_laptop: So when their device gets called with a 600dpi bitmap to 'copy_mono' they need to downscale that at that point. | 15:33.09 |
| | That is hardly doing nothing. | 15:33.13 |
| ray_laptop | Robin_Watts: but for black they don't downscale | 15:33.33 |
| Robin_Watts | Consider a page with a signficant amount of overpainting. | 15:33.34 |
| henrys | the color is downscaled not black | 15:33.45 |
| Robin_Watts | ray_laptop: OK, so not for black, for one of the color planes. | 15:33.49 |
| | If there is a lot of overpainting, then you'll downscale every color component value for every paint of that pixel. | 15:35.05 |
| | Whereas if you just do the dumb thing and downscale at the end, you only touch each pixel once. | 15:35.24 |
| | Wholesale is cheaper than retail. | 15:35.29 |
| ray_laptop | Robin_Watts: right -- if the color planes need to be erased (because they aren't white) we'd need to get the downscaled mask | 15:35.29 |
| henrys | support email search for "ftp" July 17 2013 Robin_Watts and ray_laptop ... | 15:35.42 |
| Robin_Watts | This is why the downscaler for tiffscaled etc works post getbits. | 15:36.02 |
| henrys | they actually went through the trouble off sse'ing the copied data, so I assume performance is an issue. | 15:36.17 |
| ray_laptop | Robin_Watts: I agree that doing the buffers at the end is simpler, and easier to tackle with SSE code | 15:36.59 |
| henrys | however the memory savings would be quite significant if there are few bands or full frame if could allocate 300 dpi space for 4 planes and 600 for 1. There's is a 5 color device. | 15:39.16 |
| ray_laptop | henrys: I see one that my email thinks is 7/18 with M.S. saying he uploaded their project to the FTP site | 15:39.20 |
| | henrys: I don't think they are memory constrained | 15:39.42 |
| henrys | ray_laptop: probably not. | 15:40.09 |
| Robin_Watts | henrys: Yes, we would save memory by holding those bands at lower res. But I fear we would lose speed. | 15:40.33 |
| ray_laptop | henrys: and didn't you say that they need shorts ? is their color model 16 bits per pixel or 8 ? | 15:40.35 |
| Robin_Watts | yeah, why 16bits per component ? | 15:40.47 |
| | ray_laptop: component, not pixel, AIUI. | 15:41.01 |
| henrys | Robin_Watts: I was surprised about that as well and hence brought it out in the email for clarity | 15:41.18 |
| | is there something about SSE that would make shorts preferable? | 15:42.05 |
| ray_laptop | Robin_Watts: I admit that downsampling a copy mono every time we paint a glyph would be slow IF we need to which is for copy mono with a color that is not black or, when the color is black and the color planes are not white | 15:42.40 |
| | henrys: is the black plane 16 bits as well ? | 15:43.20 |
| Robin_Watts | henrys: Which zipfile from the ftp site? | 15:43.21 |
| | xxxx_project.zip or xxxx_project_0822.zip ? | 15:43.36 |
| henrys | chrisl: you said another customer was doing this. Was it planar rendering. | 15:43.42 |
| | Robin_Watts: either one has a few bug fixes for running on linux which you won't use. | 15:44.22 |
| Robin_Watts | I'll take the latter one then - newer, and 1/3 of the size. | 15:44.44 |
| henrys | Robin_Watts: use the latest one. | 15:44.48 |
| Robin_Watts | thanks. | 15:44.57 |
| chrisl | henrys: not our customer, an old Jaws OEM. | 15:45.17 |
| henrys | and if you use pcl you need the fix I just emailed him - gs should be okay | 15:45.21 |
| | chrisl: do you know if they were doing planar rendering? | 15:45.38 |
| chrisl | They would have been doing serial separations, I believe. Each separation produced by rerunning the display list | 15:46.16 |
| henrys | ray_laptop, Robin_Watts It does seem if we went to a planar rendering model we could do different CTM's just a matter of coding ;-) | 15:46.30 |
| Robin_Watts | chrisl: Is the jaws displaylist resolution dependent ? | 15:47.00 |
| ray_laptop | henrys: the problem is with bitmaps (images or glyphs) | 15:47.32 |
| Robin_Watts | henrys: If we went to a planar rendering model, and wanted to hold different planes at different res, I think you'll give the clist a stroke :) | 15:47.42 |
| henrys | Robin_Watts: yeah you are right. | 15:48.05 |
| chrisl | Robin_Watts: largely so, but not completely. For the few cases it wasn't it was good enough to create the display list at high res, and do "stuff" to get it to lower res | 15:48.06 |
| ray_laptop | to have resolution independent display list, text has to be paths, and without glyph caching of the bitmap that would SUCK with performance | 15:48.55 |
| chrisl | ray_laptop: the glyphs were resolution dependent, but were generally in black, and therefore at the higher resolution | 15:49.33 |
| Robin_Watts | ray_laptop: That's not true. | 15:49.55 |
| | MuPDF has a resolution independent display list. | 15:50.08 |
| ray_laptop | I suppose you *could* have text as paths, and then have the glyph cache in the playback, and render to both resolutions | 15:50.15 |
| chrisl | ray_laptop: note this was slightly different, as the differentiation was contone vs line art, not based on separations | 15:50.23 |
| Robin_Watts | It's just a different set of choices that you carry through. | 15:50.25 |
| ray_laptop | Robin_Watts: mupdf has text as high level, right ? | 15:50.31 |
| Robin_Watts | ray_laptop: Right. | 15:50.37 |
| | The problems that clist has with this instance are a consequence of the design decisions that were made right at the start of designing clist. | 15:51.03 |
| ray_laptop | so as I said, the glyph cache is performed in the reader when it knows the res | 15:51.09 |
| Robin_Watts | And they were probably made for good reason. | 15:51.19 |
| mvrhel_laptop | is marcosw around | 15:51.40 |
| ray_laptop | storing glyphs as path in the clist would be resolution independent. We'd just have to add caching | 15:51.53 |
| Robin_Watts | ray_laptop: 'just'. | 15:52.10 |
| henrys | mvrhel_laptop: I've been looking for him too. | 15:52.10 |
| mvrhel_laptop | ok | 15:52.14 |
| | maybe at 9 | 15:52.24 |
| ray_laptop | Robin_Watts: simpler than putting all of the font logic post clist. | 15:52.50 |
| Robin_Watts | ray_laptop: I don't have a clear enough view to have a strong opinion on how it works out with the wacky clist bitmap cache management. | 15:53.58 |
| mvrhel_laptop | kens: for the first questions do I need to run any special command options? | 15:53.59 |
| ray_laptop | except for text, the clist is resolution independent (at least when we don't do "default" image processing to lots of rect fills) | 15:54.09 |
| henrys | for this particular problem why couldn't we just render fonts at 600 dpi and put them in the clist? | 15:54.16 |
| mvrhel_laptop | or just render even to a raster device | 15:54.18 |
| kens | mvrhel_laptop : yes you will still need the -dPDFUseOldCMS | 15:54.22 |
| Robin_Watts | For mupdf, it's a lot cleaner to have the font logic post clist. | 15:54.27 |
| kens | but the question really is 'am I doing something dumb' ? | 15:54.34 |
| ray_laptop | Robin_Watts: I strongly agree that the clist tile cache is wacko | 15:54.37 |
| | Robin_Watts: cleaning that up is on the enhancement list | 15:54.55 |
| kens | mvrhel_laptop : you can see the colour space has no icc_equivalent without going near pdfwrite | 15:55.01 |
| mvrhel_laptop | where can I catch it like this? | 15:55.23 |
| | kens ^^ | 15:55.31 |
| kens | mvrhel_laptop : Hmmm..... | 15:55.35 |
| | In zimage1 I think | 15:55.43 |
| | Or possibly zimge1_setup | 15:55.52 |
| ray_laptop | henrys: we could render fonts at 600 (and do). the problem is when painting the glyph that is not black, or when we need to erase bits that are painted black on color planes | 15:55.59 |
| kens | Let me get a debugger up | 15:56.01 |
| Robin_Watts | Their device looks to be doing the funky color encoding chicken dance. | 15:56.17 |
| ray_laptop | henrys: the common case of black text on white would be fine. | 15:56.38 |
| Robin_Watts | I bet planar operation would help immensely. | 15:56.40 |
| kens | mvrhel_laptop : If you break in image1_setup you can see it | 15:57.02 |
| ray_laptop | Robin_Watts: they are switching to 9.10, so hopefully will not be using the compressed color encoding | 15:57.14 |
| kens | break on line 209 in zimage.c | 15:57.17 |
| | just after: | 15:57.35 |
| | gs_color_space *csp = gs_currentcolorspace(igs); | 15:57.35 |
| ray_laptop | Robin_Watts: yes, and avoid the whole compressed encoding problem | 15:57.48 |
| kens | you will see that csp->icc_equivalent is NULL | 15:57.53 |
| henrys | Robin_Watts: the action starts in clist_render_thread() in the code you've downloaded. | 15:58.44 |
| ray_laptop | henrys: so they are currently rendering to 8-bit (40 bit depth), then just moving the 8 bits to shorts for some reason, right? | 15:58.55 |
| Robin_Watts | henrys: Oh, god, so they've fiddled with the internals of gs? | 15:59.08 |
| henrys | Robin_Watts: yes which I want to also get us free of. We need a maintainable solution not some patchwork | 15:59.48 |
| ray_laptop | typical of "do it yourself" customers | 15:59.49 |
| Robin_Watts | I was just reading gdevxxxx.c and gdevxxxxgraph.c | 16:00.00 |
| mvrhel_laptop | ok the issue is that it has not really tried to paint with that space yet | 16:00.09 |
| | I suspect | 16:00.11 |
| kens | mvrhel_laptop : No it won't have,m its just an image | 16:00.25 |
| | So we draw the image in that space | 16:00.31 |
| mvrhel_laptop | once we start drawing it does the creation I think | 16:00.49 |
| | and yes | 16:01.01 |
| henrys | Robin_Watts: I think it easier to understand if you read the mods to gxclthrd.c but whatever works. | 16:01.06 |
| ray_laptop | henrys: they are doing BNM from the contone into planar data in pms_600x600to300x300_MTR_5C | 16:01.07 |
| mvrhel_laptop | in gs_image_begin_typed | 16:01.09 |
| kens | : Hmm, either pdfwrite doesn't go there, or it doens't woprk, just a moment | 16:01.33 |
| mvrhel_laptop | in gsimage.c line 219 | 16:01.44 |
| | it does a code = gx_set_dev_color(pgs); which then leads to things getting set up | 16:02.06 |
| henrys | anyway I leave it to ray_laptop and Robin_Watts I have my own chaos to unravel. | 16:02.41 |
| mvrhel_laptop | kens: I am doing pdfwrite | 16:02.46 |
| kens | mvrhel_laptop : me too give me a minute | 16:02.57 |
| mvrhel_laptop | brb in 2 secs | 16:03.04 |
| ray_laptop | henrys: what a MESS that code is | 16:03.11 |
| Robin_Watts | Why? Why? Why? Why would they fiddle with it THERE? | 16:03.51 |
| henrys | ray_laptop: yes I really want to act proactively and get a good working solution or we're going to get in a hole with this one. | 16:04.11 |
| kens | mvrhel_laptop : THat works for the imagemask, but not for the image | 16:04.21 |
| henrys | that much is obvious | 16:04.24 |
| kens | For the image, uses_color is false | 16:04.33 |
| Robin_Watts | henrys: Indeed. I think we should send them a strongly worded email saying that we consider them to be working the wrong way. | 16:05.01 |
| | When they move to 9.10 they should do stuff in the device. | 16:05.22 |
| ray_laptop | Robin_Watts: I suspect it is because they want it to be multi-threaded. Their device is in the main thread | 16:05.29 |
| Robin_Watts | ray_laptop: Urgh. | 16:05.45 |
| kens | mvrhel_laptop : do you follow me ? | 16:05.52 |
| ray_laptop | Robin_Watts: but they'd be better off (IMHO) just spawning threads in their device | 16:05.55 |
| | they are probably (like many folks) sort of scared of threads, but I sure hope they know what they are doing in all that mess to make it thread safe. | 16:07.17 |
| henrys | Robin_Watts, ray_laptop I also don't want to be rude - I'm going to bring in takane-san and consult with him about how best to pursue this. | 16:08.34 |
| ray_laptop | henrys: PLEASE!!! | 16:08.49 |
| Robin_Watts | ray_laptop: Yes, I bet you're right about them wanting the benefit of multi-threading. | 16:09.07 |
| | That would explain why they've put it in there. | 16:09.15 |
| ray_laptop | I'd rather us do it then have them have stuff buried in gxclthrd.c | 16:09.16 |
| | and those pms BNM functions can't be fast | 16:09.48 |
| mvrhel_laptop | kens : I am back | 16:12.21 |
| kens | OK mvrhel_laptop THe first pass is an image which sets uses_color to false, so we don't execute gx_set_dev_color | 16:12.58 |
| ray_laptop | henrys: unless you want me to dig into this mess, I'm just going to ignore it until we hear back from them | 16:12.59 |
| | and work on the urgent cust 532 issue | 16:13.11 |
| kens | mvrhel_laptop : THe imagemask (the second call) does have 'uses_color' true so that works | 16:13.18 |
| henrys | ray_laptop: makes sense | 16:13.21 |
| mvrhel_laptop | kens: so where do you need to have the icc profile and you don't have it? | 16:13.48 |
| kens | mvrhel_laptop : The image (first call) ends up innew_pdf_begin_typed_image and there is no Icc_equivalent in the color space, I need one there. | 16:14.29 |
| | I could do it myself if that's reliable. | 16:14.45 |
| | ie I can test the icc_equivalent, and if its nULL I cna call gx_set_dev_color | 16:15.10 |
| | Oh actually, maybe I can't, I'm not sure I have a full graphics state | 16:15.35 |
| | No, its OK I do have a full graphics state, so I cna do it myslef | 16:16.06 |
| | If you think that's acceptable | 16:16.14 |
| Robin_Watts | henrys, ray_laptop: A smart way to do this might be to allow devices to declare a 'post-render' function that will get called on each band (or buffer) after rendering is done. | 16:16.18 |
| ray_laptop | Robin_Watts: right. That would let tiffscaled scale the buffers in multiple threads, which would please cust 531 | 16:17.21 |
| Robin_Watts | That would get the device the multi-threading stuff for free. | 16:17.28 |
| | ray_laptop: Hmm. hadn't considered that, but yes. | 16:17.38 |
| ray_laptop | Robin_Watts: they have BIG IRON 12 core Xeon and use the tiffscaled sometimes I think | 16:17.55 |
| Robin_Watts | tiffscaled uses error diffusion, so each band is not independent. | 16:18.06 |
| ray_laptop | Robin_Watts: I thought tiffscaled just did thinks like 600 to 200. | 16:19.00 |
| mvrhel_laptop | kens: so I am never getting to new_pdf_begin_typed_image | 16:19.07 |
| | what am I doing wrong | 16:19.16 |
| ray_laptop | goes to check the tiffscaled docs | 16:19.26 |
| mvrhel_laptop | am I supposed to have -dPDFUseOldCMS? | 16:19.32 |
| kens | mvrhel_laptop : you need to set -dPDFUseOldCMS=false to get there, other wise you end up in pdf_begin_typed_image | 16:19.34 |
| Robin_Watts | ray_laptop: The downscaler changes resolution and/or color depth. | 16:19.38 |
| mvrhel_laptop | oh = false | 16:19.43 |
| kens | mvrhel_laptop : but the poitn is that the color space at that time has no icc_equivalent, you don;t really need to go there | 16:20.02 |
| Robin_Watts | In particular, it can go from 8bpp -> 1bpp, and for that it uses error diffusion to get much nicer results than simple dithering. | 16:20.07 |
| ray_laptop | Robin_Watts: I see (having read the docs, now) | 16:20.29 |
| mvrhel_laptop | kens: well I am just trying to see the stack at that point and why we dont have one | 16:20.31 |
| marcosw_ | sorry I'm late | 16:20.40 |
| Robin_Watts | ray_laptop: But for non color depth changes, yes, working on the threads would be nicer. | 16:20.56 |
| ray_laptop | Robin_Watts: BNM is almost as nice and *much* faster, so it should be an option (IMHO) | 16:21.05 |
| kens | mvrhel_laptop : OK well if you set -dPDFUseOldCMS you'll end up in the new funstion, if you don't then you end up in pdf_begin_typed_image, but the bew one uses icc_equivalent while the old one does not. | 16:21.30 |
| mvrhel_laptop | kens: you have a full gstate there | 16:21.36 |
| ray_laptop | Robin_Watts: and BNM *could* be done in threads | 16:21.37 |
| kens | mvrhel_laptop : yes, I did say that in one commetn above | 16:21.49 |
| mvrhel_laptop | ok | 16:21.53 |
| kens | I also said I cna gall gx_set_dev_color, if its appropriate to do so and won't cause nay headaches ;-) | 16:22.19 |
| Robin_Watts | ray_laptop: right. | 16:22.21 |
| mvrhel_laptop | kens: it really is the only way to do it. until that is done, the profile will not be generated | 16:22.44 |
| kens | mvrhel_laptop : No problem, then I will go ahead and add that check throughout (there are a number of places I assume that icc_equivalent is set). I'll do it tomorrow though. Thanks. | 16:23.29 |
| mvrhel_laptop | ok. | 16:23.38 |
| | so does this solve question 2 too? | 16:23.44 |
| ray_laptop | if anybody needs me, just SMS if I'm not responsive here. | 16:24.29 |
| henrys | marcosw: we'd like to test GX_COLOR_INDEX of size 64 and 32 (compile time) is that okay? | 16:25.22 |
| kens | mvrhel_laptop : I don't think so. In that case the colour I'm getting back from the CMS seems to be incorrect. | 16:25.28 |
| henrys | marcosw: do we test anything that varies at compile time? | 16:25.54 |
| kens | mvrhel_laptop : Its a CIEA space, and the colour value is '1' when I render that it comes out as white. When I convert it to RGB it comes out as mostly black | 16:26.01 |
| sicos | good evening | 16:27.20 |
| | Does somebody know if it is normal with ghostscript to get an inverted tiff file (black is white and white is black) when I use the tiffscaled device with g4 compression to convert a pdf to tif? | 16:28.08 |
| chrisl | sicos: that sounds wrong. | 16:29.30 |
| sicos | it happens with every pdf that I use | 16:29.42 |
| | When I use g3 compression everything is fine... but I need g4 compression | 16:30.05 |
| mvrhel_laptop | kens: ok I will take a look | 16:30.20 |
| sicos | I tried gs 9.06 to 9.10 but all have the same problem | 16:30.33 |
| kens | mvrhel_laptop : thanks. I have to go off and deal with dinner now, I'll be back later | 16:30.40 |
| chrisl | sicos: well it sounds like a bug. Why do you *need* g4? | 16:30.43 |
| sicos | We have some scanner software that does some ocr ... it only accepts fax ccitt 4 compression (g4) | 16:31.21 |
| | It refuses to accept anything else | 16:31.41 |
| chrisl | Well, report a bug, and we'll look into it | 16:32.06 |
| sicos | I'll do | 16:32.14 |
| | kens.. have a nice dinner | 16:32.38 |
| chrisl | sicos: what platform are you running? Did you build gs yourself? | 16:33.43 |
| sicos | Just another question... Why is the output quality better when I use -r600 with for example downscale factor 6 to get a tiff with 100dpi instead of just using -r100 ? | 16:33.46 |
| | chrisl .. I'm on Windows and downloaded gs from the download page | 16:34.14 |
| chrisl | I think if you use -r600 you get 600dpi output | 16:34.40 |
| Robin_Watts | chrisl: No, he's right. | 16:34.56 |
| sicos | I got the problem on my work with windows xp, also have it on a windows 2003 server and at home on windows 8 | 16:35.07 |
| Robin_Watts | gs renders at the specific resolution internally. So 600dpi. Then it applies the downscale factor to get to 100dpi. | 16:35.38 |
| chrisl | Ah, I thought it worked the other way round | 16:35.57 |
| sicos | Normally I used -r100 until I discovered the downscale factor... the result is huge | 16:36.17 |
| | Didn't know that would make such a difference | 16:36.27 |
| Robin_Watts | No, the downscale happens 'post getbits', so the resolution sets what you get out of getbits. | 16:36.27 |
| mvrhel_laptop | kens: for when you return. with issue 2 I am never getting to write_color_as_process | 16:36.43 |
| Robin_Watts | sicos: When you are using a downscale factor, we render at 8bpp internally, and then error diffuse down to 1bpp. | 16:36.52 |
| | error diffusion gives much nicer results than a simple halftone. | 16:37.05 |
| | But 600dpi down 6 is way overkill. | 16:37.13 |
| sicos | Does it make a huge speed difference? | 16:37.21 |
| | use downscaling instead of -r100 | 16:37.31 |
| Robin_Watts | You'll probably do just as well with 300dpi down 3. | 16:37.31 |
| | There will be a performance difference, yes. | 16:37.46 |
| sicos | Robin: I'm still in the trying out phase so I'll keep that in mind.. thanks for the suggestion | 16:38.03 |
| Robin_Watts | I wouldn't like to predict how huge. | 16:38.10 |
| mvrhel_laptop | kens: perhaps I am missing some change you have | 16:38.28 |
| Robin_Watts | 200dpi down by 2 will effectively draw 4 times as many pixels. | 16:38.29 |
| | 300 down 3 9 times as many pixels. | 16:38.38 |
| | 600 down 6, 36 times as many pixels. | 16:38.52 |
| mvrhel_laptop | until then, I will fool with mupdf | 16:39.04 |
| Robin_Watts | And I have special case code in there for the 2 and 3 case, IIRC. | 16:39.12 |
| | So, tor7, how's the chromebook? | 16:43.36 |
| chrisl | sicos: I can't reproduce the problem on Linux - what are you using to view the tiff? | 16:43.49 |
| sicos | faststone image viewer | 16:44.19 |
| | i'll try the fax viewer | 16:44.55 |
| chrisl | Okay, I don't know that app, but as long as it wasn't the Windows viewer - it has lots of troubles with tiff | 16:45.12 |
| sicos | uhm | 16:45.39 |
| | seems to be a faststone image viewer problem | 16:45.49 |
| | uhm... sorry about that | 16:45.56 |
| Robin_Watts | sicos: ah, phew. | 16:46.11 |
| sicos | strange... when I use another tool to produce g4 files they all open fine with faststone | 16:46.35 |
| | so I wonder what bit in the header file of the tiff throws faststone image viewer off | 16:46.56 |
| chrisl | It may be the photometric | 16:47.12 |
| | Our output is "Photometric Interpretation: min-is-black" | 16:47.50 |
| Robin_Watts | henrys: Where are you seeing the 16bit operation in this stuff? | 16:47.59 |
| sicos | well nevermind... keep up the good work with ghostscript.. it is a fantastic tool | 16:48.26 |
| henrys | I'm seeing a copy from a byte array to a short array | 16:48.31 |
| Robin_Watts | henrys: where? | 16:48.39 |
| sicos | and it sure beats a lott of other tools | 16:49.09 |
| chrisl | sicos: libtiff comes with some useful tools for getting info from tiffs, if you can find it for Windows | 16:49.33 |
| henrys | gxclthread.c:4944 near that. | 16:50.07 |
| Robin_Watts | ok. I was looking in the mono case, and that doesn't use 16 bits. | 16:51.11 |
| henrys | unsigned short *avgColor | 16:51.35 |
| Robin_Watts | henrys: yeah, they are copying the CMYK values into the output and adding them. | 16:52.26 |
| | so they are holding 4 lots of 8 bit values added together in each short. | 16:52.42 |
| | Then they divide by 4 at the end. | 16:52.58 |
| ray_laptop | mvrhel_laptop: for RAW_DUMP, should I check "Interleaved" ? | 16:53.05 |
| Robin_Watts | so it's only 8 bit operation, implemented extremely inefficiently. | 16:53.12 |
| mvrhel_laptop | ray_laptop: the data is planar not interleaved | 16:53.25 |
| Robin_Watts | God, that's a horrible piece of code. | 16:53.41 |
| mvrhel_laptop | ray_laptop: what are you working on? | 16:53.45 |
| sicos | Robin: I also tried to open the tiff with the "Microsoft office picture viewer" but that one also doesn't like the tiff :-) | 16:54.02 |
| ray_laptop | mvrhel_laptop: OK. Thanks. Sorry, I forgot to mention that I was asking about the Photoshop settings, but I guess you figured that out | 16:54.12 |
| mvrhel_laptop | yes | 16:54.20 |
| henrys | marcosw came by to say sorry he was late and then left apparently ;-) | 16:55.08 |
| Robin_Watts | ray_laptop: So... this idea of having a 'post process' function seems like a good one to me. | 16:56.15 |
| ray_laptop | OK, so *finally* got RAW_DUMP to work with cust 532's code | 16:56.24 |
| | Robin_Watts: yes, indeed | 16:56.31 |
| Robin_Watts | It would be a much nicer solution to this, and has scope for other things. | 16:56.42 |
| | BUT... I can see that in a lot of cases, people are going to want a guarantee that the post process things are run "in order" | 16:57.06 |
| sicos | is there any magic downscalefactor formula like 600 downscale 2 for 300 dpi, 400 downscale 2 for 200 dpi and 200 downscale 2 for 100 dpi? | 16:57.19 |
| ray_laptop | I'm up to the ears with cust 532's pb. Can you suggest what parameters we'd pass when we callout ? | 16:57.46 |
| Robin_Watts | (for instance, if people are doing say, error diffusion, or they are sending data off via DMA, or they are writing it to a file etc). | 16:57.47 |
| | ray_laptop: Sure. I'll put together a proposal. | 16:58.05 |
| kens | mvrhel_laptop : My mistake, you need to set the DEVICE=ps2write -dPDFUseOldCMS=false | 16:58.17 |
| mvrhel_laptop | oh | 16:58.23 |
| | ok | 16:58.25 |
| ray_laptop | Robin_Watts: for DMA, they want the bands in order, not when they are finished, which will be arbitrary order | 16:58.26 |
| kens | dashes off again | 16:58.35 |
| Robin_Watts | ray_laptop: Right, that's my point. | 16:58.39 |
| | So, possibly we'd want an option to ensure that the bands happen 'in order'. | 16:59.08 |
| ray_laptop | and writing to a file, would need to have the entire page allocated and do *seek* to write whichever band | 16:59.21 |
| Robin_Watts | Or we could leave it to the function that's called back to wait in turn. | 16:59.30 |
| | My point is, that even if the callbacks wait to happen in sequence, it would still be a net win overall, I think. | 17:00.29 |
| ray_laptop | Robin_Watts: I think that doing DMA or file writing is best left to the main thread, but updating a page image in memory can be done randomly | 17:00.47 |
| Robin_Watts | as one thread can get on with rendering while the next one is in the callback. | 17:01.20 |
| ray_laptop | Robin_Watts: it'll be a win if there is more processing than just writing the bands | 17:01.21 |
| chrisl | sicos: what you mean by "magic"? | 17:01.42 |
| Robin_Watts | so my question is, should we offer an optional 'in order' guarantee? | 17:01.58 |
| ray_laptop | Robin_Watts: can JPEG or PNG be compressed as bands ? | 17:02.27 |
| Robin_Watts | i.e. should the device be able to say "please call this function back after each band, and do so in order". | 17:02.29 |
| sicos | just the best option between memory usage and speed | 17:02.35 |
| Robin_Watts | ray_laptop: depending on the settings in use, yes. | 17:02.37 |
| sicos | I mean memory usage, quality and speed | 17:02.50 |
| chrisl | sicos: it rather depends what your goal is. | 17:03.16 |
| | sicos: there's no magic bullet that's right in all cases | 17:03.36 |
| ray_laptop | Robin_Watts: having to wait for previous threads means it kills the parallelism | 17:03.47 |
| sicos | chrisl: good quality for ocring but with good speed | 17:03.49 |
| Robin_Watts | ray_laptop: It *limits* the parallelism, it doesn't kill it. | 17:04.04 |
| sicos | chrisl: I use a quadcore server with 8gb of memory to do all the conversion jobs | 17:04.35 |
| chrisl | sicos: I don't work with any ocr packages. Best I can suggest is to experiment. Personally, I'd think that you'd want fairly hi res output for accurate OCR operation | 17:05.10 |
| Robin_Watts | sicos: It depends on your input file and the input that the OCR package takes. | 17:05.16 |
| ray_laptop | Robin_Watts: how so? If thread 1 (the first band) takes longer than thread 2, 3, and 4. then 2, 3 and 4 will have to wait until thread 1 is done and thread 4 has to wait for 1, 2, 3 to finish | 17:05.25 |
| | Robin_Watts: plus the threads don't know about each other (currently) | 17:06.02 |
| Robin_Watts | ray_laptop: Yes. But as soon as the band processing of 1 is finished, that thread can start processing 5, while we do the post band processing of 2. | 17:06.04 |
| ray_laptop | Robin_Watts: but if the callout post processing is compute intensive, then we don't get to overlap ! | 17:06.56 |
| tor7 | Robin_Watts: absolutely gorgeous! | 17:06.57 |
| Robin_Watts | so the concurrency is not as smooth as before (i.e. there will be contention), but it's better than nothing. | 17:07.17 |
| tor7 | Robin_Watts: best screen I've ever had (though obnoxiously shiny, but I can live with that) | 17:07.21 |
| | good keyboard, and trackpad is apple quality | 17:07.30 |
| Robin_Watts | ray_laptop: Indeed. | 17:07.32 |
| ray_laptop | Robin_Watts: I don't see how it's better than letting the main thread just have it | 17:07.41 |
| chrisl | sicos: also, I'd have thought that using grayscale instead of halftoned output would be preferable for OCR (if the ocr can take it), but I don't really know. | 17:07.51 |
| tor7 | going to get a high speed SD-card tomorrow, so I'll see how it does on dual-booting | 17:07.59 |
| ray_laptop | in order, after the callout has finished | 17:08.01 |
| tor7 | running crouton to get a chroot:ed ubuntu install works just great though | 17:08.13 |
| sebras-hotel | tor7: and you'll get me a picture..? | 17:08.14 |
| tor7 | shame about linux toolkits not really coping with high-dpi screens :( | 17:08.31 |
| ray_laptop | that way all of the callout processing is ALWAYS in parallel | 17:08.32 |
| tor7 | sebras-hotel: working on it. one sec. | 17:08.49 |
| Robin_Watts | ray_laptop: OK, I think you've killed my idea of us offering a 'callback in order' option. | 17:09.03 |
| ray_laptop | Robin_Watts: I really have to get to work now, however. Glad to talk more later | 17:09.10 |
| sicos | chrisl: at the moment I first convert a pdf to pnggray and then use victor.dll to convert it to g4 format (that is because i thought ghoscript screwed my tiff file up.. I know better now :-)) | 17:09.13 |
| | chrisl: But I'm probably going to fix that code now that I know it is a faststone image viewer problem | 17:09.36 |
| | chrisl: so it's no more a 2 step conversion. | 17:09.55 |
| sebras-hotel | tor7: sounds like a nice, square pixel though. :) | 17:09.59 |
| chrisl | sicos: sure, but I'd have thought the pixel "patterns" of the halftone might pose extra problems for the OCR package. | 17:10.33 |
| Robin_Watts | sicos: Does the OCR package only accept 1bpp input files? | 17:11.07 |
| sicos | yes | 17:11.13 |
| sebras-hotel | tor7: actually if you want to make it easy, you might want to use Line to send it to me... | 17:11.27 |
| sicos | it want to have ccitt fax 4... so far as I know that is 1bpp | 17:11.37 |
| chrisl | sicos: oh well, so much for that idea | 17:11.49 |
| Robin_Watts | sicos: it is. It's a shame that it only takes 1bpp input, cos it's forcing someone to have made decisions about throwing information away already. | 17:12.18 |
| sicos | don't shoot the messenger :-) | 17:12.36 |
| chrisl | I still think you'd want high-ish res for best results | 17:12.57 |
| Robin_Watts | Most scanners output 8bpp data, which would be a much more sensible input to an OCR package as it wouldn't have to cope with dithering etc. | 17:13.04 |
| | chrisl: Given that you need 1bpp input, you probably want high res, but with decent error diffusion. | 17:13.35 |
| sicos | does the tiffscaled device also support antialiasing? | 17:13.39 |
| | or is that only possible on png? | 17:13.45 |
| Robin_Watts | sicos: Antialiasing is the trading of spatial information for color depth information. It's kinda hard to do that when you are going to 1bpp. | 17:14.17 |
| | But tiffscaled works in 8bpp internally, then scales down, then error diffuses; so the internal representation (before error diffusion) is antialiased. | 17:15.03 |
| sicos | but for example if you go to tiff gray scale.. does it then make any difference? | 17:15.07 |
| | ok | 17:15.13 |
| chrisl | And you certainly don't want antialised output for OCR purposes | 17:15.26 |
| Robin_Watts | chrisl: Unless you have overly high res predithered input. | 17:15.47 |
| chrisl | I'd assume that you'd want the sharpest defined edges possible for OCR | 17:16.39 |
| sicos | indeed | 17:16.45 |
| Robin_Watts | chrisl: Imagine that you are trying to OCR something that's come out of a full color CMYK process with colored text in it. | 17:17.11 |
| | but I'll admit that's a corner case. | 17:17.48 |
| sebras-hotel | tor7: oh! I spy with my little eye, no windows keys! :) | 17:17.52 |
| tor7 | sebras-hotel: the "caps lock" is by default Super_L ;) | 17:18.13 |
| sebras-hotel | tor7: even better! :) | 17:18.26 |
| | tor7: doesn't even look like it's labeled caps lock. | 17:18.44 |
| | labelled! | 17:18.56 |
| sicos | What I'm trying to find is the best setting possible for ghostscript. I know the output has to be g4. The input file kan be any kind of pdf in anykind of resolution, fully text or just scanned images | 17:19.08 |
| sebras-hotel | tor7: but when you move that chair, don't unplug the extension cord... | 17:19.33 |
| chrisl | Robin_Watts: I was thinking more of using the output of a RIP that you can control. I'd have thought something like 600dpi, 1bpp error diffusion halftoned would give the best OCR results. | 17:19.42 |
| sebras-hotel | leaves for bed, good night artifexians! | 17:20.06 |
| Robin_Watts | chrisl: Does tiffscaled handle -dDownScaleFactor=1 ? :) | 17:20.24 |
| sicos | It is an automated proces so there is no man in the middle that can fiddle with the conversion settings | 17:20.26 |
| chrisl | sebras-hotel: good night | 17:20.30 |
| tor7 | sebras-hotel: good night! | 17:20.30 |
| sicos | good night | 17:20.38 |
| Robin_Watts | sicos: Try: -r600 -dDownScaleFactor=1 | 17:20.51 |
| chrisl | Robin_Watts: well, it didn't throw an error..... | 17:21.04 |
| mvrhel_laptop | kens: so I see 2 issues | 17:21.08 |
| sicos | sorry forgot one thing.. the resolution has to be 300 dpi :-) | 17:21.12 |
| mvrhel_laptop | One is that the equivalent profile was not being used with the call to get_link. I will commit that fix | 17:21.33 |
| Robin_Watts | -r300 -dDownScaleFactor=1 then. | 17:21.38 |
| mvrhel_laptop | however. that is not the source of the black vs white | 17:21.47 |
| Robin_Watts | or -r600 -dDownScaleFactor=2 | 17:21.49 |
| chrisl | That does indeed seem to work] | 17:21.52 |
| mvrhel_laptop | kens: the main problem is line 463 in gdevpdfg.c | 17:22.54 |
| | the color values in Converted are coming out white | 17:23.22 |
| | but the mapping to colors.pure in 463 is not doing what I think you want it to do | 17:23.41 |
| chrisl | Robin_Watts: I assume -r300 -dDownScaleFactor=1 will be faster..... | 17:23.52 |
| Robin_Watts | chrisl: Yes. | 17:25.08 |
| mvrhel_laptop | kens: let me see if I can fix it... | 17:26.05 |
| sicos | does .. uhm i think to parameter was called renderingthreads .. speed anything up? | 17:26.09 |
| Robin_Watts | sicos: I doubt it. | 17:26.39 |
| chrisl | sicos: probably not at 300dpi, no | 17:26.50 |
| Robin_Watts | renderingthreads will help the rendering time of the doc. It will not help the error diffusion process, and I suspect that is the slowest bit. | 17:27.10 |
| sicos | and dBandBufferSpace ? | 17:28.19 |
| | since i got more then enough of memory in the server | 17:28.37 |
| mvrhel_laptop | ok. that fixed it. | 17:29.01 |
| chrisl | sicos: do you know if the text is always pure black, or can it be other colours and tints? | 17:29.04 |
| Robin_Watts | sicos: If memory is no object use -dMaxBitmap=10000000 | 17:29.07 |
| mvrhel_laptop | you wanted /256 not /255 kens. | 17:29.08 |
| sicos | it can be any kind of pdf | 17:31.21 |
| | with just scanned color pages in it.. or black and white... it even can be a text based pdf | 17:31.54 |
| chrisl | Okay, so you do want the error diffusion - if the text had always been pure black, then a quicker halftone solution would be viable | 17:32.28 |
| sicos | I work at an insurrance company and customers can declare there bills through a web portal. I dont know how there pdf files are generated | 17:32.30 |
| Robin_Watts | sicos: I would encourage you to get your bosses to get a support contract for gs. | 17:33.22 |
| sicos | it can be a paper bill that they scan on just a pdf bill they got from for example there dentist | 17:33.22 |
| | robin: do you know how much that will cost for a year? | 17:34.13 |
| Robin_Watts | If you are using it as part of a large commercial enterprise (and you are), it would seem reasonable to ensure you have support. | 17:34.20 |
| | offhand, no. | 17:34.25 |
| mvrhel_laptop | kens: ok clusterpushing a fix | 17:34.42 |
| sicos | I already tried to look it up on the ghostscript portal but there aren't any prices overthere | 17:34.53 |
| Robin_Watts | but if you contact sales@artifex.com they can do you a quote. | 17:34.57 |
| | sicos: Indeed, we tailor prices to circumstances. | 17:35.08 |
| sicos | well i'm going to call it a night... I think I asked you enough.. thanks for listening | 17:36.16 |
| | I'll send a mail to artifex.. thanks for the tip | 17:37.05 |
| Robin_Watts | np. | 17:38.07 |
| mvrhel_laptop | windoze 8.1 update out this friday.... | 17:51.32 |
| | and VS 2013 comes out in less than 1 month | 17:53.32 |
| Robin_Watts | mvrhel_laptop: Are you taking orders? :) | 17:54.23 |
| | So, you can't code for windows 8.1 without VS 2013. That means a month where no one will be able to use Windows 8.1 - so no change there then! :) | 17:56.08 |
| mvrhel_laptop | Robin_Watts: Maybe I can bring a copy to the next staff meeting | 17:56.54 |
| Robin_Watts | mvrhel_laptop: I'm not in the market for the 8.1 update. I never use my copy of windows 8, personally. | 17:57.29 |
| | Depending on what VS 2013 brings to the party, it may or may not be worth buying a copy for the company. | 17:57.58 |
| mvrhel_laptop | true. I will get myself a copy for 8.1 dev. and see what is new | 18:00.46 |
| Robin_Watts | Do MS offer a VS2012->2013 upgrade? | 18:01.27 |
| mvrhel_laptop | kens: fix for you problem #2 pushed | 18:01.30 |
| | Robin_Watts: not idea | 18:01.36 |
| | no diea | 18:01.39 |
| | idea | 18:01.41 |
| kens | mvrhel_laptop : I just got back, thanks, that was quick! | 18:01.42 |
| mvrhel_laptop | I am eager to get done with gs and fix my mupdf issues... | 18:02.08 |
| Robin_Watts | I can imagine that people who forked out for VS2012 to do win 8 dev are now going to be very annoyed if they have to fork out again for a .1 revision. | 18:02.09 |
| mvrhel_laptop | oh 8.1 is free | 18:02.19 |
| | dont know about VS2013 | 18:02.25 |
| kens | is keen to finish up the colour code | 18:02.25 |
| mvrhel_laptop | kens: I am hoping to get you V2 profiles before staff meeting | 18:02.41 |
| kens | That would be cool | 18:02.48 |
| mvrhel_laptop | but I am going to work on mupdf for a bit now | 18:02.53 |
| kens | No problem, I have to go back to pdfwrite and the diffs that are produced. Some are progressions some are just slightly different. I need to make sure no more are faults | 18:03.24 |
| mvrhel_laptop | Robin_Watts: I see what you are saying | 18:03.30 |
| | yes that would be annoying | 18:03.33 |
| | kens: did you happen to see 694704 | 18:06.36 |
| kens | Hmm, not sure, just a momnet | 18:06.48 |
| Robin_Watts | http://weblogs.asp.net/lduveau/archive/2013/07/10/visual-studio-2012-2013-and-windows-8-1-apps-clarifications.aspx | 18:06.55 |
| mvrhel_laptop | I tried to understand in the interpreter why we do the sethalftone when the device is not a halftone device | 18:07.02 |
| | but it is not clear to me | 18:07.09 |
| Robin_Watts | So VS2012 will not let you use the 8.1 additions. | 18:07.16 |
| kens | mvrhel_laptop : I haven't looked at that bug | 18:07.22 |
| Robin_Watts | MS really hate their developers, don't they? | 18:07.31 |
| kens | Presumably we set the halftone because the graphics state requiers that we have one | 18:07.48 |
| mvrhel_laptop | hmm this does seem like a mess | 18:08.35 |
| kens | wonders exactly what new functionality there is in windows 8.1 that VS 2012 apps can't target | 18:08.46 |
| mvrhel_laptop | I have a friend in the VS marketing group. I will have to ask him about this | 18:08.50 |
| | window 8.1 has a lot of stuff | 18:09.03 |
| | for e.g. native pdf rendering... | 18:09.11 |
| | I would be worried though about app creation compatibility between 8 and 8.1 | 18:10.33 |
| | not sure it makes sense for someone to create something for 8.1 | 18:10.52 |
| | but perhaps everyone with 8 will update | 18:11.06 |
| Robin_Watts | mvrhel_laptop: Well, if the .1 is a free upgrade, ms can hire someone to go round all three of the users houses and update them. | 18:11.27 |
| mvrhel_laptop | hehe | 18:11.34 |
| ray_laptop | I wonder how many of the broken / invalid PDF's their native rendering will cope with. And how well they'll handle the funky fill-black then imagemask white problem files we've seen. And the missing fonts. And ... | 18:16.56 |
| | and whether or not they'll let people render into an image file | 18:17.39 |
| Robin_Watts | ray_laptop: 2 possible ways to do this suggest themselves; a new device function, or a dev spec op. | 18:18.34 |
| ray_laptop | we should license GS to them so they can import PostScript, and take a step toward killing Acrobat | 18:18.39 |
| Robin_Watts | A friend just asked me "does VS2013 have new features, like lower case letters?" | 18:19.46 |
| ray_laptop | Robin_Watts: why not just a pointer in the gx_device_printer * structure. gdev_prn_open inits it to NULL, they just set it before requesting data in 'print_page' | 18:20.05 |
| | I don't see a reason we need a spec op or device function | 18:20.41 |
| Robin_Watts | Do all clist things go through a gx_device_printer ? | 18:20.58 |
| ray_laptop | Robin_Watts: Not pattern-clist, but we don't do MT rendering for those | 18:21.29 |
| kens | is off now, I'll get back to the colour code tomorrow Michael, thanks again. Night all | 18:22.05 |
| Robin_Watts | So I can safely cast dev in clist_render_thread to a gx_device_printer? | 18:22.16 |
| | I was thinking that it would be good if this callback would work in both clist and non-clist cases. | 18:22.55 |
| mvrhel_laptop | bbiaw | 18:23.08 |
| Robin_Watts | casting from dev to gx_device_printer in clist_render_thread feels very wrong to me. | 18:27.27 |
| | ok, so the only way we can ever get into the multi-threaded rendering case is if gdevprn.c has set it up. | 18:31.44 |
| ray_laptop | Robin_Watts: to make the callback work for non-clist devices, we'd have to add it to gdev_prn_get_bits and gdev_prn_get_bits_rectangle if !PRINTER_IS_CLIST(pdev) | 18:31.53 |
| Robin_Watts | ray_laptop: Can we add it there and have that do both clist and non clist cases? | 18:32.47 |
| ray_laptop | at that point we'd call out with whatever data comes from the underlying mem_get_bits_rectangle | 18:32.52 |
| | Robin_Watts: no, because those two functions are in the main thread (above the get_bits_rectangle call) | 18:33.24 |
| Robin_Watts | ok. | 18:33.38 |
| | we also need to make it get called in the clist, but not multithread case. | 18:34.01 |
| ray_laptop | in the non-clist case, there really won't be any parallel processing since everything else for the page is done | 18:34.29 |
| | Robin_Watts: yes | 18:34.40 |
| Robin_Watts | ray_laptop: Right, but it means the device writers don't need to worry about which case they are in. | 18:35.23 |
| ray_laptop | Robin_Watts: right. I understood your intent and agree | 18:35.42 |
| | Robin_Watts: it would be fun to do a clist display device and have the callback update bands on its page buffer :-) | 18:37.32 |
| | watch parallel processing in action | 18:37.49 |
| Robin_Watts | interesting. | 18:38.00 |
| | So new printer device proc you reckon. | 18:39.10 |
| | s/So/So a/ | 18:39.17 |
| ray_laptop | huh ? | 18:39.21 |
| Robin_Watts | You reckon the way to do this is to have a new printer device proc? | 18:39.54 |
| ray_laptop | I was just thinking a *post_processing_callback(...) element in the gx_device_printer struct | 18:40.06 |
| Robin_Watts | Ah, ok. | 18:40.15 |
| ray_laptop | I guess it could be buried in the printer_procs | 18:40.59 |
| | Robin_Watts: actually, putting it in the gx_printer_device_procs makes sense and is OK with me | 18:42.41 |
| Robin_Watts | ok. | 18:42.48 |
| ray_laptop | all you have to do is figure out what params it should have (beyond gx_device_printer *) | 18:43.47 |
| Robin_Watts | the buffer device, the band number, the number of lines. | 18:44.21 |
| ray_laptop | Robin_Watts: seems like enough. The buf_device has the info needed to access the band data | 18:49.10 |
| Robin_Watts | ray_laptop: Yeah. | 18:49.37 |
| ray_laptop | so the calling function just calls get_bits or get_bits_rectangle on the bdev | 18:49.50 |
| | and can cast the gx_device_printer to its device struct to get any info needed for the post processing, including, possibly where to put the results | 18:51.11 |
| Robin_Watts | I'm having trouble parsing that. | 18:52.24 |
| ray_laptop | Robin_Watts: where will the data be processed into ? | 18:52.43 |
| Robin_Watts | ray_laptop: That's device specific. | 18:53.01 |
| | The callback can choose to work 'in place' on the buffer device, or it can choose to copy to some other secret buffer that gs knows nothing about (but that it finds from within it's gx_device *) | 18:53.49 |
| ray_laptop | yes, but where does it get the destination if it needs buffering. Or if it allocs it's buffer, how does it return the pointer ? | 18:53.54 |
| Robin_Watts | ray_laptop: Right. That should be hidden in the devices own structure. | 18:54.31 |
| ray_laptop | Robin_Watts: each post_process invocation will need its own buffer. | 18:54.48 |
| | it can't just scribble is a shared buffer | 18:55.15 |
| | Robin_Watts: how about adding a *result param | 18:55.44 |
| Robin_Watts | ray_laptop: What would we do with it? I'm against that. | 18:55.56 |
| | The customers code allocates a buffer, uses the buffer, and then writes the results back into the buffer device. | 18:56.22 |
| | so the caller can read it out as the results of the getbits. | 18:56.30 |
| ray_laptop | Robin_Watts: but the buffer device type and how it holds its data is opaque | 18:56.48 |
| Robin_Watts | ray_laptop: It had better not be opaque - the purpose of this post process callback is to work on it. | 18:57.18 |
| ray_laptop | I'm missing something. In order for the post process to change the data depth or anything else, it CAN'T use the same buffer | 18:58.23 |
| | the post_process calls the bdev->procs.get_bits to read from the rendered data in whatever format, but it can't scribble back in there | 18:59.23 |
| Robin_Watts | ray_laptop: If it's working 'in-place' then it is limited in what it can do, yes. | 18:59.23 |
| | ray_laptop: Ah, right. The customers code does NOT get the data using get_bits. | 18:59.43 |
| ray_laptop | Robin_Watts: but what if the data it wants to create is LARGER than the buffer | 18:59.47 |
| Robin_Watts | ray_laptop: Then it needs to copy it elsewhere. | 19:00.00 |
| | It can allocate any buffers it likes, and then will have to stash those pointers into a list or something accessed via it's device pointer. | 19:00.40 |
| ray_laptop | Robin_Watts: so how does each post_process thread tell the main thread where it put the data ? | 19:00.56 |
| Robin_Watts | ray_laptop: It doesn't tell the main thread of ghostscript. It tells the device. | 19:01.32 |
| | There will need to be some secret device specific way in which this callback can talk to the "main thread" of the device. | 19:02.11 |
| | but that's not our concern. | 19:02.15 |
| ray_laptop | that's what I meant. The main thread print_page calls get_bits which starts the rendering threads | 19:02.17 |
| Robin_Watts | right, and the rendering threads call into this function. | 19:03.14 |
| | this function is part of the device. It can have any sort of setup it likes to get its results out. | 19:04.09 |
| | gs doesn't need to be involved. | 19:04.26 |
| ray_laptop | but it has to know where the data is when the get_bits returns -- so what ? an array of pointers for each line, or each band or something. We need an example implementation | 19:04.38 |
| Robin_Watts | ray_laptop: Well, the easiest way to do this would be for the device to allocate a page sized buffer up front. | 19:05.59 |
| ray_laptop | Robin_Watts: sort of defeats the clist mode | 19:06.23 |
| Robin_Watts | and then the post process function can map from the rendered image into the page sized buffer. | 19:06.36 |
| ray_laptop | how about an approach that doesn't need so much memory | 19:06.43 |
| | Robin_Watts: I'll mull this over. I have to run an errand. bbiaw | 19:07.09 |
| Robin_Watts | an array of pointers would be just as much memory as a full sized buffer, right? | 19:07.17 |
| ray_laptop | Robin_Watts: not one per line, no | 19:07.40 |
| Robin_Watts | if you're going to have an array of pointers, one per band, presumably by the time that array is fully populated you will have a whole page worth in memory. | 19:08.48 |
| | i.e. the same amount of memory as a page buffer would have needed. | 19:09.01 |
| ray_laptop | oh, I see. how do we know when to free some of the lines (and invalidate the pointer) | 19:11.03 |
| Robin_Watts | ray_laptop: Device specific. | 19:11.24 |
| | gs itself is not involved in anything the device does in the post process phase. | 19:11.43 |
| ray_laptop | I *really* need to run. | 19:11.48 |
| Robin_Watts | sure. go. we can talk later/tomorrow. | 19:11.56 |
| whoami_ | hello | 19:40.07 |
| ghostbot | niihau | 19:40.07 |
| Gigs- | I am having a ton of problems trying to build mupdf related to openjpeg | 19:40.55 |
| Robin_Watts | Gigs-: Are you using the openjpeg that we supply? | 19:41.11 |
| Gigs- | debian doesn't have libopenjpeg1 apparently, so I did the git submodule thing | 19:41.19 |
| Robin_Watts | ok. | 19:41.32 |
| Gigs- | thirdparty/openjpeg doesn't populate, but the -patched one did | 19:41.32 |
| | so I changed the reference in Makethird to the other name, but it's still not compiling | 19:41.48 |
| Robin_Watts | Gigs-: Eh? | 19:42.00 |
| | What git revision are you on? | 19:42.18 |
| Gigs- | Makethird says thirdparty/openjpeg which is an empty dir, there's openjpeg-1.5.0-patched in thirdparty | 19:42.29 |
| | I did git reset --hard and then pulled, should be up to date right? | 19:42.48 |
| | I didn't see an autogen script so I'm not sure about the makefiles | 19:42.56 |
| | nor ./configure for that matter | 19:43.11 |
| Robin_Watts | Gigs-: Do git log -1. | 19:43.12 |
| | and tell me the revision. | 19:43.21 |
| Gigs- | Tue Oct 15 11:30:37 2013 +0200 commit d246518b3f3f64ba10475e5043c554011a383a1ccommit d246518b3f3f64ba10475e5043c554011a383a1c | 19:43.31 |
| | to be honest I could do without openjpeg, jpeg2000 is a nice idea but it's sloooow | 19:44.14 |
| | if it's not used internally I'll never use it for an output format | 19:44.27 |
| Robin_Watts | OK. Now do: git submodule update --init | 19:44.39 |
| Gigs- | k | 19:44.42 |
| | Directory 'thirdparty/jbig2dec' exists, but is neither empty nor a git repository | 19:44.58 |
| | I get that | 19:45.00 |
| | but the first time I did it, it did openjpeg stuff | 19:45.07 |
| Robin_Watts | So delete it, and the -patched one, and retry, | 19:45.19 |
| Gigs- | k | 19:45.24 |
| | nothing happened, I don't think git update replaces missing files | 19:45.49 |
| Robin_Watts | OK. Try completely deleting the thirdparty directory- you haven't got any changed files in there, right ? | 19:46.27 |
| Gigs- | no | 19:46.30 |
| | ok that did it | 19:46.44 |
| | it's getting curl and openjpeg | 19:46.50 |
| | ah ok my thirdparty/openjpeg directory populated now, weird | 19:47.30 |
| | let me try a build | 19:47.54 |
| | looks like it's working now, thanks for your help | 19:48.21 |
| Robin_Watts | np. | 19:48.28 |
| whoami_ | I would like to accelerate the creation of PDF, you have any ideas? (I use already-dNumRenderingThreads = 2-c 30000000 setvmthreshold) | 19:52.02 |
| Robin_Watts | whoami_: Our PDFwrite expert signed off about 4 hours ago. You might want to try again tomorrow. | 19:53.00 |
| | He works on UK time. | 19:53.13 |
| Gigs- | I just have one main lingering question about tint transforms from my essay the other day, FunctionType 0 /Size [ 2 ] /Range [ 0 1 0 1 0 1 0 1 ] /Domain [ 0 1 ] (stream) 00 00 00 00 00 80 FF 00> | 19:54.00 |
| whoami_ | And me French time :) | 19:54.09 |
| Robin_Watts | Sorry, you're creating pdfs, and you're using -dNumRenderingThreads? | 19:54.22 |
| | AIUI, NumRenderingThreads doesn't apply to pdfwrite. | 19:54.32 |
| Robin_Watts | has to step afk for a while, sorry. | 19:55.00 |
| whoami_ | yes that accelerate the creation of pdf | 19:55.11 |
| Gigs- | did it? | 19:55.16 |
| | in my tint transform stream, how is it ordered, like C C M M Y Y K K? If that's the case, why is K inverted? | 19:55.44 |
| whoami_ | Robin_Watts it is in the general framework of a pdf on sending server, then you think that the fastest way to the <strong>customer</strong> that my program sends the ps file and then creates the pdf on the server | 20:03.06 |
| Gigs- | whoami_: where are the PS files now? Are they dynamically generated? | 20:07.17 |
| whoami_ | for now I generates pdf with GS / Redmon with a ruby program. | 20:08.29 |
| Gigs- | where do the source PS come from? | 20:08.47 |
| whoami_ | From printing of user (Printer => Redmon => Ghostscript => PDF) | 20:11.10 |
| Gigs- | There are programs to directly let them print to PDF | 20:12.13 |
| | cutepdf for example | 20:12.38 |
| | it includes a bundled copy of ghostscript that runs on their machine | 20:12.50 |
| | I think even redmon can go straight to pdf | 20:14.13 |
| whoami_ | non malheureusement | 20:15.07 |
| Gigs- | well there is no need to go to a server anyway | 20:15.42 |
| | at least not as PS, you can always send the PDF to a server | 20:16.32 |
| | that way all the clients do their own rendering and speed is not a problem | 20:16.48 |
| whoami_ | the purpose is to have a pdf file on my server (for my personal needs) | 20:16.58 |
| Gigs- | yeah, I would still render it on the client as they print and then upload the pdf to the server | 20:18.24 |
| | especially if you are having speed issues on the server | 20:18.37 |
| | raaaayyyy | 20:18.55 |
| whoami_ | because if the generation of pdf froze programs for several minutes when the pdf are dozens of pages | 20:19.03 |
| Gigs- | ghoscript really doesn't do parallel | 20:20.10 |
| | if you only can handle one at a time you need to redesign your program to be able to run more than one copy of ghostscript | 20:20.33 |
| | or install gs on all the clients and rendering it there first | 20:21.07 |
| whoami_ | I do not understand what you want to do or how or why | 20:22.09 |
| | there already GS on my clients | 20:22.39 |
| Gigs- | so it is the client that is locking up then | 20:22.59 |
| | I thought you had the opposite problem | 20:23.18 |
| | yes just send the PS to the server and run ghostscript there | 20:23.36 |
| whoami_ | It's not the server but the customers who froze when pdf is too large | 20:24.20 |
| | it is possible to generate ps file from redmon ? | 20:26.51 |
| Gigs- | yes but it will take just as long | 20:27.09 |
| | set up your server as a print server and use a basic driver on the windows side | 20:28.20 |
| | either PCL or PS | 20:28.27 |
| | if you use PCL you will need to use ghostpcl | 20:30.03 |
| | it will be faster to use a native driver and pretend your server is a standard print server from the client side | 20:31.34 |
| whoami_ | but will not print secure (The server is on internet) | 20:32.23 |
| Gigs- | oh, I don't know then. | 20:32.44 |
| | I would look at CUPS details if the server is linux | 20:34.55 |
| | they can probably help you more | 20:35.09 |
| whoami_ | customers are on windows so I would have to fight more with samba | 20:36.37 |
| Gigs- | no from the client perspective it would be a normal print server | 20:36.54 |
| whoami_ | no from the server | 20:38.15 |
| Gigs- | https://wiki.archlinux.org/index.php/CUPS_printer_sharing#Between_GNU.2FLinux_and_Windows | 20:38.26 |
| | oh the server isn't linux then, well, get another server :) | 20:38.52 |
| whoami_ | no but I do not want to use cups | 20:39.12 |
| | no it's a linux server | 20:39.42 |
| | but I think you involved my problem too :) | 20:41.18 |
| | thank you for the help I would spend tomorrow thank you | 20:45.30 |
| user123 | Hi Guys, can anybody provide commercial licensing fees for Ghostscript and muPDF? | 22:10.09 |
| tor7 | user123: mail sales@artifex.com to enquire about licensing | 22:31.11 |
| user123 | Thanks tor7, i did. twice. no response. | 22:31.58 |
| Robin_Watts | user123: Mail them again, and copy me (robin.watts@artifex.com) in and I'll make sure it gets through. | 22:53.03 |
| user123 | Thanks Robin. | 22:54.16 |
| Robin_Watts | user123: Scott just got the mail. | 23:12.19 |
| | He should respond pretty quick. | 23:12.25 |
| | He'll send you a huge list of questions, and just answer them as best you can - the more he understands what you want to do, the more he can tailor the quote to your needs. | 23:13.00 |
| user123 | Great. Thanks for your help. | 23:14.15 |
| Robin_Watts | no worries. | 23:14.25 |
| | ray_laptop: Hey | 23:26.11 |
| | I've run myself into a bit of a dead end here. | 23:26.37 |
| SpNg | I'm having some rough output along the edges when going from eps -> pngalpha. I have set the text and graphic alpha bits to 4. Are there any other anti aliasing optimizations I can do? | 23:28.00 |
| Robin_Watts | SpNG: You're probably hitting the limits of what pngalpha can do. In particular stuff plotted through clip regions may not be antialiased well. | 23:29.00 |
| | What res are you trying to get out? | 23:29.12 |
| SpNg | 300 x 300 | 23:29.19 |
| Robin_Watts | Try: using -r900 -dDownScaleFactor=9 -o out.png -sDEVICE=png16m | 23:29.50 |
| | Try: using -r900 -dDownScaleFactor=3 -o out.png -sDEVICE=png16m | 23:29.55 |
| | sorry. | 23:29.57 |
| | the latter one. | 23:30.01 |
| SpNg | can I get transparency with that output? | 23:30.08 |
| | gs -dEPSFitPage -g300x300 -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pngalpha -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -r600 -sOutputFile=out.png in.eps | 23:30.46 |
| | that is the command I'm currently using. I will add the DownScaleFactor | 23:30.57 |
| | and increase -r | 23:31.03 |
| Robin_Watts | never tried DownScaleFactor with pngalpha. Not sure. | 23:31.18 |
| | Trying it now. | 23:31.21 |
| | There is no point in using the AlphaBits with the downscaler. | 23:31.44 |
| | ok, I don't think DownScaleFactor works with pngalpha | 23:32.34 |
| SpNg | hmm yeah the results are not better | 23:33.29 |
| | is my best option to output to a larger file then use another program to resize? | 23:33.45 |
| Robin_Watts | SpNg: Try it and see if it gives you the results you need. | 23:34.15 |
| SpNg | Robin_Watts: I have tested it, and I can get good results, just one more moving piece. I was hoping to use GS to go from eps to raster each time | 23:34.51 |
| Robin_Watts | SpNg: Are you building your own gs ? | 23:38.14 |
| SpNg | Robin_Watts: haha, no way. I just love GS. The more I learn about it, the more I want to use it. | 23:39.01 |
| | I'm doing a bunch of work with EPS files | 23:39.10 |
| Robin_Watts | So you're not building it from source? | 23:39.17 |
| ray_laptop | Robin_Watts: were you talking to me about your "dead end" (head or bottom) | 23:39.45 |
| SpNg | Robin_Watts: yes I'm compiling from source | 23:39.59 |
| Robin_Watts | ray_laptop: Yeah. This postprocess thing had me worried. | 23:40.20 |
| | I think I may see a way through now. | 23:40.31 |
| ray_laptop | SpNg: if you are starting with eps, you may want to use -dEPSCrop or -dEPSFitPage | 23:41.04 |
| Robin_Watts | The problem is if devices start calling getbits rather than the prn_getbits entries, we might get strange results. | 23:41.15 |
| | but I think that's a reasonable limitation. | 23:41.26 |
| ray_laptop | SpNg: nm. I just saw you have that | 23:41.31 |
| SpNg | ray_laptop: yeah I'm using that right now. | 23:41.35 |
| | ray_laptop: yeah, I'm just trying to increase the output quality on smaller png and jpg rasters from EPS. | 23:42.29 |
| | any suggestions on resizing software? I have seen ImageMagic, netpbm and GraphicsMagic | 23:42.51 |
| Robin_Watts | SpNg: I'm just looking to see if I can find a quick solution to do it all in 1. | 23:43.43 |
| SpNg | Robin_Watts: Thank you. I really appreciate the help! | 23:44.44 |
| ray_laptop | SpNg: as Robin_Watts pointed out -dGraphicsAlphaBits=4 -dTextAlphaBits=4 are the best we can do. We only do box filter for those, however, not BiCubic | 23:45.10 |
| Robin_Watts | ray_laptop: I suspect mail going to sales@artifex.com is intermittently going wrong. | 23:45.20 |
| | s/wrong/missing/ | 23:45.34 |
| ray_laptop | the raster image postprocessing would allow you to use BiCubic or Gaussian or whatever | 23:45.49 |
| Robin_Watts | We've had 3 occasions of people coming on here saying that scott hasn't replied, and when I get the mail resent with me copied in, it gets through fine. | 23:46.01 |
| ray_laptop | Robin_Watts: Maybe Scott gets so much spam that he ignores it | 23:46.21 |
| | I'll ask him | 23:46.31 |
| Robin_Watts | He claims never to have seen them. | 23:46.31 |
| | He might be contacting you :) | 23:46.37 |
| SpNg | ray_laptop: ok good to know | 23:46.44 |
| ray_laptop | Robin_Watts: don't hesitate to give out his direct email. Also, he gets support@artifex.com email now (AFAIK), so cc support on your response to a potential | 23:47.39 |
| | Robin_Watts: what are your concerns with the post_process callout ? | 23:48.40 |
| Robin_Watts | ray_laptop: Leave it with me. I think I'm happier now. | 23:49.44 |
| | If I'm still not happy by the time you arrive tomorrow, we'll discuss it then. | 23:50.00 |
| ray_laptop | Robin_Watts: I gave the "destination" issue some thought and have sketched out a 'buffer manager' framework for the resutls | 23:50.17 |
| | Robin_Watts: something we could use in an example implementation that lets us point out what would be needed (locking, etc) and would allow parallel PNG or JPEG or whatever | 23:51.39 |
| Robin_Watts | Can't do parallel PNG or JPEG without blocking to ensure the processing is 'in order'. | 23:52.24 |
| ray_laptop | by 'sketch', I mean a mental picture. Nothing on e-paper yet. | 23:52.26 |
| Robin_Watts | Each band in a PNG would need to be compressed following on from the last one. Can't restart zlib. | 23:53.01 |
| ray_laptop | Robin_Watts: OK. Well, maybe parallel TIFF (band == StripSize) | 23:53.25 |
| Robin_Watts | And unless we start using restart intervals in JPEG, it's a continuous bitstream too :( | 23:53.33 |
| ray_laptop | cust 531 uses TIFF anyway, so it's a good "example" | 23:55.01 |
| | gotta keep the whales happy ;-) | 23:55.28 |
| Robin_Watts | SpNg: This isn't working out trivially. Try me again in about 15 hours time. I must go to bed now :) | 23:59.02 |
| | Forward 1 day (to 2013/10/16)>>> | |
IRC Logs