| <<<Back 1 day (to 2013/11/18) | 2013/11/19 |
ray_laptop | Robin_Watts: Mine isn't until next Monday | 00:03.41 |
| Robin_Watts: when is yours (You haven't had so many that you've forgotten when, like some of us ;-) ) | 00:04.15 |
Robin_Watts | Wednesday, I think. | 00:04.30 |
| But public observance of it will be on saturday :) | 00:04.52 |
ray_laptop | Robin_Watts: ask Helen. She probably rememebers :-) | 00:04.57 |
Robin_Watts | I'm married. There is only 1 birthday I have to remember now. | 00:05.34 |
ray_laptop | Robin_Watts: Right. Because mine is near Thanksgiving, I usually have the public recognition on that day | 00:05.51 |
| Robin_Watts: and anniversary !!!! | 00:06.07 |
Robin_Watts | Helens birthday and our anniversary are only 2 days apart. I planned well. | 00:06.31 |
ray_laptop | Robin_Watts: well done, dude! | 00:06.55 |
| My dad did similarly. Their anniversary is a week before her birthday, and a week after that is Xmas | 00:08.27 |
| it does present a strain on the budget at that time of the year, however | 00:09.05 |
| Then I came along a at the end of November and my younger sister 1 week later :-0 | 00:09.45 |
Robin_Watts | Is your dads birthday in February? :) | 00:10.25 |
Micha` | (ahahah) | 00:11.18 |
ray_laptop | My dad's birthday is near the end of May (four days from my middle sister's) | 00:11.27 |
Robin_Watts | So, at what point do we think that 801 have had long enough to complain about psdcmykog? | 00:11.31 |
| I guess if we haven't heard back from them by the meeting tomorrow I'll commit it. | 00:12.20 |
| Then I can simplify 801s device some more. | 00:12.41 |
ray_laptop | Robin_Watts: I think that they've responded to other issues, and haven't even commented on the psdcmykog part, and I didn't expect them to, so I AFAIC commit! | 00:12.55 |
| AFAIAC | 00:13.18 |
Robin_Watts | ray_laptop: At this point it costs me nothing to give them another night, cos I'm going to bed in a mo. | 00:13.19 |
ray_laptop | Robin_Watts: sleep well. Mvrhel is probably nodding off about now, too | 00:13.44 |
Robin_Watts | mvrhel will be getting up about now, I think. Or should be getting up about now. He's probably been awake for hours. | 00:14.19 |
ray_laptop | and there is no rush on the commit | 00:14.30 |
Robin_Watts | actually, I've pushed the psdcmykog branch to my repo | 00:15.35 |
| mvrhel_laptop: If you read the logs, and you're bored, I'd be grateful for any comments you might have on the rejigging I've done of the psd device. | 00:16.11 |
| ray_laptop: Likewise ^ | 00:16.16 |
ray_laptop | Robin_Watts: OK. | 00:16.24 |
Robin_Watts | ray_laptop: I just put a fix on the customer branch so NO_OUTPUT really does produce no output. | 00:49.07 |
ray_laptop | Robin_Watts: (for the logs). Thanks for the ~fix~ I doubt writing the headers for the 4 files would really affect the timing, but it _is_ cleaner. | 06:00.53 |
| Robin_Watts: (for the logs) Let me know if you see anything with what I sent / (pushed to your private repo) | 06:02.17 |
paulgardiner | Micha`: Are you around? | 10:15.10 |
Micha` | paulgardiner: Gooood morning! | 10:50.45 |
| Or whatever 11:50 is supposed to be called. | 10:50.52 |
| Good ante-noon. | 10:51.17 |
kens | ante meridian, or just morning :-) | 10:51.40 |
Micha` | Morning at 11:50 would convey the fact that I woke up late. Oh the shame. | 10:52.24 |
paulgardiner | Hi. I read some your comments from the other day. | 10:52.31 |
Micha` | I comment a lot. Was it about the fact that 9.11 related things will always be "too soon"? I was kind of proud of this one. | 10:53.25 |
paulgardiner | You said something about separate display lists for annotations and the rest of the page | 10:53.28 |
Micha` | Ah yeah, yes. So you see, there is one peculiar annotation type (AFAICS) when it comes to the order of things being drawn. | 10:54.04 |
| Highlighting is inherently supposed to be drawn first, and before the text. | 10:54.22 |
paulgardiner | Oh really?! I thought it was supposed to look like the result of a highlight pen | 10:55.24 |
Micha` | And this is what MuPDF does (in the lib and in the apps). | 10:55.48 |
| However, none of the other app do the same, it seems. | 10:56.00 |
| As a result, some annotating apps specify the alpha to be 1. | 10:56.18 |
| ...thinking, quite legitimately, that it'll be drawn behind the text. | 10:56.43 |
paulgardiner | Just tried Abobe reader on Windows and I do see what you suggest | 10:56.53 |
Micha` | When the library is tweaked to take into account highlight colors, it thus fails miserably. | 10:57.13 |
| By the way, in one of your bug report, you mention that MuPDF allows for arbitrary colors in text annotations. As I see this, their value are hardcoded, right? | 10:57.50 |
paulgardiner | At the moment yes. Hardcoded in the apps but not in the library interfaces | 10:58.16 |
Micha` | So my first step was to read those values, and this is when I realized the problem with highlighting. | 10:58.26 |
| Well, I'm not sure about that Paul. | 10:58.38 |
| Isn't the job of pdf_update_text_markup_appearance to read the color/alpha ? | 10:59.11 |
paulgardiner | How things are at the moment yes. Does it not? | 10:59.35 |
Micha` | Therein they are hardcoded. | 10:59.43 |
| I had to add a few lines to read C and CA. | 11:00.25 |
paulgardiner | There seems to be both an update and a set method | 11:00.51 |
| The "set" method takes color and alpha | 11:01.12 |
| Oh yeah. I remember. | 11:01.43 |
Micha` | Right-oh, but the set is only called by the update. | 11:01.49 |
| (These are awfully confusing naming, IMHO) | 11:02.22 |
paulgardiner | Suggestions for alternatives would be gratefully received. | 11:03.17 |
| But anyway, We could, as a temporary solution, take the color from the annot dict, but hardwire alpha 0.5 for highlight. | 11:04.39 |
Micha` | Well, if we're willing to actually read color/alpha, we should do something about highlighting... | 11:04.49 |
| Yes, but is it really necessary to have a temporary solution :-) | 11:05.12 |
| We have several possibilities: | 11:05.23 |
paulgardiner | I'm not sure what other apps are doing. Are they still generating an appearance stream? Do they special-case the rendering of highlight annotation appearance streams, drawing just those before the other page content? | 11:05.56 |
Micha` | Wait a sec, I'll check poppler. | 11:06.15 |
paulgardiner | What happens if one creates a hightlight in adobe reader and then views the page in MuPDF? | 11:06.57 |
| Is an appearance stream picked up which completely overwrites the text? | 11:07.21 |
Micha` | I fail to create annotations with adobe; I used okular. | 11:07.55 |
paulgardiner | Or does adobe reader not generate one (its being a special case) and MuPDF generates its own? | 11:07.59 |
Micha` | But really, I'd think that the appearance stream of the annot is drawn behind the text. | 11:08.30 |
paulgardiner | Perhaps annotations should always be drawn over the content and adobe reader avoids generating one for highlight so that it can place the highlight below the text, but not break the rules. | 11:09.51 |
| MuPDF displayed annotation appearance streams long before any support for adding annoations existed, and I am not aware of any bug reports for highlighs obscuring text, so I'd guess apps that placed the highlight under the text were not generating appearance streams, or at least not saving them to the file. | 11:13.21 |
Micha` | Is MuPDF respecting the appearance stream of markup annotations? | 11:15.12 |
paulgardiner | I believe so. | 11:16.07 |
| Hmmm! I just highlighted some text with android version of Adobe Reader and the result display correctly in MuPDF. | 11:16.53 |
| Perhaps annotations have an under/over flag or something like that | 11:17.17 |
Micha` | Or just a blend type. | 11:18.45 |
| So you're saying that Adobe Reader creates an appearance stream, and that MuPDF reads it ok, displaying it behind the text, right? | 11:19.22 |
paulgardiner | Yeah, I wondered that, but it could red text on a blue background. Wouldn't it be hard with a blend type? | 11:19.31 |
| Micha`: yes | 11:19.40 |
| No | 11:19.45 |
| actually | 11:19.49 |
| I've saying that Adobe Reader puts something in the file that MuPDF displays correctly. It might be an appearance stream, but if it is, there must be some sort of over/under flag or a special blending | 11:20.40 |
| I'd need to analyse the file | 11:20.59 |
| Thinking more on it, I susppect it isn't an appearance stream because the android app explicitly keeps separate display lists for the page and annotations, then always drawing the annotations after the other content | 11:23.40 |
| Whatever adobe reader has created has to be in the main content, I'm pretty sure. | 11:24.08 |
Micha` | What I understand from Poppler is that it discards the appearance stream of any highlight annotation, then creates a new one with a Multiply blend type. | 11:26.12 |
| Maybe that's the only secret; multiply blend type. | 11:26.52 |
paulgardiner | Oh. Could be. Multiply would do it for black on white | 11:27.18 |
| What happens with colored text and backgrounds? | 11:27.42 |
| I also wonder what abobe reader does? I'd imagine we'd want to align areselves with adobe more than poppler | 11:29.07 |
| :-) ourselves I mean | 11:29.32 |
Micha` | So! With a blue background, black and some green text and a yellow annotation, we end up with... | 11:32.52 |
paulgardiner | I'd be very pleased if it was simply the use of Multiply. That's a nice simple solution. | 11:32.52 |
Micha` | A nightmare for colorblind people. | 11:33.00 |
paulgardiner | Does adobe match poppler? | 11:33.16 |
Micha` | So we end up with the highlighting being black in both Adobe and Poppler. Hence both use multiply. | 11:33.35 |
| Let's do a quick victory dance move. | 11:33.48 |
paulgardiner | Excellent. | 11:33.52 |
Micha` | Aaaand it's gone. | 11:33.54 |
| What I don't get is why Poppler discards the appearance stream of highlight annots. | 11:34.29 |
paulgardiner | Apparently adobe reader often discards and regenerates appearance streams too. | 11:35.46 |
Micha` | And FYI, Poppler draws underline, squiggly, and highlight with Multiply, but only discards highlight's appearance streams. | 11:36.08 |
paulgardiner | So we could add a function pdf_set_markup_annot_color (or possibly just pdf_set_annot_color, seeing as the color is stored in a place not specific to markup AFAIK). | 11:36.51 |
Micha` | Right. | 11:37.07 |
paulgardiner | Then pdf_update_markup_appearance_stream could get the color from the dict and use multiply. | 11:37.19 |
| The appearance streams for annotations are generated via the pdf_write device: there might be some fiddling needed to get the multiply option in. | 11:38.15 |
| Presumably our device interface supports the setting of that. | 11:38.38 |
Micha` | Yes, I do believe pdf-interpret knows about BM at least. | 11:40.39 |
paulgardiner | Yes, but the pdf-write device may possibly not handle it yet. Should be easy to do anyway. | 11:41.38 |
Micha` | Shouldn't pdf_write be agnostic to which blend type it's given? | 11:42.35 |
Robin_Watts | paulgardiner: Setting a blend mode probably requires a group to be created. | 11:42.47 |
Micha` | And just blindly store it? | 11:42.53 |
Robin_Watts | Or at least an extstate dictionary. | 11:42.53 |
| which means adding such things to the resources. | 11:43.13 |
| not sure that's coded for in pdfwrite. | 11:43.22 |
paulgardiner | Robin_Watts: oh okay, but pdf-write already has to do similar things, so it shouldn't need a restructuring I'd have thought. | 11:43.59 |
Robin_Watts | A restructuring, no. Some work, possibly. | 11:44.16 |
Micha` | When a new form is created, such as an appearance stream (it is a form, right?), I think a group is automagically created if none fit the given specification. | 11:45.52 |
| That's part of the job of pdf_dev_new_form, I believe. | 11:46.06 |
| Am I missing something? | 11:46.26 |
paulgardiner | Not sure. We can look at what Adobe Reader creates, in any case. | 11:54.54 |
Micha` | Sure can. Ok, I'll have a more in-depth look later, around the evening. | 11:56.33 |
paulgardiner | tor7: Hi. I have the addition of markup working on iOS. There's a commit that needs looking over on paul/master | 11:57.42 |
Micha` | Oh, by the way, Robin directed me to you w.r.t. this old question (18/10): When the appearance stream of the Ink annotation is updated to mimick the InkList, any curve goes through a rather deep bezier-recursion before being added to the stream. At the end, each segment is itself stored in the stream as a very short bezier curve (using the `c` operator). Is there any reason to think that a PDF reader is so bad at d | 11:59.31 |
| rawing curves that they need to be pre-bezier'ed for it? | 11:59.31 |
| If you have a second to explain, I'll happily read that when I'm back :-) | 11:59.48 |
paulgardiner | Micha`: As far as I'm aware, we don't perform a deep recursion. We just link the sequence of points input by the users dragged finger with bezier curves. The calculations are just to ensure each the end of each curve abuts correctly with the beginning of the next. | 12:10.58 |
Micha` | (Well, lunch was much quicker than expected) | 12:12.37 |
| paulgardiner: Boy! I can't recall at ALL what I was trying to ask with this question. I'll have to go through my doodles to find the relevant PDF. I thought at one point that the InkList of an annotation got Bezier-recursed in the AP. Not the case, it seems. | 12:36.10 |
| Most probably I thought that in a drunken stupor while doing crack or something. | 12:36.51 |
paulgardiner | That bit of code is certainly complicated enough to misunderstand if looking through it quickly. | 12:38.11 |
Micha` | Couldn't agree more. | 12:40.17 |
| I got lost quite a few times, wandering between pdf-interpret, list-device, pdf-write, pdf-appearance, and illegal drugs. | 12:41.08 |
Rikin | hi | 14:02.15 |
ghostbot | niihau | 14:02.15 |
Rikin | i want to make wraper class for direct print to printer in C# can any help me | 14:03.36 |
| using ghostscript | 14:04.01 |
kens | Rikin : if you have specific questions then we can try to answer them, vague questions, not so much | 14:08.17 |
| You may like to look at GhostscriptSharp: | 14:11.08 |
| http://mattephraim.com/blog/2009/01/06/a-simple-c-wrapper-for-ghostscript/ | 14:11.08 |
| and also Ghostscript.Net: | 14:11.23 |
| http://ghostscriptnet.codeplex.com/ | 14:11.23 |
Rikin | i want to print PDF files to printer withou user interaction. | 14:11.40 |
kens | Rikin : then use the mswinpr2 device to drive the printer, you can do this from the command line | 14:12.47 |
Rikin | k thks for reply... let me check links | 14:13.34 |
henrys | kens each time I go through the agenda I bump into the dash problem - last the difficult was in pdfwrite but if the dash count is high just fall back to gx_default_stroke_path(). | 14:16.42 |
| s/diffcult/difficulty | 14:17.02 |
kens | henrys we have a dash imit in 3 places. One is pdfwrite,one is the interpreter and oneis the clist. | 14:17.21 |
| the clist is not a problem | 14:17.38 |
| THe other 2 I still intend to tackle, but I've been kind of buys. Is this more important njow ? | 14:18.00 |
henrys | kens:no, you just said last that pdfwrite would be non trivial and I thought that was a trivial fix. That's all. | 14:18.55 |
kens2 | sorry, connection hiccuped | 14:20.13 |
| The only difficulty with pdfwrite is that it needs the dash array to turn into malloc'ed memory so its all back to garbage collection and stuff | 14:20.42 |
| I mihgt have a bash at it on one of the flights | 14:21.16 |
henrys | 1) ubuntu upgrade 2) reboot 3) boom | 14:56.20 |
kens2 | Hmm isn't that supposed ot be a Windows sequence ? | 14:56.38 |
henrys | they are converging | 14:56.53 |
Robin_Watts | henrys: Do we consider that 801 have had time enough to complain about psdcmykog ? | 15:05.02 |
henrys | I do | 15:05.54 |
Robin_Watts | And we're not expecting to see mvrhel here for the meeting? | 15:06.32 |
kens2 | I wouldn't think so | 15:06.58 |
henrys | Robin_Watts: no | 15:07.11 |
kens2 | THough I've had a couple of mails from him | 15:07.12 |
Robin_Watts | OK, I shall go ahead and unleash my changes then. | 15:07.27 |
kens2 | Cry Havoc.... | 15:07.40 |
henrys | so to fix my ubuntu upgrade I have to reboot single user - mount the root filesystem with write permission. And comment out a line in /lib/udev/rules.d/60-persistent-storage.rules and reboot using vi or some other terminal program. This is not a good experience for non technical users. | 15:13.15 |
kens2 | Or even for technical ones | 15:14.16 |
Robin_Watts | non masochistic ones, at least. | 15:14.48 |
henrys | this toronto mayor is really something - I can see a drinking problem or maybe pot - but smoking crack cocaine ! | 15:23.21 |
kens2 | was ont the radio this morning, what a hoot | 15:23.38 |
| Mind you, we've just had the chairman of a bank caught on undercover camera trying to buy crack | 15:27.37 |
henrys | I imagine these guys have the money and connections to get really good pharmaceutical, why screw with that stuff? | 15:28.58 |
| just about meeting time | 15:29.35 |
kens2 | Well, our one seems to be something of an idiot. He turns out not to have an bamking qwualifications, not even experience | 15:29.37 |
henrys | chrisl:I've been told urw response is imminent but that's all I got | 15:29.59 |
| from the agenda we still have a log of unclaimed support bugs⦠have a look and I will too. | 15:31.03 |
| s/log/lot | 15:31.12 |
| Robin_Watts: so can you help marcosw_ set up this device for testing? Is it simply a matter of plugging it in? | 15:31.59 |
Robin_Watts | henrys: Yes. | 15:32.08 |
kens2 | Hmm, the dashboard isn't working for me, can't get to the aganda | 15:32.15 |
marcosw_ | which device are we discussion? | 15:32.22 |
Robin_Watts | psdcmykog | 15:32.29 |
marcosw_ | ^ion^ing | 15:32.30 |
kens2 | switches to chrome | 15:32.48 |
henrys | we should wait for ray but I wanted to talk about customer coverage while in maui. What are your dates marcosw_? | 15:33.17 |
kens2 | I returned at least one of the 'unclaimed' bugs because I don't think its properly specified | 15:33.52 |
marcosw_ | I'm arrivingThursday and will be there until Monday. | 15:33.52 |
kens2 | Hmm, one of them I need to close I think | 15:34.27 |
henrys | marcosw_:okay then perhaps we don't really have an issue. I thought you were staying longer | 15:34.40 |
marcosw_ | the only day that will be an issue is Friday, but I think most of us are out then :-) | 15:35.19 |
henrys | marcosw_: I don't think there is a problem - I assumed you were going to be going for a week like most of us. | 15:36.41 |
| kens2: okay marcosw_ and I will review all support also. | 15:37.38 |
| Robin_Watts: and including that device will automatically test process_page and everything? | 15:38.04 |
kens2 | I put a couple back to Marcosw after looking at them. One was to retest, the other looked ocverly braod | 15:38.09 |
Robin_Watts | henrys: Yes. | 15:38.16 |
henrys | Robin_Watts: should it be part of the MT testing? | 15:38.19 |
Robin_Watts | Yes. | 15:38.25 |
| ideally. | 15:38.28 |
henrys | marcosw_: are you good with adding that to the nightly? | 15:39.10 |
Robin_Watts | Also, it would be good if Marcos could do a check of the results. | 15:39.26 |
ray_laptop | iirc, the MT testing also tests -dBGPrint=true, right ? | 15:39.40 |
henrys | ray_laptop:you made a comment in the /tmp file bug that it might be fixed. Is it? | 15:40.30 |
Robin_Watts | The psdcmykog device scales everything down to 50%, so any automated 'visual' testing would need to take that into account. | 15:40.45 |
henrys | ray_laptop: processing the agenda in advance of the meeting | 15:40.47 |
marcosw_ | henrys: I'll add psdcmykog to the weekly and night, the weekly will cover multi-threaded testing | 15:40.52 |
ray_laptop | Robin_Watts: we discussed first committing *without* the verify, then after a baseline is collected, enabling the 'verify' that marks pages that get the color_usage wrong | 15:41.17 |
henrys | paulgardiner: how's iOS? | 15:41.23 |
Robin_Watts | ray_laptop: I've not added the verify stuff in yet. | 15:41.40 |
ray_laptop | Robin_Watts: great. adding it (or something like it) afterwards will then let us spot problems | 15:42.14 |
Robin_Watts | ray_laptop: indeed. | 15:42.23 |
henrys | ray_laptop: what are your maui days? I'm concerned about 801 coverage if you, Robin and I have the same days. | 15:42.28 |
paulgardiner | henrys: still a way to go. I've nearly completed the annotation support, but I still have javascript integration and signatures to do. | 15:43.18 |
Robin_Watts | henrys: I suspect I'll be available to answer email. | 15:43.21 |
| paulgardiner: Did you see the email from Raed ? | 15:43.40 |
henrys | kens2: I bumped pdf/vt up into the regular agenda - needing a research volunteer. You are the logical person to take that one. But I don't know somebody else might be interested in learning about it. | 15:44.12 |
paulgardiner | Robin_Watts: yes. So do we want to add some sort of signature support also to Ghostscript? | 15:44.17 |
ray_laptop | henrys: with BGPrint and saved-pages both needing "persistent" clist files (and needing to close them), I don't see any way to have that work with 'delete on close' | 15:44.21 |
Robin_Watts | paulgardiner: He was talking about mupdf. | 15:44.30 |
kens2 | henrys I'm unconvinced by any requirement for PDF/VT. | 15:44.35 |
| Its been 'the next big thing' for at least hte last 10 years | 15:44.47 |
| But real on demand printers don't use it | 15:44.59 |
henrys | kens2: so am I but you said to add it to the agenda. Would you like me to remove it? | 15:45.19 |
kens2 | I don't remember saying to add it..... | 15:45.32 |
paulgardiner | Robin_Watts: oh okay. That fact passed me by somehow. I remember his being the customer that wanted gs on W8 | 15:45.45 |
kens2 | goldfish memory strikes again | 15:45.51 |
Robin_Watts | paulgardiner: He is mostly a gs customer, but used mupdf for some things like text extraction etc, IIRC. | 15:46.15 |
henrys | kens2: I told you at chicago I got a lot of questions about it and you said then go ahead might as well add it to the agenda. | 15:46.21 |
Robin_Watts | You might want to ask him exactly what he wants to do with it? | 15:46.31 |
kens2 | henrys I believe you, but I don;t remember it :-) | 15:46.38 |
paulgardiner | Robin_Watts: Okay will do | 15:46.40 |
kens2 | I'll go and read the spec again | 15:46.58 |
| You never know htey may have changed it | 15:47.06 |
henrys | kens2: okay we'll probably knock it off the agenda next meeting. It's a longstanding frequent visitor to the agenda ;-) | 15:47.38 |
kens2 | :-D | 15:47.47 |
henrys | ray_laptop: okay well can you fix the last comment in the bug? | 15:48.38 |
| Robin_Watts: any MS office news? | 15:49.30 |
tor7 | paulgardiner: your latest ios changes look reasonable. one thought though, with the word boundaries, might it be worthwhile to allow both selecting text inside quotes without also selecting the surrounding quotes and punctuation? | 15:49.33 |
ray_laptop | henrys: OK. Maybe somebody else has an idea for how we can make the clist files be persistent, but only sometimes. | 15:49.38 |
Robin_Watts | henrys: I spoke to the administrator this morning. | 15:49.42 |
henrys | Robin_Watts: I know you've been busy ... | 15:49.43 |
| chrisl: /tmp file ideas for ray_laptop | 15:50.01 |
Robin_Watts | There are 2 companies involved here, a UK one and a Maltese one. Both are in administration. | 15:50.15 |
paulgardiner | tor7: yeah, that would be worth doing sometime | 15:50.27 |
ray_laptop | we do know ahead of time when we will need persistent clist files (for BGPrint or saved-pages) | 15:50.38 |
henrys | Robin_Watts: sounds like a money laundering operation | 15:50.45 |
Robin_Watts | They are in the process of clarifying exactly where the IPR lives. This should all get signed off by the courts by the end of this week (next monday at latest) | 15:50.48 |
| henrys: No, the Channel island companies are the money laundering operation. | 15:51.02 |
| (note the lack of smileys) | 15:51.18 |
| So, come next week we should be in a position to know exactly where we stand, and to start talking about amounts etc. | 15:51.50 |
henrys | Robin_Watts: okay. | 15:52.28 |
| tor7:how's GL | 15:53.25 |
| ? | 15:53.26 |
tor7 | henrys: on ice while tackling SVG input. about to revive that and see if I can get image masking and working and a fallback for non-nvidia cards | 15:54.32 |
henrys | that's all I had for the meeting I did update the agenda a bit, have a look and see if it needs edits | 15:54.41 |
| read is asking for signatures. Interesting | 15:54.57 |
kens2 | ray_laptop : customer #396 emailed support with a bunch of PDF files and the source to a device today. Could you cast an eye over the device please ? I already replied with information about teh PDF files. At the moment I think I will wait to see what htey come back with. | 15:55.03 |
henrys | s/read/raed/ | 15:56.24 |
ray_laptop | kens2: having a look at it... | 15:57.04 |
kens2 | THanks | 15:57.09 |
marcosw_ | Robin_Watts: there isn't a psdcmykog device in devs.mak. What am I missing? | 15:57.58 |
Robin_Watts | marcosw_: When did you update ? | 15:58.18 |
marcosw_ | 5 minutes ago | 15:58.26 |
Robin_Watts | Is there a cmykog device there? | 15:58.35 |
marcosw_ | yup. | 15:59.04 |
Robin_Watts | That's the puppy. | 15:59.11 |
kens2 | devs.mak has it in the change log | 15:59.16 |
marcosw_ | right, so the psdcmykog device is called cmykog. any reason why the file format isn't included in the device name? | 15:59.46 |
Robin_Watts | No, the device is called psdcmykog (as in -sDEVICE=psdcmykog) | 16:00.21 |
henrys | bbiaw | 16:00.30 |
kens2 | fetches coffee, brb | 16:00.33 |
ray_laptop | kens2: YUCK! what a mess!!! | 16:01.41 |
Robin_Watts | ray_laptop: Did you see the main from 801 this morning? Complaining of DOS line endings ? | 16:02.07 |
ray_laptop | Robin_Watts: yes. I guess the easiest thing is for me to do a tarball as well (from the branch checkout on peeves) | 16:02.53 |
marcosw_ | Robin_Watts: it's early on the west coast, so maybe I'm just still asleep, but the psdcmykog device locks up for me, for example: | 16:04.21 |
| bin/gs -sDEVICE=psdcmykog -o test.psd -r72 ./examples/tiger.eps | 16:04.21 |
| it's been running for ~5 minutes now. | 16:04.38 |
Robin_Watts | ray_laptop: If we gave them a nosh account on casper, we could encourage them to check out the branch from git. | 16:04.59 |
ray_laptop | marcosw: that doesn't sound right | 16:05.05 |
Robin_Watts | marcosw: what platform ? | 16:05.16 |
kens2 | ray_laptop : I didn't really follow the device too well, and it seems to make calls to 'something else' which is not included. They did say they would send a complete set of source, but if you can see anything obvious, it would be good to mention it. | 16:05.17 |
marcosw_ | mac os x 10.8 | 16:05.25 |
| I can try it on linux | 16:05.37 |
Robin_Watts | testing now. | 16:06.04 |
ray_laptop | kens2: they have this external function 'rip_init' which sets up a bunch of statics. If they ever call that and expect the device to react, that won't work. | 16:06.15 |
kens2 | ray_laptop : I really don;t know what that function is supposed to do, though I did wonder | 16:06.43 |
ray_laptop | kens2: all of the s_init_* variables. | 16:06.43 |
kens2 | let me open the source again | 16:06.55 |
| ray_laptop : Yes, I was assuming (perhaps incorrectly) that this function was setup by their rip before opening the device.. I'm assuming that the rip only drives a single device and therefore never changes. Of course, I could be totaly wrong. | 16:08.25 |
marcosw_ | Robin_Watts: psdcmykog works fine on linux, so that's good enough to start running regressions. | 16:08.59 |
ray_laptop | kens2: they seem to have a device that they want to have all kinds of color modes (a'la cups), but they don't control it with device params, AFAICT | 16:09.03 |
chrisl | henrys: sorry, completely forgot about the "new" meeting time..... | 16:09.15 |
kens2 | ray_laptop : that could be, and it may well be that they would benefit from some words from you on the subject. THey do say they are 'mainly' printing black & white (with optional spots apparently) | 16:10.12 |
henrys | chrisl: no problem see above | 16:10.25 |
kens2 | It looks like CMYK is a planned future enhancement, so getting in now to explain what they *shoudl* do might be valuable | 16:10.50 |
chrisl | henrys: good news about URW..... I'm afraid I don't have suggestions about the tmp file situation - I've discussed it with Ray two or three times, and exhausted my ideas. I'll have another think, but I let's not hold our breath! | 16:12.11 |
ray_laptop | kens2: From this, I can't tell which mode is 'standard', but I see the DEFAULT_POLARITY is #defined as ADDITIVE and the DEFAULT_COLORSPACE is their variant on DeviceGray | 16:14.16 |
| chrisl: Ok, thanks. | 16:14.39 |
kens2 | I believe (from their email) that it should be working in DeviceGray | 16:14.43 |
| I may know better when they send a complete package I cna run | 16:14.59 |
kens2 | senses an open can of worms approaching | 16:15.34 |
ray_laptop | kens2: yes, I hear the herd of worms thundering toward us. | 16:16.12 |
Robin_Watts | marcosw: You are right. I should rename the device in the makefile to be psdcmykog | 16:18.38 |
| I will do that in just a mo, then I'll test it on macos. | 16:18.50 |
marcosw_ | Robin_Watts: okay. if you are fixing the devices/devs.mak file you should also add a $(arch_h) to fix parallel builds: | 16:19.54 |
| $(GLOBJ)gdevcmykog.$(OBJ) : $(DEVSRC)gdevcmykog.c $(gdevcmykog_h) $(arch_h) | 16:19.56 |
Robin_Watts | There are a couple of such things I need to do. | 16:20.17 |
marcosw_ | yeah, the cmykog.dev dependencies are probably wrong to, I think this is (more) correct: | 16:21.05 |
| $(DD)cmykog.dev : $(DD)page.dev $(cmykog_) $(GLD)page.dev $(GDEV) | 16:21.05 |
chrisl | page.dev twice? | 16:21.58 |
marcosw_ | oops, cut and paste error | 16:23.35 |
| how about: $(DEVS_MAK) $(cmykog_) $(GLD)page.dev $(GDEV) | 16:23.59 |
chrisl | Does it require devicen.dev ? | 16:26.01 |
marcosw_ | I was just going by the psdcmyk.dev dependencies. | 16:26.45 |
chrisl | I thought psdcmyk.dev would need devicen.dev - perhaps not...... | 16:27.28 |
marcosw_ | chrisl: wouldn't be the first missing dependency in our makefiles... | 16:28.02 |
ray_laptop | kens2: the first thing he's doing wrong is "Open file in Acrobat Reader 9.0 (Linux) take a screenshot (PNG file)" and then saying "100% black in Acrobat". He _should_ be saving it as a TIFF or PNG from Acrobat, and also tell us what his Acrobat settings are for ripping. | 16:28.38 |
chrisl | marcosw_: <sigh> very true | 16:28.49 |
kens2 | ray I did that in my reply | 16:28.57 |
ray_laptop | kens2: when I do that, the 'p2' file has 100% black for the "target", but all of the text is 85% | 16:29.42 |
| kens2: maybe I should read your reply. Just a sec | 16:29.56 |
kens2 | Basically the problem with most files is that they use/Separation /Black | 16:33.58 |
marcosw_ | Robin_Watts: is there an icc profile I need to use with the psdcmykog device? I'm not seeing anything in the orange or green planes when converting tiger.eps. | 16:34.08 |
kens2 | and DeviceGray does not support that separation | 16:34.11 |
Robin_Watts | marcosw_: Indeed, without a profile, you won't see anything on those planes. | 16:34.27 |
| mvrhel is doing me a profile that will be checked in at some point, together with an example file. | 16:34.41 |
| but for now, we can ignore them. | 16:34.54 |
marcosw_ | Robin_Watts: okay, I'll add the device as, when we get the profile and sample files it should be easy to enough to incorporate them into the nightly/weekly testing. I presume I only need to test at 300 dpi. Do we want both banding and page mode or is banding good enough? | 16:36.16 |
Robin_Watts | marcosw_: Let me fix some stuff first. | 16:36.37 |
| in particular it's name etc. | 16:36.41 |
marcosw_ | Robin_Watts: no problem, nothing will run until after midnight PST. | 16:37.48 |
ray_laptop | kens2: yes, and then the alternate colorspace is ICCBased, with a sampled Function for the tint transform | 16:37.53 |
Robin_Watts | s/it's/its/ | 16:38.24 |
kens2 | ray_laptop : yes, exactly right, so if we don't support /Seaparation /Black we get something grey | 16:39.27 |
ray_laptop | marcosw: for psdcmykog, IMHO, we want banding and page mode | 16:39.51 |
Robin_Watts | marcosw_: Any resolution will do, but given that we want banding/not, 300.0 and 300.1 seem reasonable ? | 16:41.32 |
ray_laptop | kens2: when I convert it to pnggray using gs, I get 91% which is darker than Acrobat, but still not 100% Black, | 16:43.10 |
| Robin_Watts: doing 72 dpi doesn't make much sense (the output will be 36 dpi) | 16:43.54 |
kens2 | ray_laptop : yeah, but basically that's beacus DeviceGray is not /Separation ?Black | 16:43.54 |
Robin_Watts | ray_laptop: Indeed. | 16:44.22 |
kens2 | So we always use the alternate | 16:44.25 |
Robin_Watts | ray_laptop: Once I've got this psdcmykog thing in, I'm going to have a hack at the 801 device again to remove all the boilerplate and simplify it. | 16:45.16 |
ray_laptop | kens2: exactly what color it maps to is up to the tint transform being processed through the ICC profile (which looks to be sRGB IEC61966-2.1 from HP) | 16:46.27 |
| Robin_Watts: boilerplate ? | 16:46.42 |
Robin_Watts | ray_laptop: There is lots of code in there that exists just to do devn colors. | 16:47.17 |
ray_laptop | Robin_Watts: Oh, OK. I can't recall. Did they say that they never want to do spot colorants ? | 16:47.51 |
Robin_Watts | Part of the refactoring I've just done on the psd{rgb,cmyk,cmykog} devices is to extract stuff into a more reusable form. | 16:48.11 |
kens2 | ray_laptop : yes, that's pretty much what I'm trying to get over to the customer | 16:48.16 |
Robin_Watts | The transformation I have in mind does not preclude the use of spot colorants. | 16:48.44 |
ray_laptop | Robin_Watts: right, so you are going to make use of that for their device as well ? | 16:49.03 |
kens2 | Hmm, I wonder if a quick hack to turn /Separation /Black into /DeviceGray would work :-) | 16:49.36 |
Robin_Watts | ray_laptop: That is my plan. | 16:49.38 |
ray_laptop | kens2: Do you mean altering the /Separation /Black cs in the PDF to have the alternate be DeviceGray ? The tint transform would have to invert in that case | 16:51.46 |
kens2 | ray_laptop : I mean defining a override setcolorspace | 16:52.00 |
ray_laptop | but of course that will work. | 16:52.01 |
kens2 | to tets for /Separation /Black and replace with /DeviceGray (inverted) | 16:52.18 |
ray_laptop | kens2: it definitely would need to invert | 16:52.50 |
kens2 | ray_laptop : yes, I'mjust wondering if it might be a quick solution to their problem | 16:53.04 |
ray_laptop | kens2: quick and *very* dirty. | 16:53.21 |
kens2 | :-D | 16:53.25 |
chrisl | It's a pretty common thing to do...... | 16:53.40 |
ray_laptop | kens2: how would you do it without needing to modify gs ? The PDF interpreter binds most operators such as setcolorspace | 16:54.18 |
kens2 | -dDELAYBIND ? | 16:54.37 |
Robin_Watts | henrys, marcosw, ray_laptop: How do we feel about the idea of giving customer 801 an account on casper? | 16:54.42 |
kens2 | Not sure at the moiment | 16:54.45 |
ray_laptop | kens2: and it certainly isn't something that we'd want standard. | 16:54.45 |
kens2 | Oh no definitely not | 16:54.52 |
Robin_Watts | We can set it to have no shell, but it would allow them to ssh in and git clone our private repo. | 16:55.17 |
ray_laptop | kens2: I'm not sure if DELAYBIND will work with the pdf_*.ps files, but go ahead and try it | 16:55.18 |
kens2 | I'll run a quick hack and see what happens | 16:55.23 |
ray_laptop | Robin_Watts: I have no heartburn over that, particularly since it would be 'read-only' for them | 16:56.07 |
Robin_Watts | ray_laptop: Well, no, it could be both read only and read write. | 16:56.34 |
| harder to make it read-only in fact, I think. | 16:56.59 |
ray_laptop | kens2: the problem appears to be the tint transform function used. I looked at the sample data and the last entry has values (RGB): 23 1F 20 -- Nowhere hear 0,0,0 | 17:01.05 |
kens2 | ray_laptop : yes, that is pretty much it. | 17:01.21 |
ray_laptop | kens2: do you want me to look any further at the files. | 17:01.51 |
kens2 | The 'problem' of course is that the customer's customer thinks its black, and if they runit to a CMYK device, it *is* black..... | 17:01.53 |
| ray_laptop : not really, just the device. I already analysed the PDF files, I'm going to wait and see what htey come back with on those. | 17:02.14 |
ray_laptop | kens2: as far as their device, I'll write up something with the problems that their approach has and send it to you | 17:02.24 |
kens2 | But I will play with overrriding setcolorspace | 17:02.25 |
| ray OK thanks | 17:02.32 |
ray_laptop | kens2: and feel free to take out anything I say that you think is too harsh :-) | 17:03.01 |
kens2 | :-D | 17:03.12 |
ray_laptop | starts the email: I've reviewed this stinking pile of .... | 17:03.38 |
kens2 | chrisl, do we not install lib etc with the Windows build ? My one here has it, but possibly I copied it manually | 17:04.06 |
chrisl | kens2: we install lib, but not Resource | 17:04.24 |
kens2 | Yes, I just realised that | 17:04.31 |
| Lookiong for the wrong file.... | 17:04.38 |
chrisl | It has been a topic of discussion - I remain concerned that if we install Resource, people may modify the files, and wonder why their changes have no effect | 17:05.24 |
kens2 | Agreed. I don't understand why his GSView has dependencies on that, mine doesn't seem to | 17:05.52 |
chrisl | No neither does mine - I still have 4.9, don't have 5.x, but I doubt that matters | 17:06.31 |
kens2 | Sounds like he's being an ass then | 17:06.52 |
ray_laptop | chrisl: IMHO, we should *not* install Resource since we have them in %rom, and they can always use their own Resource directory with -sGenericResourceDir= | 17:08.01 |
chrisl | Well, the only way I can see to make a gs installer install give that error is to "-I..../Resource/...." then we'll automagically set generic resource directory to that path | 17:08.01 |
kens2 | chrisl yes, I just closed it as 'worksforme' becaus eit does | 17:08.25 |
chrisl | ray_laptop: the complaint is that to get them, people have to download the entire source tree, just for the init files | 17:08.39 |
kens2 | ray_laptop : but if they odn;t have a copy of our resources, how can they add their own ? | 17:08.49 |
chrisl | kens2: well, it is your bug.... :-) | 17:08.57 |
kens2 | :-) Yep | 17:09.04 |
chrisl | <ahem> *was* your bug..... | 17:09.17 |
kens2 | THat makes 4 bugs I've closed today I think | 17:09.37 |
| And teh loon from teh US Marines last night | 17:10.00 |
ray_laptop | chrisl: they can grab subsets of the tree from git.ghostscript.com http://git.ghostscript.com/?p=ghostpdl.git;a=snapshot;h=4f25e8e14303fcd6f21fe32d864ade99ff27e68b;sf=tgz | 17:10.39 |
kens2 | Hmm that offers a 5Mb download for me | 17:11.18 |
chrisl | ray_laptop: I don't think that's a subset, I think that's the entire source tree | 17:11.58 |
ray_laptop | kens2: sorry. I didn't realize that the 'snapshot' when I was on the Resource 'tree' page was for the whole think | 17:12.01 |
| chrisl: right | 17:12.08 |
kens2 | Maybe we just need ot offer a 'resources.zip' or something | 17:12.37 |
ray_laptop | They can (painfully) pull in the Resources by pulling in all of the .raw files | 17:12.45 |
chrisl | kens2: I looked at that - it's quite hard to do without relying on zip! | 17:13.26 |
kens2 | Umm, yes.... | 17:13.43 |
ray_laptop | kens2: we can have a small .lib PS program that exports the %rom/Resource tree | 17:13.51 |
kens2 | Do you have to avoid zip ? | 17:13.54 |
| ray_laptop : yes, that would work I guess..... | 17:14.09 |
ray_laptop | that way all you need is to have gs installed :-) | 17:14.18 |
chrisl | kens2: one of the drivers for switching to nsis was not depending on zip. | 17:14.36 |
ray_laptop | chrisl: it wasn't .zip we wanted to avoid, but just winzipse | 17:15.02 |
kens2 | Well, If someone wants to install their own resources I don;t htink its unreasonable to expect a *little* abvility from them | 17:15.06 |
chrisl | ray_laptop: I though we wanted to get away from depending on a commercial application? | 17:15.45 |
ray_laptop | kens2: right. If they aren't smart enough to use gs to run the 'extract_Resource.ps', then they aren't smart enough to be mucking about with them | 17:15.57 |
kens2 | LOL according to the register, the BBC Radiophonic Workshop in Maaida Vale is a former Edwardian roller skating venue :-O | 17:16.09 |
chrisl | ray_laptop: would the PS to dump the init files work after the files have been combined, compacted and compressed? | 17:16.15 |
ray_laptop | chrisl: unzip is not commercial | 17:16.20 |
| chrisl: yes (no way to do otherwise) | 17:16.40 |
Robin_Watts | infozip is not commercial. | 17:17.08 |
ray_laptop | anyone that wants the original, commented, non-binary version can darn well download the full sources | 17:17.17 |
Robin_Watts | i.e. pkzip or winzip are commercial. zip is not. | 17:17.26 |
chrisl | Well, I'd rather not have an extra dependency in the release chain | 17:17.57 |
ray_laptop | chrisl: but the extracted files can still be replaced and/or supplemented | 17:18.31 |
kens2 | TIme for me to go, goodnight all | 17:18.34 |
ray_laptop | chrisl: let me throw together an extract_Resource.ps and you can tell me what you think. No extra dependencies or programs other than gs | 17:19.19 |
chrisl | ray_laptop: I thought we sacrificed the individual files for better compaction/compression - oh, and aren't several binary encoded, too? | 17:19.40 |
ray_laptop | chrisl: yes. just one gs_init.ps and it _does_ use binary. But as I said above. Anyone wanting to modify the Resource/Init contents has to know what they are doing and can get the sources | 17:20.37 |
| but for other Resource contents, doing things like adding to CIDFont or Font or IdiomSet, etc. (or replacing some of those files) is possible | 17:21.58 |
chrisl | ray_laptop: my original intention was to put "Resource" somewhere like a "not-used" directory, but that proved beyond my knowledge of nsis..... | 17:23.39 |
| I have to go..... | 17:39.23 |
| ray_laptop: (for the logs) if you have something you want me to look over, either stick it on a branch in your repo, or send me a e-mail | 17:40.02 |
ray_laptop | chrisl_: I guess my idea won't work. The PS file operator (as it is currently implemented) won't create directories. It probably could. | 18:43.04 |
| Since Adobe PS treats things as a flat file system, the / (or whatever the program thinks is a path separator) is just another character | 18:45.33 |
| so on real Adobe PS, one can do (mydir/somefile) (w) file and it will work | 18:46.21 |
pipitas | Hello all. Today I've a question about "planar" devices: I keep stumbling across that term in different Ghostscript resources (incl. this IRC channel's logs). | 18:56.20 |
| So what are "planar" devices? Can someone give a short description for me? | 18:56.26 |
Robin_Watts | pipitas: Sure. | 18:57.22 |
| Normally when gs renders internally, it does so in 'chunky' format. | 18:57.44 |
| That is, suppose you have an 8bit per component rgb device, the memory buffers will be RGBRGBRGBRGBRGB etc. | 18:58.09 |
| Sometimes what you really want is to get whole planes of R, then whole planes of G then whole planes of B. | 18:58.39 |
| RRRRRRRRRRR...GGGGGGGGGGG...BBBBBBBBBBB... | 18:58.49 |
| This latter format is known as planar format. | 18:59.00 |
| Does that help? | 18:59.04 |
pipitas | Robin_Watts: Yes, thanks | 18:59.45 |
ray_laptop | oh, great. I misspelled misspelling in a log message to correct a misspelling :-/ | 20:42.41 |
ray_laptop | should have called it a 'typo' | 20:43.12 |
marcosw | Robin_Watts: are you still about? | 21:19.05 |
Robin_Watts | marcosw: I am. | 21:19.13 |
marcosw | I saw you checked in the psdcmykog changes. Should I add it to the nightly/weekly regression? | 21:19.33 |
Robin_Watts | marcosw: Yes, I believe it is working correctly now. Thanks. | 21:20.07 |
| I've got to run for dinner - the boss is calling. | 21:20.22 |
| do you need me for anything else ? | 21:20.27 |
marcosw | for psdcmyk we test 72 dpi in page mode and 300 dpi in banded mode. I'll do the same for psdcmykog. | 21:20.34 |
| nope, I'm good. | 21:20.40 |
Robin_Watts | 72 will end up being 36. | 21:20.49 |
| but I don't suppose that matters. | 21:20.54 |
marcosw | no, since we aren't comparing to anything else but itslef. | 21:21.11 |
ray_laptop | marcosw: we want to include the psdcmykog device on the -dBGPrint=true -dNumRenderingThreads=? test as well, since that is how the customer will be running. | 21:31.34 |
| marcosw: and the 'process_page' is particularly "stressed" in these modes | 21:32.43 |
| (not to mention the CPU) :-) | 21:33.00 |
| bbiab | 21:33.16 |
Micha` | Robin_Watts: You mentioned something earlier about the need for an extgstate for having a blend mode... | 22:49.44 |
| This is what the PDF standard asks for indeed, so is there a reason why pdf-device.c puts the BM (blend mode) element in a transparency group dict? | 22:50.30 |
| (In pdf_dev_new_form) | 22:50.47 |
| paulgardiner: (Maybe you have an opinion on that?) | 22:56.33 |
| Creating an ExtGState instead of adding BM to the group works as intended; otherwise the blend mode is lost. | 23:07.59 |
| Welp, I'd better open a bug report then. | 23:49.17 |
Robin_Watts | Micha`: It's probably just a bug. | 23:54.00 |
| I don't remember ever writing the code to add stuff to the resources dictionary. | 23:54.23 |
Micha` | Well, you can have a look at http://bugs.ghostscript.com/show_bug.cgi?id=694794 ; I attached a fix proposal. | 23:55.05 |
| This is basically a copy/paste from a similar thing in pdf_dev_begin_mask. | 23:55.54 |
| This is probably not the way to proceed, but is a quick fix. | 23:56.39 |
| By which I mean that equivalent ExtGStates may be created, with only a BM set. And using num_smasks is definitely wrong. Meh, I should have refrained from proposing a fix, all things considered :-) | 23:59.52 |
| Forward 1 day (to 2013/11/20)>>> | |