| | <<<Back 1 day (to 2012/09/03) | 2012/09/04 |
| ray_laptop | cluster pushing the fix for mvrhel's clist_copy_planes issue as well as (I hope) Bug 693234. | 01:50.05 |
| tor8 | morning paulgardiner | 09:33.08 |
| paulgardiner | tor8: hi | 09:33.14 |
| tor8 | I rooted and installed android jelly bean on my galaxy tab last night | 09:33.38 |
| | the button background colors have changed yet again... | 09:33.53 |
| sebras | tor8: why don't we supply our own buttons completely? | 09:34.16 |
| | tor8: so we're independent of changes made by upstream I mean. | 09:34.36 |
| tor8 | sebras: so we can fit in with the system theme, I guess | 09:34.38 |
| sebras | sure, but this must be a problem for other apps too, how do they solve it? | 09:34.59 |
| tor8 | by using colorful icons, or custom sets for each version? | 09:35.18 |
| | or they all use completely custom buttons... | 09:37.00 |
| sebras | tor8: could it be the case that device vendors manipulate the button theme as well? for HTC sense, etc... | 09:41.14 |
| | tor8: if so then it makes it almost impossible to fix proper. | 09:41.35 |
| paulgardiner | tor8: in what way does it look wrong? Do we use the background color at the edge of the buttons? | 09:45.33 |
| tor8 | paulgardiner: our icons are white to look good on a dark button background | 09:45.59 |
| | but on jelly bean the button backgrounds are light gray | 09:46.14 |
| | we could set our own button colors I guess, I did try messing with that xml once | 09:46.45 |
| | didn't like the results though, but it may be worth trying again | 09:47.04 |
| paulgardiner | white with a black outline? | 09:47.32 |
| tor8 | paulgardiner: http://ghostscript.com/~tor/stuff/Screenshot_2012-09-04-11-48-15.png | 09:50.10 |
| paulgardiner | Any pattern in what the standard apps do? | 10:05.18 |
| | Robin_Watts, tor8: I've done the renaming and remerged master. The results on paulg/forms | 10:17.36 |
| chrisl | tor8: ping | 10:56.17 |
| tor8 | chrisl: pong | 10:56.54 |
| | paulgardiner: looking | 10:56.56 |
| chrisl | tor8: I made some changes to the jbig2dec stuff to handle building without configure on some slightly out of the ordinary systems - should I commit them to jbig2dec or ghostpdl, or both? | 10:58.11 |
| paulgardiner | tor8: one thing I should mention, while there are two separate builds on the forms branch, one with v8 and without, both versions include all the code in pdf_font.c. We might want to make some of that conditional too. | 10:59.10 |
| tor8 | chrisl: right. I think jbig2dec is the best place for now. or we can do the git-subtree switch today before you commit, and see how pulling/pushing between the two works. | 10:59.56 |
| | paulgardiner: because of size concerns? | 11:00.24 |
| paulgardiner | Yes. Not sure if it's an issue or not. But just thought I'd mention it in case it wasn't obvious that pdf_form.c was in both versions. | 11:01.41 |
| tor8 | pdf_font.c or pdf_form.c? | 11:02.01 |
| | paulgardiner: if the latter, I think having form support (with no-op javascript) in the base build is desirable | 11:02.30 |
| paulgardiner | :-) Oops. pdf_form.c | 11:03.08 |
| | Ok. Good. | 11:03.26 |
| chrisl | tor8: (sorry, doorbell) I'd prefer to get the changes in before we "activate" the git-subtree scheme, so we keep to the every commit builds policy. Problem is, (I just remembered) we need changes to the Ghostscript build, too | 11:06.03 |
| tor8 | chrisl: right. let's put them in both then. | 11:27.23 |
| | chrisl: oh, and remove .cvsignore from jbig2dec.git while you're at it | 11:27.46 |
| chrisl | tor8: okay, I'll do that later today, then - I have a feeling I haven't tested the latest changes on Windows, I should do that first.... | 11:28.06 |
| tor8 | chrisl: splitting commits from ghostpdl into jbig2dec.git requires the --onto <commit> argument, and takes a few minutes to run | 11:28.37 |
| | so going the other way from jbig2dec to ghostpdl will be easier in general | 11:29.06 |
| chrisl | Hmm, yes, but we can't make the ghostpdl/gs/jbig2dec folder read-only, can we? Whereas we could easily make the jbig2dec repos read-only for most of the world | 11:30.18 |
| tor8 | the git-subtree split command goes through all history and recreates the split commits from the root every time (with the same sha1 sums every run) | 11:30.20 |
| | chrisl: yeah. we could set up a job that runs once a day and splits out the ghostpdl/gs/jbig2dec directory and pushes to jbig2dec.git | 11:31.24 |
| | that's probably the easiest way to go | 11:31.48 |
| chrisl | tor8: I'm just concerned that unless we actually block "normal" commits to to the "client" one, someone, at some point will commit changes to the wrong repos | 11:32.39 |
| tor8 | mhmm. and moving to git submodules would prevent that, but given how much trouble some of us still get into with git ... you wouldn't want to deal with that | 11:34.34 |
| | chrisl: making /home/git/jbig2dec.git read-only except for the automatic script could work | 11:35.31 |
| | or hooks in /home/git/ghostpdl that checks for and rejects commits that touch gs/jbig2dec that aren't from git-subtree merge | 11:36.15 |
| | I think the former will be easier though | 11:36.32 |
| chrisl | Personally, I would prefer making /home/git/jbig2dec.git read-only - given that the majority of jbig2dec development is likely to be done in a ghostpdl tree | 11:37.14 |
| tor8 | chrisl: so we have consensus :) | 11:37.42 |
| chrisl | It would seem so - I wonder what we've missed ;-) | 11:38.06 |
| tor8 | chrisl: make the changes in ghostpdl and I'll cook up a script to put in cron | 11:38.18 |
| chrisl | tor8: okay, like I say, I'll commit them later today, if that's okay | 11:39.14 |
| tor8 | chrisl: sounds good. remind me to fix the script, I need to look over the mupdf forms merge now | 11:39.47 |
| chrisl | Okay-dokey | 11:40.06 |
| mvrhel | Hmm Bug 693300 is not a separation issues | 13:15.47 |
| Robin_Watts | mvrhel: Thanks for replying to Marti. | 13:20.43 |
| mvrhel | Robin_Watts: no problem. Hopefully the profile will help him determine what is right and wrong | 13:29.47 |
| Robin_Watts | I'm feeling useless here, because other than pointing and the diffs and saying "they aren't the same", I have no real clue how to follow up. | 13:30.19 |
| | s/and the/at the/ | 13:30.31 |
| mvrhel | Robin_Watts: I am likely of little help on this to Marti either though other than to give him the profile. He has all the color engines to compare amongst and decide what is "correct" in this likely corner case | 14:00.41 |
| tor8 | paulgardiner: I can't spot anything obviously bad about the paul/forms merge. I'll wait until Robin_Watts gives the ok signal then push to origin/master | 14:04.18 |
| Robin_Watts | had better look then. | 14:04.28 |
| paulgardiner | Ok thanks Tor | 14:05.24 |
| Robin_Watts | Well, there is very little to object to in the merge. I say go for it. | 14:06.35 |
| tor8 | Robin_Watts: keep an eye on the cluster, with a my luck it'll retest everything on the forms branch... | 14:11.31 |
| | oh, and maybe I should temporarily disable the mail hooks so kens doesn't complain ;) | 14:11.45 |
| Robin_Watts | So I should change the cluster to mujstest master rather than forms now. | 14:12.28 |
| mvrhel | now I see that Bug 693300 is a transparency issue. fun | 14:12.51 |
| tor8 | Robin_Watts: paulgardiner: pushed. and a regression queue two weeks long. | 14:13.32 |
| Robin_Watts | awesome :) | 14:13.51 |
| paulgardiner | hide under desk | 14:14.24 |
| mvrhel | whoa | 14:15.10 |
| | what is up with the cluster | 14:15.14 |
| Robin_Watts | Hmm. I just emptied the queue, but now I'm wondering if I should have. | 14:15.22 |
| | Might be better to actually let it run them all. | 14:15.33 |
| | Nah, let's go with the fast one. | 14:15.45 |
| | mvrhel: forms branch merged to master. | 14:15.53 |
| tor8 | Robin_Watts: if the cluster is stable, I have a handful of sebras patches to push | 14:25.25 |
| Robin_Watts | tor8: wait for it to settle down, please. | 14:25.40 |
| | I can't guarantee it won't suddenly explode again until it stops. | 14:26.01 |
| tor8 | Robin_Watts: that's what I thought. I've seen the dashboard go haywire a few times already. | 14:26.11 |
| Robin_Watts | mvrhel: Is the fact that our default CMYK profile doesn't roundtrip correctly a bug ? | 14:35.42 |
| | (I mean, should we correct the profile so it does?) | 14:35.57 |
| kens | chrisl I see the Unicode question is back | 14:44.26 |
| chrisl | kens: it was bound to rear its head | 14:47.45 |
| kens | A meeting topic I think it should be | 14:48.01 |
| kens | channeling Yoda... | 14:48.23 |
| chrisl | Yes, I think we need to get this cleared up | 14:49.17 |
| mvrhel | Robin_Watts: we should not be doing round trips through profiles | 14:52.05 |
| Robin_Watts | Right, but round-tripping is how marti does black point detection? | 14:52.31 |
| mvrhel | Robin_Watts: Is that a question :) | 14:53.11 |
| | or a statement | 14:53.21 |
| | oh reading his email now | 14:53.39 |
| Robin_Watts | Let me rephase... My (possibly incorrect) understanding from Martis last email is that he now does black point detection via roundtripping. | 14:53.53 |
| mvrhel | reading his email now.... | 14:54.48 |
| henrys` | 3 of the forms meeting | 14:57.57 |
| Robin_Watts | tor8: dashboard looks sanish. | 14:58.21 |
| mvrhel | Robin_Watts: what is interesting is that our default profile is a very simple variant of the standard SWOP cmyk profile. Which would indicate to me that the standard SWOP profile would not roundtrip either | 14:58.25 |
| | Robin_Watts: after I finish up with this bug I will take a closer look at athis | 14:58.44 |
| henrys | kens:to the agenda I'll add | 14:59.24 |
| kens | THank you Master henrys :-) | 14:59.42 |
| | By the way, do we know which hotel yet ? | 15:00.19 |
| mvrhel | bbiab | 15:00.31 |
| henrys | paulgardiner:so last week we said we'd meet and never did about item 11 in the status report | 15:00.33 |
| paulgardiner | Yep. | 15:00.52 |
| henrys | kens:no monday was a holiday I imagine miles will respond today | 15:01.01 |
| | and the thinking was to just create a bitmap | 15:02.21 |
| tor8 | henrys: would it be possible dump a pdfwrite / xpswrite file to cups / windows instead? | 15:03.14 |
| Robin_Watts | Yeah. The linux technique for printer driving seems to be to make a bitmap and then use a filter to turn that into printer specific languages. | 15:03.38 |
| tor8 | Robin_Watts: the question is how we hook into that and generate a bitmap at the correct resolution (or just hardcode it at 300 or 600 dpi?) | 15:04.12 |
| Robin_Watts | We don't. The app does. | 15:04.27 |
| henrys | tor8 is the app | 15:04.39 |
| Robin_Watts | (We = the mupdf libs) | 15:04.42 |
| paulgardiner | Maybe the important thing to be able to claim that the library supports printing | 15:04.59 |
| Robin_Watts | Right, well, that's a different kettle of aquatic lifeforms. | 15:05.03 |
| tor8 | Robin_Watts: right. except we should probably add printing to the viewer. | 15:05.09 |
| | or we can point at sumatrapdf and say "they do printing with mupdf, so it's possible" | 15:05.35 |
| paulgardiner | The only forms-specific part of printing is that a request to print can eminate from the document, rather than just from the user | 15:06.52 |
| | I'm looking now at implementing the event system via which the library can inform the app of things like a print request | 15:07.32 |
| henrys | maybe tor8 is right for now point to sumatra | 15:07.33 |
| henrys | thinks we should entertain buying sumatrapdf | 15:07.51 |
| tor8 | "C++" | 15:08.52 |
| Robin_Watts | (Sorry, phone went). | 15:09.13 |
| | I reckon we should say "the library supports everything you'll need for printing", and as long as we have the right hooks in there, we can be fine. | 15:09.50 |
| | Actually making tors new viewer application print is going to be a larger (post-alpha) job. | 15:10.18 |
| henrys | tor8:did you look more closely at the api sebras pointed to last time? | 15:10.19 |
| | or somebody posted a link the to the gtk printing api | 15:10.42 |
| Robin_Watts | I suspect that sumatrapdf is not for sale (and it would come with a large heap of cruft that we wouldn't want). | 15:11.07 |
| tor8 | henrys: no, sorry, I haven't | 15:11.21 |
| Robin_Watts | AIUI it supports more than one PDF rendering engine, for example. | 15:11.27 |
| henrys | Robin_Watts:I don't know about that the main player seems to be off doing other stuff. | 15:11.46 |
| Robin_Watts | These days the main player is zeniko I believe. | 15:12.05 |
| tor8 | henrys: but I do believe modern gtk+ does printing through cairo | 15:12.23 |
| | so we *could* get printing by writing a cairo device for fitz | 15:12.38 |
| marcosw | Robin_Watts: morning, you kind of broke the cluster with a recent change to clutermaster.pl | 15:12.42 |
| Robin_Watts | marcosw: I did? | 15:12.50 |
| | tor8: Or we render to a bitmap and then output the bitmap to cairo. | 15:13.17 |
| marcosw | I presume you did. I didn't edit the file and I think you and I are the only ones who do. | 15:13.18 |
| Robin_Watts | marcosw: I certainly edited it. I wasn't aware I'd broken it. | 15:13.38 |
| tor8 | Robin_Watts: that would be the lazy^Wtime to market approach :) | 15:13.43 |
| marcosw | "my" variable $s masks earlier declaration in same scope at clustermaster.pl line 402. | 15:13.48 |
| | "my" variable $t masks earlier declaration in same scope at clustermaster.pl line 403. | 15:13.48 |
| Robin_Watts | tor8: I think it's the only sane way to go. | 15:14.01 |
| henrys | tor8:our answer is simply to see what the API supports, that completely constrains our choice. We aren't taking over printing on the platform. | 15:14.21 |
| tor8 | Robin_Watts: given what happens at the back end with cups, yeah | 15:14.22 |
| Robin_Watts | Otherwise people will get one rendering of transparency on screen, then another rendering through cairo. | 15:14.23 |
| | Plus fonty nightmares etc. | 15:14.51 |
| tor8 | alright, if we're happy with bitmap printing then we don't have to do much | 15:14.59 |
| Robin_Watts | marcosw: fixed. | 15:15.20 |
| tor8 | I still want xpswrite and pdfwrite devices though! | 15:15.23 |
| Robin_Watts | tor8: I'm working on pdfwrite :) | 15:15.32 |
| henrys | tor8:we could plug in ghostscript ;-) | 15:15.55 |
| tor8 | henrys: how is the mooscript (or whatever we should call it) project coming along? | 15:16.20 |
| henrys | big plug required | 15:16.22 |
| paulgardiner | Presumably, going through cairo, you either end up generating bitmaps to feed it anyway, or you risk fonty problems. | 15:16.29 |
| tor8 | paulgardiner: true. fonty and transparency problems, both. | 15:16.58 |
| henrys | tor8:I imagine little to 0 progress | 15:17.02 |
| tor8 | henrys: anything I can do to help boost it along, without taking it over completely? | 15:17.31 |
| marcosw | so the cluster now runs two jobs for every mu commit? | 15:17.32 |
| Robin_Watts | marcosw: Yes. | 15:18.02 |
| chrisl | tor8: you have objections to function pointer call backs, IIRC? | 15:18.11 |
| Robin_Watts | marcosw: Unless you want to be clever and spot the commits that can't affect js. And I don't see how. | 15:18.41 |
| tor8 | chrisl: the fitz device interface is built on function pointer callbacks... | 15:18.48 |
| henrys | tor8:I was going to try to convince folks to pull the plug but ... | 15:18.49 |
| chrisl | tor8: well, I was wondering about doing printing in mupdf through something like the Ghostscript display device | 15:19.29 |
| tor8 | chrisl: but, callbacks have the drawback of needing to wrap up state and pass it around in a struct | 15:19.32 |
| | chrisl: right. if we get the mooscript code working, then we're halfway there | 15:20.02 |
| marcosw | Robin_Watts: I always wondered why this wasn't the case from the beginning. | 15:20.29 |
| tor8 | chrisl: mooscript as I started it is a fitz device that calls the ghostscript graphics library, probably higher level than you propose? | 15:20.42 |
| Robin_Watts | marcosw: Why we didn't do 2 tests per commit? | 15:20.55 |
| | because we had the js stuff separated onto a different branch. | 15:21.05 |
| henrys | paulgardiner:anyway it looks you don't really need to worry much about printing, it isn't really specific to the forms stuff. Are there other items in the report we should discuss? | 15:21.38 |
| chrisl | tor8: slightly - I was thinking it would be a device that handles line art and bitmaps, and the calling app could inject those into the print API of the system - so mupdf doesn't need to know anything about the platform | 15:21.52 |
| Robin_Watts | chrisl: There is a defined 'device' API that anyone can write for. | 15:22.38 |
| | SumatraPDF use that to write a GDI+ based renderer, which is what they use for printing. | 15:22.54 |
| paulgardiner | henrys: nothing I specifically need feedback on, thanks. Sometime soon I want to dicuss the api I'm putting in for events, but I'm not quite ready yet. | 15:23.04 |
| Robin_Watts | Our renderer is just one such device. Text extraction is another. PDF write (part written) is another. | 15:23.22 |
| chrisl | Robin_Watts: I considered something defined at link/run time might be less "frightening" to potential integrators | 15:23.54 |
| Robin_Watts | It's a device. It would be at link time. | 15:24.18 |
| chrisl | But if the device simply called callbacks set by the calling code at runtime...... | 15:25.03 |
| Robin_Watts | When you call the apis for "run page" etc, you pass in a device pointer. | 15:25.08 |
| | A device *is* a struct full of callbacks. | 15:25.22 |
| henrys | so we could make gtk print a device and not have it in the viewer app? | 15:26.25 |
| chrisl | But then you need to supply full support for *all* the fitz imaging calls, which is probably more than an integrator would want to undertake | 15:26.27 |
| Robin_Watts | henrys: We could write a GTK device, yes. | 15:26.53 |
| | Or any integrator could. | 15:26.58 |
| | BUT... you'd then have problems with font matching/transparency matching etc. | 15:27.17 |
| | The only way to guarantee that you get printed exactly what we render is to render to a bitmap and dump the bitmap. | 15:27.51 |
| henrys | Robin_Watts:it seems that would be more useful than these xpswrite or pdfwrite - as it would provide an example of using a framework as would be used in a regular app | 15:28.19 |
| Robin_Watts | But any way you cut it, the library already supports all it needs to for printing. | 15:28.34 |
| | If you want to do 'tight' integration with the printing on a given platform, you implement a new device specific for that platform. If you want 'loose' integration, but exact output matching, you just ask mupdf to render to a bitmap and handle that. | 15:29.36 |
| paulgardiner | Ah right. I hadn't thought of it that way before, that writing a device is a potential integration task. | 15:29.48 |
| Robin_Watts | Either way, no changes are required to the mupdf lib itself. | 15:29.56 |
| | paulgardiner: I don't think it's reasonable to expect us to write 'tight' devices for every system. | 15:30.19 |
| paulgardiner | Well, unless commisioned | 15:30.42 |
| Robin_Watts | right. | 15:30.47 |
| chrisl | AIUI, the fitz device interface doesn't know about fonts? | 15:30.49 |
| Robin_Watts | I fear it does. | 15:31.03 |
| chrisl | I thought it just punted fonts off to freetype? | 15:31.41 |
| tor8 | chrisl: type 3 (callback driven) and freetype fonts | 15:31.45 |
| Robin_Watts | The device gets "fz_text" pointers. | 15:32.05 |
| chrisl | Right, I'm thinking that a mupdf "printer device" might not get enough information to send to something like a PDFCreator virtual printer, and have it work as expected | 15:32.32 |
| Robin_Watts | Those include fz_font * pointers, matrices, lengths, strings, wmode etc. | 15:32.33 |
| henrys | well that why the gtk makes sense, it works on all important platforms. Something that actually works is a lot better than just saying all the pieces are there | 15:32.40 |
| Robin_Watts | chrisl: It absolutely should get enough information. | 15:33.05 |
| chrisl | Okay | 15:33.14 |
| | (I thought missing font information was one of the issues with mupdf/pdfwrite to be resolved.....) | 15:33.58 |
| Robin_Watts | henrys: Right. Doing GTK based printing does make sense. | 15:34.23 |
| | but I still reckon we should do it by feeding a bitmap to the GTK print stream rather than writing a cairo device. | 15:34.58 |
| henrys | and that is really part of tor8's viewer project though it may be implemented as a device. | 15:35.04 |
| | tor8:we agree the viewer will support gtk printing? | 15:36.01 |
| tor8 | henrys: sure. but initially by dumping a bitmap, as robin suggests | 15:36.21 |
| henrys | right | 15:36.38 |
| chrisl | We'll be using cairo, then, I think..... | 15:36.59 |
| kens | runs away screaming | 15:37.27 |
| henrys | I'm curious what gtk does on windows. | 15:37.46 |
| chrisl | Either cairo will have a GDI backend, or it will simply dump a bitmap | 15:38.24 |
| henrys | I thought windows was replace GDI with an XPS'ish pipeline | 15:39.12 |
| chrisl | henrys: yeh, but I don't know how up to date cairo will be with that change | 15:39.51 |
| henrys | but it will take a long time to get rid of GDI I reckon. | 15:39.52 |
| Robin_Watts | Right, so it'll make an XPS file with a single bitmap in. | 15:40.03 |
| kens | The drivers in Windows 7 appear to all be GDI | 15:40.09 |
| Robin_Watts | http://developer.gnome.org/gtk/2.24/gtk-High-level-Printing-API.html | 15:40.11 |
| mvrhel | ok. so I have figured out the issue with Bug 693300 | 15:41.40 |
| Robin_Watts | The app calls gtk_print_operation_new, then sets options. Then it calls gtk_print_operation_run to display the dialogue to choose the printer. When the user clicks OK, you get callbacks on the GtkPrintOperation you got from gtk_print_operation_new. | 15:41.53 |
| | One of those being 'draw-page'. When you get that, you tickle Cairo (in our case, we throw it a bitmap) and that then magically goes into the print queue. | 15:42.43 |
| paulgardiner | Trivial then! :-) | 15:43.56 |
| henrys | whip that up for us before the meeting tor8 ;-) | 15:44.33 |
| mvrhel | the windows print pipeline is xps based now | 15:47.13 |
| Robin_Watts | I bet there is a GDI -> XPS stage in there somewhere for old printers though. | 15:47.48 |
| mvrhel | that was supposed to be the case since Vista. | 15:47.53 |
| chrisl | To actually draw to the GtkPrinter, it looks like you have to interact directly with cairo: http://developer.gnome.org/gtk/2.24/GtkPrintContext.html | 15:48.20 |
| mvrhel | there is support for the old pipeline but for windows printing we should be creating xps content | 15:49.19 |
| henrys | I wish we could go back to apps just generating postscript, this really sucks. | 15:50.01 |
| mvrhel | how is the xpswrite device going.... | 15:50.30 |
| henrys | I believe I'll have something between this meeting and the next, did I say that last time? | 15:51.02 |
| mvrhel | and IRC echo... | 15:51.16 |
| henrys | that doens't help mupdf though | 15:51.34 |
| chrisl | If we end up using cairo for this stuff, isn't there a danger that some people will think: why do we need mupdf, let's just use cairo? | 15:53.29 |
| mvrhel | we really dont want to get tangled up with cario do we? | 15:54.03 |
| Robin_Watts | chrisl: Surely there must be cairo calls for "start a page" "put this bitmap on the page" "close page" | 15:54.15 |
| | mvrhel: With GTK you have no choice. | 15:54.32 |
| henrys | I wonder what QT uses - probably the same thing. | 15:54.35 |
| chrisl | Robin_Watts: you need to create canvases and stuff, probably not too much hassle, but if we're just dumping a bitmap, anyway...... | 15:55.57 |
| Robin_Watts | QT doesn't appear to be wedded to cairo. | 15:56.04 |
| paulgardiner | I've always wanted to write an app in QT | 15:56.13 |
| Robin_Watts | Professor google says: | 15:57.29 |
| | When printing directly to a printer on Windows or Mac OS X, QPrinter uses the built-in printer drivers. On X11, QPrinter uses the Common Unix Printing System (CUPS) or the standard Unix lpr utility to send PostScript or PDF output to the printer. As an alternative, the printProgram() function can be used to specify the command or utility to use instead of the system default. | 15:57.38 |
| paulgardiner | tor8: I'd forgotten about QT. How come you chose GTK over QT? | 15:58.14 |
| henrys | paulgardiner:my next question | 15:58.31 |
| tor8 | paulgardiner: C++ | 15:58.35 |
| | or rather, my distaste for it | 15:58.40 |
| chrisl | Distaste? Or vehement hatred? | 15:59.06 |
| tor8 | not that I'm thrilled about Gtk+ either... | 15:59.07 |
| | chrisl: trying to be civil here ;) | 15:59.14 |
| marcosw | henrys: are we meeting today? | 15:59.18 |
| chrisl | :-) | 15:59.20 |
| henrys | it's a library you don't have to deal with the code | 15:59.24 |
| paulgardiner | Ah right fair enough... although you'd probably be writing very little C++ as QT allows so much to be done in xml | 15:59.32 |
| Robin_Watts | Oh, well that's alright then... :( | 15:59.59 |
| kens | Yeah, XML is *so* much better than C++ ;_) | 16:00.15 |
| henrys | Do we want a meeting now or shall we just wait for sunday? | 16:00.20 |
| chrisl | henrys: last time I looked, there weren't any stable C bindings for Qt - that was a few years back, though | 16:00.29 |
| kens | I'm happy to wait | 16:00.29 |
| tor8 | henrys: the API is still C++ (with a preprocessor step you have to run) | 16:00.30 |
| marcosw | I'm happy to wait until Sunday. | 16:00.36 |
| Robin_Watts | I have nothing for the meeting. | 16:00.40 |
| henrys | everyone should be prepared to talk about projects laid out in the last agenda. | 16:00.44 |
| paulgardiner | I was astounded by QT when it turned out hat the blipfoto grid of pictures could be done as 40 lines of xml and no C or C++ | 16:00.51 |
| henrys | I didn't look carefully but don's support HCL tell them to get a support contract. | 16:01.45 |
| kens | henrys I was planning to ignore that one | 16:02.03 |
| | After telling them to report tyhe problem properly | 16:02.19 |
| | The files they've supplied are (as Alex says) not the ones they used, and they work just fine | 16:02.40 |
| | I strongly suspect this is a problem I fixed some time back, but I was just going to sit on it | 16:03.12 |
| henrys | you can write in the bug report that Scott is waiting for a reply from them and we can't do anything until that takes place or I'll do it, let me know | 16:03.20 |
| kens | I'll do that, the bug report as it stands is a waste of time | 16:03.37 |
| henrys | mvrhel:I assume you are good skipping the meeting? | 16:04.39 |
| | alexcher? | 16:04.41 |
| alexcher | yes | 16:05.08 |
| Robin_Watts | henrys: Any ETA on the agenda? <ducks> | 16:05.26 |
| mvrhel | henrys: that is fine | 16:05.37 |
| henrys | Robin_Watts:maybe tomorrow, it's long this time. | 16:05.53 |
| kens | Been a long time between meetings | 16:06.12 |
| chrisl | Uh-oh, don't like the sound of that :-( | 16:06.32 |
| henrys | I won't text ray and tell him the meeting was canceled but it is tempting. | 16:07.34 |
| chrisl | tor8: I've committed the jbig2dec related changes to ghostpdl.git | 16:08.21 |
| tor8 | chrisl: okay. I'll try automatically pulling that commit to jbig2dec.git with some git-subtree voodoo | 16:09.22 |
| chrisl | crosses fingers....... | 16:09.43 |
| mvrhel | oh wow. Bug 693300 just got rather interesting. Turns out that pdf14_compose_group needs to be able to handle overprint | 16:21.56 |
| chrisl | mvrhel: that's what the "compatible" blend mode is for, isn't it? | 16:22.36 |
| mvrhel | this is a weird case where we have two images. one in a separation color space, the other an RGB color space each in their own transparency group | 16:22.53 |
| | and we have overprint mode enabled during the spot image drawing, which occurs after the RGB image is drawn | 16:23.22 |
| | chrisl, the blending is not the issue. the issue is that we ignore the drawn components. I need to think about this one a bit | 16:24.17 |
| chrisl | Ah, oops! | 16:24.49 |
| mvrhel | then to add to the fun there is a soft mask too | 16:25.51 |
| chrisl | Of course there is - otherwise it would be too simple :-( | 16:26.18 |
| mvrhel | ray_laptop: I think I fixed the mem leak issue. It has been committed | 16:26.28 |
| | ray_laptop: did your fix for the copy_planes clist read and write work? | 16:26.49 |
| chrisl | tor8: our ciabot.py hook either stopped being called, or stopped working around Aug 18th - any thoughts? | 16:27.24 |
| ray_laptop | Robin_Watts: for the windows print pipeline, MS caved and did an XPS->GDI so that 'legacy' drivers can work | 16:31.05 |
| Robin_Watts | GDI -> XPS presumably :) | 16:31.20 |
| ray_laptop | Robin_Watts: no, the XPS in the print pipeline is converted to GDI which is what legacy drivers take as input | 16:32.00 |
| | on the app side, the GDI and XGDI, etc. calls put XPS into the pipeline | 16:32.25 |
| Robin_Watts | OK, but how about legacy apps that only know how to create GDI ? | 16:32.30 |
| | ok, so there is both GDI -> XPS and XPS -> GDI. | 16:32.40 |
| ray_laptop | Robin_Watts: right. But initially when MS was promoting the XPS pipeline, they DIDN'T commit to having support for legacy GDI based drivers which caused a furor for a brief while | 16:33.36 |
| | which is how we got sucked into doing XPS. | 16:34.03 |
| | mvrhel: my test for the clist_copy_planes fix has your patch for the increased usage. Are you seeing 2400+ non-pdfwrite differences ? | 16:40.08 |
| mvrhel | ray_laptop: I have not reviewed my diffs. I know there will be a lot though | 16:40.40 |
| ray_laptop | mvrhel: I need to back away from that commit and just do my fix and test it. Should be shortly. | 16:40.55 |
| mvrhel | ray_laptop: ok sounds good thanks | 16:41.09 |
| | Robin_Watts: did you ever find out about the hotel? | 16:57.57 |
| Robin_Watts | mvrhel: Not yet. I'd expect a mail back from miles today I guess. | 16:58.23 |
| | #ghostscript-logs just spoke... | 16:59.00 |
| chrisl | Yes, I fixed it | 16:59.08 |
| Robin_Watts | chrisl: Cool. What was wrong? | 16:59.18 |
| kens | off for dinner | 16:59.28 |
| chrisl | The cia site changed their domain, so the e-mail address we were using no longer worked | 16:59.50 |
| | We should now be fully up to date, I think | 17:01.00 |
| marcosw | Robin_Watts: http://bugs.ghostscript.com/show_bug.cgi?id=692381 describes a UnicodeNote.txt file that was supposed to ship with 9.04 but I can't find any evidence that it did. Is the Unicode support as documented in http://bugs.ghostscript.com/attachment.cgi?id=7728 9.06? I presume it's not the default for the binaries we make. | 17:06.17 |
| Robin_Watts | That looks (at first blush) like a statement of the current situation. | 17:07.31 |
| chrisl | marcosw: we're going to discuss the status of the Windows UTF-8 stuff *again* at the staff meeting | 17:08.11 |
| marcosw | chrisl: so does the current code have the "USEUNICODE=1" nmake option and does it work as described? | 17:08.53 |
| chrisl | marcosw: I can't vouch for it working as described, but the build option is there - just let me check the actual setting..... | 17:09.44 |
| mvrhel | bbiab | 17:10.35 |
| chrisl | marcosw: yes, giving USEUNICODE=1 to nmake will build in the UTF-8 code on Windows | 17:11.10 |
| marcosw | chrisl: thx | 17:11.22 |
| chrisl | np | 17:11.29 |
| | I *really* want it resolved before 9.07....... | 17:11.50 |
| Robin_Watts | I *really* hate perl. | 17:18.08 |
| | But I think the dashboard should be giving proper mujstest links in the 'done' jobs section. | 17:18.22 |
| henrys | Robin_Watts:if you have something for the agenda that I might miss please send it in advance, saves me republishing it. | 17:42.03 |
| Robin_Watts | henrys: I have nothing for the agenda at the moment, but I sometimes think of things when I read your list. | 17:42.31 |
| | Actually, there should probably me an item for "mupdfwrite", so Scott/Miles can be informed about it. | 17:44.12 |
| marcosw | henrys: do want an agenda item for the Ghostscript vs. Distiller file size comparison? | 17:44.36 |
| Robin_Watts | Another for lcms2.4 maybe? (It exists, I have a branch with it on, Marti is looking into a couple of non-trivial diffs) | 17:45.01 |
| henrys | marcosw, Robin_Watts:got them, thanks | 17:46.23 |
| Robin_Watts | tor8: I have some patches on robin/master. The last one is the pdf write stuff (still a work in progress), but the others are preparatory commits for that, and can probably go in as is. | 17:47.53 |
| chrisl | marcosw: I assume you'll be needing Windows builds done for Gemma now that alexcher has committed the JPX workaround? | 17:56.35 |
| marcosw | chrisl: let's see how close mvrhel is with http://bugs.ghostscript.com/show_bug.cgi?id=693300 | 17:58.30 |
| chrisl | Oh, okay, I'd forgotten that was theirs, too | 17:59.08 |
| mvrhel | marcosw: checking the bmp diffs now | 17:59.41 |
| | or running them now | 17:59.48 |
| Robin_Watts | tor8, paulgardiner: VS builds are broken on master (release) | 18:10.01 |
| alexcher | Robin_Watts: What's broken? MSVC 7 builds gs just fine. | 18:26.47 |
| Robin_Watts | alexcher: mupdf. | 18:27.03 |
| | I have a fix on robin/master for tor8 to review. | 18:27.42 |
| ray_laptop | mvrhel: OK, I committed the fix for the clist_copy_planes issue: 2379627 Fix clist_copy_planes to insure that all planes written together. Bug 693234. | 18:43.47 |
| mvrhel | ray_laptop: ok great. thanks | 18:46.34 |
| ray_laptop | I put in the log that it fixes 692324 -- I guess I should test that ;-/ | 18:56.24 |
| | OK, I can duplicate the failure with the cited revision | 19:07.41 |
| | hurray! It _does_ fix that bug as well as the case mvrhel had given me. :-) | 19:10.30 |
| | off to run an errand. | 19:12.46 |
| tor8 | Robin_Watts: in "Add pdf_dict_puts_drop function", you sometimes call pdf_dict_puts(..., pdf_new_int()) instead of the new function | 21:09.55 |
| | everything up to that commit LGTM | 21:10.14 |
| mvrhel | marcosw are you there? | 22:06.30 |
| | oh never minde | 22:07.08 |
| marcosw | mvrhel: yes, but apparently not needed :-) | 22:08.11 |
| mvrhel | sorry I got confused about the hormel chili file | 22:14.33 |
| Robin_Watts | tor8: Will fix that, thanks. | 22:44.21 |
| | tor8: (For the logs) new version of that commit up. | 22:50.34 |
| mvrhel | marcosw: Gemma's bug 693300 is fixed | 23:03.42 |
| marcosw | mvrhel: great, thanks for letting me know. | 23:03.58 |
| mvrhel | I just did the commit marcosw | 23:04.10 |
| | It was a weird transparency/overprint case that I had not seen before | 23:04.43 |
| | The Hormel Chili one appears to be a shading/overprint issue | 23:05.08 |
| marcosw | I just assigned another, similar issue to you: http://bugs.ghostscript.com/show_bug.cgi?id=693018 | 23:08.26 |
| | I'll check to see if your latest commit fixed it. | 23:08.47 |
| | never mind, that is the Hormel Chili one. | 23:09.02 |
| mvrhel | yes. that is a shading issue | 23:26.47 |
| | I already checked to see if it was a transparency/overprint issue | 23:27.06 |
| | oh we are going to be at the hilton | 23:29.51 |
| | have we stayed there before? | 23:30.00 |
| Robin_Watts | I haven't. | 23:31.04 |
| mvrhel | Ok. I loose track of the hotels | 23:31.16 |
| | lose | 23:31.20 |
| Robin_Watts | It's just up from the Doubletree. | 23:31.44 |
| | Near Kincaids, where we eat last time. | 23:31.54 |
| | Forward 1 day (to 2012/09/05)>>> | |
IRC Logs
