| | <<<Back 1 day (to 2012/05/21) | 2012/05/22 |
| tor8 | Robin_Watts: morning | 10:41.22 |
| Robin_Watts | morning | 10:50.10 |
| tor8 | Robin_Watts: any hints on why dprintf, if_debug, etc don't seem to work in mooscript anymore? | 10:52.27 |
| | I have the libgs.a assembled from a 'make debug' build, and my source is compiled with -DDEBUG | 10:52.51 |
| | but nothing makes it out to stdout... | 10:52.58 |
| Robin_Watts | Hmm. | 10:54.07 |
| | dprintf called from where? | 10:54.13 |
| tor8 | from mootop.c and from the dev_ghost bridge device | 10:55.02 |
| Robin_Watts | Let me hunt... | 10:55.13 |
| | OK. is mem->gs_lib_ctx->fstderr set up? | 10:57.00 |
| tor8 | maybe I'm linking wrong... something really weird is going on | 10:57.50 |
| Robin_Watts | gs_lib_ctx_init is supposed to call gs_lib_ctx_get_real_stdio | 10:57.50 |
| | I suspect mooscript predates all the lib_ctx changes I made to remove globals. | 10:58.21 |
| tor8 | this is really weird. I put calls to my own printf-wrapper functions and they're not being called. time to dig further with gdb... | 11:02.31 |
| | and yes, mooscript is really old. did you change the setup code in xpstop.c etc? | 11:02.52 |
| Robin_Watts | yes. | 11:10.58 |
| | This was a couple of years ago. | 11:11.04 |
| tor8 | okay, I think I may have figured it out | 11:11.38 |
| | I'm assembling the libgs.a from the wrong set of object files, so it's getting the wrong main() | 11:11.52 |
| | now it's working better. but odd that the regular pdf interpreter fails when I linked it as I did... :/ | 11:12.38 |
| Robin_Watts | Amazon is selling Nero 11 Multimedia Suide for 25 quid at the moment in a lightning deal if anyone is interested. | 11:14.41 |
| | So Microsoft Visual Studio 11 Express will only target Metro, not the desktop. | 11:39.40 |
| tor8 | Robin_Watts: that's ... disappointing | 11:42.36 |
| Robin_Watts | $499 for the cheapest version that targets the desktop. | 11:43.00 |
| | which probably means £499. | 11:43.14 |
| tor8 | a bit of a drastic turnaround from the approach that they started when they began with the express editions ... | 11:43.34 |
| | I blame apple! | 11:43.44 |
| Robin_Watts | http://www.osnews.com/story/25977/Visual_Studio_11_Express_editions_Metro-only | 11:44.22 |
| kens | It'll be interesting to see if MS changes their mind over Metro, which will depend on whether big outfits refuse to upgrade. And of course if it shuld become phenomenally succesful on mobiles so that MS doesn't care about desktop PCs any more :-) | 12:03.25 |
| Robin_Watts | Metro makes sense for touchscreen (or gesture based) PCs. | 12:03.50 |
| kens | Yes, but not for desktops | 12:04.00 |
| Robin_Watts | s/PCs/computers/ | 12:04.02 |
| | indeed. | 12:04.04 |
| kens | Most corporates use desktops, I can't see them changin in a hurry | 12:04.22 |
| Robin_Watts | so it makes perfect sense that MS should try to move windows into that space. | 12:04.27 |
| | And having the desktop as 'just another tile' seems a reasonable way to do that. | 12:04.45 |
| kens | Not convinced. | 12:04.58 |
| Robin_Watts | BUT ditching the desktop entirely? bonkers! | 12:05.13 |
| kens | But I bet someone will come up with a nice startup app which will launch the desktop tile straight to the front for me | 12:05.19 |
| Robin_Watts | kens: I think the point is that things like the login screen will be a tile, and it means any device that can run metro can drop back to the desktop. | 12:05.58 |
| | It's a sneaky way of getting a nice interface and yet keeping the power of the desktop. | 12:06.19 |
| kens | But I understand that you won't be able to get straight to the desktop | 12:06.37 |
| | You have to launch into Metro and tehn change. | 12:06.51 |
| Robin_Watts | I can only hope that this is a ploy to get people to write more metro apps, and they'll keep supporting VS11. | 12:06.54 |
| kens | We will have to see :-( | 12:07.02 |
| | A single Window interface is such a backward step | 12:07.22 |
| Robin_Watts | indeed. | 12:07.30 |
| | Windows took long enough to get out of the "one window per app" hole it started in as it was. (Some would say it still has one foot in there) | 12:08.03 |
| | Certainly it's still less usable than RISC OS was 20 years ago. | 12:08.15 |
| | (Oh god, I'm turning into one of them) | 12:08.23 |
| kens | One window per app is bad enough, one window in the display is jst awful. | 12:08.37 |
| paulgardiner | Robin_Watts: Oh do you remember the dragable save icon. Those were the days. :-) | 12:09.59 |
| Robin_Watts | paulgardiner: Indeed. Drag and drop between apps/filer windows? It's so simple. Why has no one done it as well since? | 12:10.50 |
| paulgardiner | I know. Madness | 12:11.11 |
| kens | "Real cardboard ?".... | 12:11.49 |
| Robin_Watts | ? | 12:12.47 |
| kens | 4 Yorkshiremen sketch | 12:13.00 |
| | Monty Python | 12:13.11 |
| Robin_Watts | right. | 12:13.51 |
| | The tiffsep device leaks if it gets memory allocation errors. | 12:18.15 |
| | Do I fix it, or do I leave it and say "it was broke when I found it" ? | 12:18.29 |
| kens | I htink a lot of devices do that. pdfwrite certainly does. I fixed the ones I foudn when doing the memory work but I am morally certain there are more. | 12:20.36 |
| paulgardiner | Did we decide at some stage that pdf_keep_obj(NULL) should be permitted? | 12:22.27 |
| Robin_Watts | paulgardiner: Urm... drop_obj(NULL) is certainly permitted. | 12:22.56 |
| paulgardiner | Yeah, but I thought you and Tor discussed keep. | 12:23.17 |
| Robin_Watts | quite possibly. | 12:23.31 |
| tor8 | paulgardiner: it should be permitted. | 12:23.37 |
| | if we didn't decide so before, I've decided it now :) | 12:23.47 |
| paulgardiner | -) | 12:23.52 |
| | :-) | 12:23.55 |
| tor8 | almost all of the other the pdf_obj functions take NULL safely and return "safe" defaults | 12:24.18 |
| Robin_Watts | Where the hell has everything gone from inside the mupdf solution?! | 12:24.27 |
| tor8 | Robin_Watts: mubusy? | 12:24.40 |
| paulgardiner | You might not wish to permit the scenario that lead me to ask about it. | 12:24.41 |
| Robin_Watts | tor8: I now have generated, mubusy and mudraw. | 12:25.01 |
| tor8 | and mupdf? | 12:25.09 |
| Robin_Watts | I feel sure I still need the actual pdf/fitz/xps code somewhere ;) | 12:25.17 |
| paulgardiner | Aaggh! What I was going to do wouldn't have worked anyway. | 12:25.44 |
| Robin_Watts | ok, a git checkout of win32 solved it. | 12:26.37 |
| | paulgardiner: pdf_keep_obj *does* work perfectly well will NULL. | 12:27.01 |
| paulgardiner | My copy has an assert in it. I probably need to rebase some time. | 12:27.28 |
| tor8 | Robin_Watts: glad it solved itself. I just checked it out and I see what I expect. | 12:27.29 |
| Robin_Watts | paulgardiner: Have you published the forms branch to the golden repo? | 12:28.00 |
| | If so, then rebasing is bad. | 12:28.12 |
| | You should merge trunk to forms in that case. | 12:28.35 |
| paulgardiner | No. Still only on my repo on casper | 12:28.38 |
| Robin_Watts | Ah, then rebasing is fine. | 12:28.45 |
| Robin_Watts | lunches | 12:46.58 |
| sebras | tor8 Robin_Watts: oh... -g3 is a flag for gcc that was new to me, might come handy in mupdf perhaps? | 14:02.08 |
| Robin_Watts | What does it do? | 14:02.42 |
| sebras | requests gcc to generate more debug info, for macros e.g. | 14:03.02 |
| Robin_Watts | I try and avoid using unix when debugging :) | 14:03.29 |
| chrisl | sebras: if you use "-gdwarf-2 -g3" with gcc that includes macro debug data, too. | 14:15.05 |
| Robin_Watts | http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options | 14:35.09 |
| | chrisl: -gdwarf-2 does not accept a concatenated debug level, because GCC used to support an option -gdwarf that meant to generate debug information in version 1 of the DWARF format (which is very different from version 2), and it would have been too confusing. That debug format is long obsolete, but the option cannot be changed now. Instead use an additional -glevel option to change the... | 14:35.18 |
| | ...debug level for DWARF. | 14:35.20 |
| chrisl | Oh, well when they introduced macro info in gcc 3.x they defaulted to DWARF2 format, but you still had to give the two options for it to work - I guess that was bug that they fixed since..... | 14:38.49 |
| | In that case, I should probably change the Ghostscript build to use -g3 when it's gcc....... | 14:41.10 |
| Robin_Watts | I can't parse the sentence, so I just pasted it :) | 14:41.55 |
| henrys | chrisl:I use -ggdb in the other language but I also have -g3 which I should get rid of. | 14:43.56 |
| chrisl | For a while, -ggdb didn't include macro data - I guess that's also changed now. | 14:45.09 |
| henrys | yes macro stuff works okay | 14:46.02 |
| Robin_Watts | henrys, tor8, paulgardiner: Forms meeting in 15 mins ? | 14:46.51 |
| tor8 | Robin_Watts: I assume so. | 14:47.07 |
| henrys | right | 14:47.10 |
| paulgardiner | Oh yes. Ok | 14:47.11 |
| kens | Can anyone remember the magic PostScript operator which does nothing but I can use ot for a breakpoint ? | 14:47.18 |
| henrys | zsetdebug | 14:49.18 |
| kens | aha, thanks henrys | 14:49.24 |
| henrys | paulgardiner:so I agree the list is scary ;-) | 15:00.06 |
| paulgardiner | henrys: Yes quite. Hopefully we don't have to implement every part of every item. | 15:00.48 |
| henrys | in the interest of the schedule I wonder if tor8 could take on a couple of items in parallel? | 15:00.55 |
| Robin_Watts | Can we run through each task quickly? | 15:01.10 |
| henrys | yes | 15:01.35 |
| Robin_Watts | Suite of test files: That's just a matter of grepping tests{,_private}/pdf for... something, right? | 15:01.56 |
| henrys | alexcher has a *HUGE* corpus of PDF files also. | 15:01.57 |
| Robin_Watts | /AcroForm I think? | 15:02.43 |
| henrys | maybe I can ask alexcher to do that along with his tests. | 15:03.10 |
| paulgardiner | Yes. | 15:03.10 |
| | Yes to /AcroForm that was | 15:03.26 |
| tor8 | henrys: yes, I can probably do work on the fast partial update part. | 15:03.31 |
| henrys | okay is that really a significant delay? | 15:03.55 |
| Robin_Watts | I was going to say, do we need to worry about that? | 15:04.25 |
| sebras | Robin_Watts: pdfshow test.pdf g | grep '\/AcroForm' | 15:04.33 |
| Robin_Watts | the ios port rerenders from the document every time, right? | 15:05.11 |
| | sebras: grep -l -R /AcroForm . --include="*.pdf" | 15:05.29 |
| tor8 | henrys: nope, but it's low hanging fruit :) | 15:05.30 |
| Robin_Watts | I'd vote not to touch it until we need to. | 15:05.46 |
| henrys | seems reasonable to me. | 15:06.05 |
| paulgardiner | tor8: I realised only the other day that for fast update the app can probably best do the compositing. Like in Android, you'd just put an annotation view over the doc view. That's probably what you had in mind from the beginning. | 15:06.10 |
| tor8 | Robin_Watts: the ios app only redraws the page on zooming though. | 15:06.14 |
| Robin_Watts | Right, but even so, it's fast enough for a proof of concept, right ? | 15:06.35 |
| henrys | tor8:OTOH if it's easy and painless than just do it, but let's get it off paulgardiner's desk. | 15:06.39 |
| tor8 | paulgardiner: yes, just be able to draw annotations to separate pixmap buffers (and composite them manually or let the os do it) | 15:06.52 |
| | either way, it's not a critical piece to getting something shippable | 15:07.10 |
| Robin_Watts | I have no useful comments on the DOM other than to put my finger on my nose. | 15:07.10 |
| paulgardiner | Hopefully we'll find that many of the test files restrict themselves to a smallish subset of the dom | 15:07.56 |
| henrys | I got nothing for that too. | 15:07.59 |
| Robin_Watts | Saving forms: I'm gradually knocking the PDF saving code into shape as I do the "save linearised" code. | 15:08.45 |
| henrys | on to the next one - can't this data also be stored externally? | 15:08.52 |
| Robin_Watts | Do we need anything other than being able to save PDF files? | 15:08.58 |
| paulgardiner | Robin_Watts: I don't believe so. It looks to me so far that all state changes naturally go into the dicts | 15:09.31 |
| henrys | okay but I thought you could use external xobjects but that may not be common. | 15:10.14 |
| paulgardiner | Robin_Watts: transitory stuff like changes for the sake of mouse over say don't have places in dicts to save them but we don't want to save those anyway | 15:10.19 |
| Robin_Watts | Submitting forms: That sounds like it needs investigation (like someone authoring a few forms with acrobat and playing with the submission options) | 15:10.22 |
| | henrys: There is this FDF thing and the XML forms thing. | 15:10.40 |
| | and presumably the form status must be exposed as key/value pairs for http submission. | 15:11.04 |
| paulgardiner | The submitting may end up mostly done in the app with the lib just supplying mapping from field to value, but I'm unsure as yet what the JS SOAP object is for | 15:11.21 |
| henrys | tor8:maybe you could do the linux and ios build (next item)? | 15:12.03 |
| | I got the impression paulgardiner was a windows mostly developer | 15:13.16 |
| tor8 | henrys: yeah. I have considered caving and using gtk+ for our linux viewer so we can get proper text fields, but if we're doing inline editing maybe that is something we can reuse for search entry etc. | 15:13.19 |
| Robin_Watts | My gut feeling is that the app changes are going to evolve through several iterations before they stabilise. | 15:13.41 |
| | If that's true, then it may make sense to hold off recoding the app side multiple times until it's settled ? | 15:14.09 |
| paulgardiner | henrys: It is probably where I'm most at home. | 15:14.11 |
| | Robin_Watts: That's a good point. | 15:14.25 |
| tor8 | there is also that. | 15:15.04 |
| henrys | Robin_Watts:Part of my evil plan was tor8 would catch stuff as he integrated but maybe you are right. | 15:15.05 |
| Robin_Watts | Debugging android is a bitch. debugging ios is only marginally better. | 15:15.09 |
| paulgardiner | Robin_Watts: although an iOS or Android version might be a good demo (when we get to the stage of feeling we are far along for a demo). | 15:15.54 |
| tor8 | Robin_Watts: debugging ios with xcode is actually not that bad. a lot better than my experience with android. | 15:15.55 |
| Robin_Watts | My experience with android is that you can get code to run easily, but debugging is "printf". | 15:16.26 |
| paulgardiner | Debugging the Java parts of android isn't bad, but native code is difficult I think | 15:16.41 |
| Robin_Watts | My experience with iOS is that it's impossible to get code to run, but when you do, the debugger may be OK. | 15:16.48 |
| | but tor8 has clearly got over the impossible stage with iOS :) | 15:17.18 |
| paulgardiner | Eclipse gives quite a nice debugging interface for the Java parts. | 15:17.19 |
| Robin_Watts | but all the interesting stuff is in the native sections, right? | 15:17.36 |
| tor8 | Robin_Watts: the major problem I've had with iOS is the lack of source and ambiguous documentation for the massively overcomplicated frameworks. | 15:17.38 |
| | but the debugger is easy, since it's all native code and gdb at the bottom | 15:18.13 |
| paulgardiner | Robin_Watts: But hopefully the native bits will be already adequately tested on Windows. | 15:18.22 |
| Robin_Watts | "API via which text constraints can be handled in native text widgets" is basically "widget text layout", right? | 15:18.43 |
| paulgardiner | Hmmm | 15:19.03 |
| henrys | paulgardiner:generally if you come across a feature and the latest chrome doesn't implement it let's note it but not work on it. Maybe some of these items fall into that category. | 15:19.37 |
| Robin_Watts | The app edits a string, and we lay that string out (i.e. make an appearance stream from it) ? | 15:20.03 |
| paulgardiner | henrys: Yes. That's a good point. | 15:20.11 |
| Robin_Watts | At the moment, mupdf doesn't have any layout capabilities at all. I have this niggling thought that a layout engine would be nice to have at some stage (to allow us to do reflow, or to support document formats that aren't absolutely positioned) | 15:22.02 |
| paulgardiner | Robin_Watts: at the moment on Windows, I don't try to make the native text dialog look like part of the doc. When I bring it up, I populate it with the current field text. When the user changes the text and presses ok I update the PDF field | 15:22.02 |
| | Robin_Watts: we need at least a very primitive layout engine for multiline text fields. | 15:22.37 |
| Robin_Watts | Oh, sorry, this is native text widgets. | 15:22.42 |
| | I'd missed the all important 'native'. | 15:22.55 |
| | We need to layout whenever the app returns us a string and we have to put it into the document. | 15:24.01 |
| tor8 | yeah, didn't we decide on using native widgets? or both? or has paul changed his mind? | 15:24.07 |
| Robin_Watts | With native text widgets that's when the native widget closes. | 15:24.16 |
| tor8 | anyway we have to do the layout to save it back out | 15:24.19 |
| Robin_Watts | With inline widgets, that's on every keypress. | 15:24.25 |
| | But I don't see the need for us to pass styling information to the native widgets personally. | 15:24.56 |
| tor8 | text layout is a big task to get right if we want to support everything (bidi languages, CJK input, etc) | 15:25.11 |
| Robin_Watts | (at least for a first version, I don't care if my widget is 'centred' and the native widget shows it left aligned) | 15:25.26 |
| | tor8: Yes. And it's not just 'text' layout. | 15:25.52 |
| paulgardiner | Robin_Watts: that's easier then. I think if we try to style the native widgets to match the field, it's really not going to work, | 15:26.05 |
| Robin_Watts | It would make sense to style the native widgets to the field if you could edit the styling in the native widget (like, say, change the justification, or the boldness of the text etc) | 15:26.40 |
| | but my understanding is that we can't - we just change the text ? | 15:26.50 |
| tor8 | we did talk about fonts for the form filling in london, the fonts embedded in the pdf may not have full character sets for instance | 15:26.57 |
| paulgardiner | Robin_Watts: centred dialog with left aligned text is exactly how it is now. | 15:27.02 |
| Robin_Watts | And I reckon that's plenty good enough for a first version. | 15:27.19 |
| tor8 | so maybe we should swap fonts to one of the base 14 once we start editing | 15:27.35 |
| Robin_Watts | If people want exactly the right text, then they should be using inline widgets. | 15:27.38 |
| paulgardiner | There are constraints like numerical only, or password that we might want to enforce. | 15:27.57 |
| | Robin_Watts: Yes. Agreed | 15:28.13 |
| Robin_Watts | tor8: I'm inclined to think that if people use chars that aren't in the font, then they just won't display. | 15:28.17 |
| | (we should check how acrobat handles that) | 15:28.26 |
| | but the data will be there on submission. | 15:28.34 |
| paulgardiner | acrobat and chrome look inline only to me. | 15:28.42 |
| Robin_Watts | paulgardiner: password, yes. | 15:28.46 |
| | numerical only - that sounds like a validation thing, which is a separate issue. | 15:29.00 |
| | validation is done using JS, right ? | 15:29.11 |
| tor8 | on a personal note, I *hate* fields where you can't ever have it in an invalid state. | 15:29.28 |
| henrys | I was just looking at the Quality Logic PDF FTS - it says 26 tests for interactive forms. | 15:29.40 |
| paulgardiner | validation can be JS, but there are also ways that the doc can legislate numerical only etc. | 15:29.49 |
| tor8 | like number fields where you're not allowed to have it empty for instance. makes entering text a royal pain. | 15:29.49 |
| Robin_Watts | I have a list of the files from our repo here. I'll mail 'em out. | 15:29.58 |
| paulgardiner | henrys: That looks useful | 15:30.11 |
| | To a small degree, I could already do inline editiing. On each key press I'd just need to do text=current_field_text; text+=char; current_field=text if you see what I mean. | 15:32.20 |
| henrys | reading a bit ahead is non-js actions something that could be handed off to tor8? | 15:32.29 |
| Robin_Watts | Inline editing: I am becoming more convinced that this is the ideal way to go. I'm still reluctant to drop support for native widgets, because on some devices (mobile ones etc), we may need them. | 15:32.58 |
| paulgardiner | Robin_Watts: That's pretty much how I see it. | 15:33.47 |
| Robin_Watts | paulgardiner: Or you'd need to have the notion of 'caret position' and allow 'insert', 'delete','back/forward' etc. | 15:33.51 |
| paulgardiner | Robin_Watts: Yes. That's why I said to a small degree. | 15:34.18 |
| tor8 | rolling our own text fields is easy enough for the desktop platforms, but the touch and mobile devices all have their own funky ideas about text input | 15:34.28 |
| | so yes, I do think we need to support native widgets at least for mobile | 15:34.46 |
| paulgardiner | Robin_Watts: but given that we already have to create the appearance streams for the text. Adding a caret and highlighting part of it isn't a huge extra | 15:35.00 |
| Robin_Watts | paulgardiner: I agree that a first version may not be a massively hard thing to do. | 15:35.01 |
| | Other Javascript engines: Anyone have a feeling for how important this is? | 15:35.43 |
| tor8 | and the hardest task is (should be) doing the text layout, handling enough UI state to replicate notepad should be trivial. with emphasis on should :) | 15:35.49 |
| Robin_Watts | My gut says it's around a weeks work to get spidermonkey in and up to the stage that v8 is now, if we have no problems. | 15:36.25 |
| henrys | let's not worry about other engines now. | 15:36.47 |
| paulgardiner | Robin_Watts: probably right. | 15:36.49 |
| Robin_Watts | (that's 2 weeks for Paul cos he's halftime) | 15:36.51 |
| | henrys: good answer :) | 15:37.03 |
| paulgardiner | henrys: yes. Excellent answer. | 15:37.18 |
| Robin_Watts | Synthesise missing appearance streams for fields other than text : Is it just checkboxes and tickboxes we are missing? | 15:37.30 |
| paulgardiner | I'm probably managing a bit more than half time, BTW. | 15:37.48 |
| henrys | of course tor8 may want to fool with it, I know he wanted to try spidermonkey. | 15:37.52 |
| | I am curious what chrome does for the next one? | 15:38.28 |
| Robin_Watts | checkboxes and tickboxes strike me as pretty important; I can't imagine too many forms don't require them? | 15:38.46 |
| | henrys: which one ? | 15:39.00 |
| henrys | missing appearance streams. | 15:39.16 |
| Robin_Watts | It may be worth looking at zenikos patch for this, at least to see which ones he's added code for, | 15:39.29 |
| paulgardiner | Robin_Watts: I'm less sure about the missing appearance stream stuff now. Less sure we need it that is. | 15:39.51 |
| sebras | Robin_Watts: just grepping means you're missing out on AcroForms embedded in object streams, where ase pdfshow *.pdf g | grep '\/AcroForm' would catch those as well. that's why tor8 invented grepable for pdfshow on one late night of debugging... | 15:39.52 |
| Robin_Watts | We probably shouldn't take on the code itself from the patch without double checking his email. | 15:40.03 |
| | sebras: Right. | 15:40.09 |
| | sebras: But it'd need a funky xargs invocation to cope with a recursive grep and I'm not that l33t. | 15:40.44 |
| paulgardiner | I removed the appearance stream for a button from one of my test files, and Adobe reader didn't recreate the stream until I pressed the button (which would have been because of JavaScript updating the look of the button). | 15:41.24 |
| henrys | paulgardiner:just to verify you mean we don't support it when you say unsupporterd or do you mean Adobe? | 15:41.33 |
| tor8 | Robin_Watts: find . -name '*.pdf' -exec mubusy show {} g \; | grep AcroForm | 15:41.45 |
| paulgardiner | henrys: which bit is that? | 15:41.49 |
| henrys | under text field variants | 15:41.50 |
| Robin_Watts | paulgardiner: If we find forms that have checkboxes and tickboxes in, but don't have appearance streams (or rely on us synthesising the appearance stream on a change of state), then that's pretty damn important, I reckon. | 15:42.39 |
| tor8 | "Combed text"? | 15:42.48 |
| paulgardiner | henrys: I meant I've yet to do anything towards those. | 15:42.55 |
| Robin_Watts | I can't imagine a serious use of forms that doesn't involve at least 1 checkbox or tickbox. | 15:42.58 |
| paulgardiner | Robin_Watts: I just meant that, from what I've seen recently, I now suspect missing appearance streams may be uncommon, unless it's a doc that is marked as needing regeneration | 15:44.14 |
| Robin_Watts | "[] Click here to opt out of us spamming you" | 15:44.20 |
| | OK, so it's a rare case. | 15:44.30 |
| henrys | we are getting close to the next meeting and the limits of my ADHD medication. | 15:44.46 |
| paulgardiner | Robin_Watts: It may be. | 15:44.48 |
| Robin_Watts | Did anyone have any thoughts on my mujstest mail ? | 15:45.18 |
| tor8 | Robin_Watts: sounds like something we'd implement using javascript ;) | 15:45.42 |
| Robin_Watts | tor8: I think it's a modified version of a pdfapp.c client - we render to an internal bitmap, and the apps commands, instead of coming from the user, are driven by the script. | 15:46.53 |
| tor8 | aren't there x11-based tools that do similar things though? click at this coord, type this text, grab a screenshot, etc | 15:46.55 |
| | like expect but for gui apps | 15:47.12 |
| henrys | It is a good idea make the testing batchlike and non interactive. | 15:47.27 |
| paulgardiner | tor8: I believe combed text is where forms have a line of boxes that are supposed to be filled one per letter. | 15:47.29 |
| Robin_Watts | If we want to run it on the cluster, we can't use X. | 15:47.39 |
| tor8 | right. | 15:48.17 |
| henrys | I imagine testing forms should be done as an overnight activity not clustered done with custom scripts at marcos' place on an imac or a linux box. | 15:48.18 |
| paulgardiner | tor8: What's the thing that we might do with javascript? Not sure I saw the email | 15:48.22 |
| tor8 | paulgardiner: I was mostly joking. about robin's suggestion to test scripting with a script :) | 15:48.51 |
| Robin_Watts | paulgardiner: 17/05/2012 15:01 From me: Subject "Re: PDF form tasks" | 15:49.02 |
| | I may regret this, but I'd be interested in having a go at a first version of mujstest. | 15:49.39 |
| paulgardiner | tor8: Ah. I'd wondered that. Maybe I should have been joking. | 15:49.45 |
| henrys | Robin_Watts:I was going to try and get you back into ghostscript as soon as linearized was done. | 15:50.36 |
| paulgardiner | Ah silly me. I read mujstest as a possible IRC name :-) | 15:50.39 |
| henrys | we do need to wrap up - it would be good to figure out what tor8 can do in parallel to expedite the schedule. I think it is important for us to get something out soon. It's a fast moving marketplace we may be missing opportunities. | 15:52.14 |
| tor8 | I'd be happy to bring our desktop viewer up to the same level of functionality as the ios and android apps (it's lagging behind a lot there) | 15:53.25 |
| | if we want to use that as a target for showing off form support | 15:53.49 |
| | I think it'd be faster to try it out than doing the same for android | 15:54.08 |
| Robin_Watts | hell yes. | 15:54.14 |
| tor8 | it's something we've wanted to do for soon two years but never allocated the time for | 15:54.59 |
| henrys | okay that sounds good - we don't need any formal assignment - just paulgardiner should keep in mind that if he comes across something tor8 can easily do hand it off if it picks up the schedule. | 15:55.00 |
| paulgardiner | Ok good. | 15:55.28 |
| | tor8: I have of course have a few app changes on my branch but not a huge number. | 15:56.05 |
| tor8 | so paul doesn't have to worry about incermental updates (tor, or later), other javascript engines (later), saving forms (robin) | 15:56.27 |
| ray_laptop | kens: I assume you figured out the rest of the PS b.p. () true .setdebug is the do nothing PS sequence (true or false), then b.p. in C in zsetdebug (psi/zmisc.c) | 15:56.37 |
| tor8 | and collecting test files (robin, or alexcher?) | 15:56.58 |
| kens | ray_laptop : once I knew the operator I looked in teh docs, thankls though | 15:57.24 |
| paulgardiner | I'm working on another one of my original test files at the moment. It demonstrates javascript updating the appearance of a button to make into a toggle. It's all stuff we definitely need, and leads me into a js api change I need to make. | 15:57.29 |
| Robin_Watts | tor8: I've mailed out a list of forms files. | 15:57.45 |
| | We can get alex to check his set too. | 15:57.52 |
| alexcher | tor8: I can look for JS files im my collection. | 15:57.57 |
| tor8 | Robin_Watts: right, so that's a start. | 15:58.10 |
| | alexcher: I have updated the mooscript branch today and added a README with build instructions. | 15:58.40 |
| paulgardiner | Great. collectiont the test files seemed one of the most important to me. They should give us a better idea of how the dom is generally used | 15:58.57 |
| tor8 | it can draw the tiger and render text. | 15:59.00 |
| | let me know if you have any trouble building it | 15:59.13 |
| paulgardiner | alexcher: thanks. | 15:59.16 |
| Robin_Watts | paulgardiner: Have you checked out our test files yet from svn ? | 15:59.30 |
| henrys | paulgardiner:anything else, we have to move along to the next meeting now? | 15:59.33 |
| alexcher | tor8: yex, I've seen this. | 15:59.39 |
| paulgardiner | henrys: No. That's good. We've covered a lot. | 15:59.54 |
| henrys | marcos will be late so if you had questions for him hold off. | 16:00.30 |
| kens | I do | 16:01.18 |
| henrys | ray_laptop:I see you have an important new deadline do you need someone else to look at other problems on your desk? | 16:02.07 |
| | I didn't really have anything for this meeting or if I did I forgot it in the forms meeting. Does anybody else have business for this meeting? | 16:03.24 |
| mvrhel_laptop | I don't have anything | 16:03.39 |
| henrys | Robin_Watts:sort of curious when linearized will be done? | 16:03.45 |
| | it looks like hin-tak was very busy this weekend. | 16:04.20 |
| kens | henrys yes please | 16:04.23 |
| | We need to think about controling pdfwrite from non-PS interpreters | 16:04.49 |
| Robin_Watts | henrys: It's held up at the moment, but 1) me waiting for tor8 to revamp some old commits, and 2) me being up to my armpits in downscaler. | 16:04.50 |
| | but hopefully not too long when both those get unblocked. | 16:05.06 |
| | A couple of staff meetings ago we brought up the fact that there are no decent font equivalents for something or other that we needed. | 16:06.22 |
| henrys | kens:agreed but I see it being on the list just not very high up. | 16:06.38 |
| | kens:do we have a customer with a concern? | 16:06.58 |
| kens | Yes, ActivePDF | 16:07.11 |
| henrys | damn | 16:07.22 |
| chrisl | Robin_Watts: that got pushed down the priority list because the potential customer appears to have made alternative arrangements. | 16:07.25 |
| henrys | so much for my "not high on the list" idea | 16:07.43 |
| kens | henrys its come up twice this week which is what prompted me | 16:07.49 |
| ray_laptop | henrys: sorry -- I was distracted. If someone (mvrhel) wants to look at bug 693036 that's fine with me. What I am working on for cust 532 is bug 693013 | 16:08.07 |
| Robin_Watts | chrisl: OK. I said at the time jokingly that we should kickstarter a campaign, but the more I think about it, the more it seems like a really good idea. | 16:08.09 |
| henrys | I'll look at it today, I did see a bug report but just glanced at it. | 16:08.10 |
| kens | henrys the bug report is a free user, but there is a support email | 16:08.25 |
| mvrhel_laptop | ray_laptop: on that one (bug 693036) did I need to do a speed test, server and non-non server mode for his cases with and without -dUseFastColor? | 16:09.33 |
| chrisl | Robin_Watts: first, I doubt we'd get much interest, and second, I think we have access to "decent" fonts for those requirements - I just need to go through and compare (some of!) the glyphs in them. | 16:09.33 |
| henrys | ray_laptop, mvrhel: I thought we agreed push back on that. Don't use fastcolor, wait for the server, we can't help you more, please go away. | 16:10.06 |
| | mvrhel_laptop ^^^ | 16:10.22 |
| ray_laptop | mvrhel_laptop: I did the speed test, but the problem with wrong output with PCL and -dUseFastColor remains | 16:10.23 |
| Robin_Watts | chrisl: It costs us nothing to try, and you'd be amazed what gets funded. but if we don't have a problem any more then fair enough. | 16:10.39 |
| mvrhel_laptop | ray_laptop: oh. so did you reply to the customer? | 16:10.41 |
| henrys | right marcosw is doing a cluster test with UseFastColor and we're going to look at that. | 16:10.56 |
| ray_laptop | henrys: I think we need to understand why the output is wrong. We may have other PCL customers that prefer FastColor | 16:11.11 |
| mvrhel_laptop | I agree that I will look at the rendering problem | 16:11.26 |
| | just trying to find out if the customer was told anything yet | 16:11.40 |
| | specifically what henrys said | 16:12.06 |
| ray_laptop | mvrhel_laptop: I have to look where I sent/posted the server results. | 16:12.11 |
| chrisl | Robin_Watts: the problem is (I think) there are two or three "good enough" candidates already out there so I don't think there would be much funding floating around for it | 16:12.25 |
| Robin_Watts | On another subject; assuming I can find and fix this (hopefully) last problem with the downscaler and tiffsep, do we need to worry about antialiasing not working with device n any more ? | 16:12.31 |
| henrys | we left it as marcosw would do a complete regression test for UseFastColor this customer would be told to not use UseFastColor and the bug will be closed. | 16:12.43 |
| | by all means push communication to marcosw or I'll tell him if you want. | 16:13.47 |
| mvrhel_laptop | henrys: right I think the bug should stay open but maybe the customer number should be removed from the bug | 16:14.06 |
| | or a new bug opened | 16:14.47 |
| henrys | okay I'll process this bug you guys forget about it. | 16:14.55 |
| chrisl | Robin_Watts: we have had people using just text anti-aliasing, or just graphics - but I'm not sure if that was just ignorance on their part........ | 16:15.52 |
| henrys | Robin_Watts:so mupdf doesn't support devn so this is not an issue? | 16:16.49 |
| mvrhel_laptop | Robin_Watts: that is a good question. the priority to get it working likely goes to enhancement limbo | 16:16.53 |
| | mupdf doesnt even do cmyk does it? | 16:17.14 |
| Robin_Watts | henrys: The problem is purely a ghostscript one. | 16:17.36 |
| ray_laptop | why this customer (393) thinks they need AA at 400 dpi is a puzzle to me | 16:17.40 |
| mvrhel_laptop | yes | 16:17.44 |
| henrys | the bugs are now in single digits enhancements should not be limbo for long? | 16:17.44 |
| Robin_Watts | mupdf only currently has rgb and greyscale plotters - but we could add cmyk or cmyk + spots easily. | 16:18.20 |
| | and supporting aa under that would be easy. | 16:18.27 |
| mvrhel_laptop | with overprint? | 16:18.47 |
| Robin_Watts | Why not? | 16:18.56 |
| mvrhel_laptop | oh I didnt know all of that would be easy | 16:19.06 |
| Robin_Watts | I didn't say adding new plotters would be easy :) | 16:19.19 |
| mvrhel_laptop | I thought you said easily | 16:19.36 |
| Robin_Watts | (New plotters aren't hard, but they aren't trivial) | 16:19.39 |
| | I said the AA bit of it would be easy. | 16:19.46 |
| mvrhel_laptop | now you sound like a politician. | 16:20.21 |
| Robin_Watts | The issue with not being able to AA devn colors in ghostscript is purely down to the highlevel color/color index thing. | 16:20.22 |
| | ooh, bitch! | 16:20.35 |
| | :) | 16:20.40 |
| | Mupdf doesn't have the concept of cramming colours into an int (color_index), so it's not a problem. | 16:21.14 |
| mvrhel_laptop | right | 16:21.20 |
| | ghostscript doesn't either now. ;) | 16:21.42 |
| Robin_Watts | mvrhel_laptop: <cough>copy_alpha</cough> | 16:21.57 |
| mvrhel_laptop | or rather has both | 16:21.57 |
| chrisl | Robin_Watts: so how does mupdf represent colors? | 16:22.03 |
| henrys | is it just me that thinks this should be fixed properly, it should work without scaling, if so I'll be quiet. | 16:22.04 |
| Robin_Watts | chrisl: An array of color values. | 16:22.26 |
| mvrhel_laptop | henrys: I think we want it fixed properly. I would like to have it as an enhancement in my lap | 16:22.36 |
| chrisl | Robin_Watts: ah, the sensible approach..... :-) | 16:22.46 |
| mvrhel_laptop | that is what we have with the devn color type that I added | 16:22.58 |
| Robin_Watts | I wonder how many places in the code, we have 'color_is_pure' tests which are now failing because we have a devn color... | 16:23.34 |
| mvrhel_laptop | I fixed most of thpse | 16:23.45 |
| | those | 16:23.47 |
| Robin_Watts | Ah, ok. | 16:23.51 |
| mvrhel_laptop | AA is not in the regression test | 16:24.15 |
| | so was missed | 16:24.17 |
| Robin_Watts | Right. I wonder how many other things aren't in the regression test... | 16:24.42 |
| mvrhel_laptop | that, is always an issue | 16:24.57 |
| henrys | so first off marcosw should ping the customer with ray_laptop's question why are you using AA at 400 dpi agreed? | 16:25.08 |
| mvrhel_laptop | all the icc color stuff | 16:25.17 |
| | I should make a smoke test for that | 16:25.25 |
| | I think that was on my to do list at one point | 16:25.33 |
| chrisl | henrys: I'm pretty sure we've asked them about aa before and the reply was a useful "we have to..." or something similar. | 16:26.13 |
| ray_laptop | mvrhel_laptop: I thought that AA _was_ in marcos' nightly regression | 16:26.30 |
| marcosw | is anyone else having trouble with arifex email at google? I keep getting "Bad Request -- Error 400". | 16:26.47 |
| mvrhel_laptop | ray_laptop: don't know. maybe not for the tiffsep psdcmyk devices | 16:26.54 |
| ray_laptop | I think chrisl is right, but I still don't understand why | 16:26.57 |
| kens | marcosw nope, mine is OK | 16:27.01 |
| mvrhel_laptop | which is the only thing that this would effect | 16:27.03 |
| marcosw | I'm also having trouble connecting to my university account, also on google.com. But my personal gmail account works, odd. | 16:27.43 |
| mvrhel_laptop | so here we have a corner case of a particular device and an option | 16:27.48 |
| kens | marcosw is the nightly regrsssion working properly ? I keep getting the 'skiped' email even when I am reasonably sure thre are changes | 16:27.49 |
| Robin_Watts | I plan to put the downscaler into psdcmyk next. | 16:27.51 |
| ray_laptop | marcosw: gmail works for me (and POP to the gmail server) | 16:27.52 |
| marcosw | kens: I'll check. | 16:28.25 |
| ray_laptop | Robin_Watts: rather than piecemeal device changes, why isn't the downscaler just in the graphics lib ? (so the get_bits_* returns the downscaled image) | 16:29.30 |
| henrys | ray_laptop:read the logs | 16:29.50 |
| Robin_Watts | ray_laptop: It changes the size of the bits returned. | 16:30.09 |
| | and the depth of the bits returned. | 16:30.43 |
| | so it can't be just in getbits/getbits_rectangle. | 16:31.03 |
| marcosw | ken: turns out that the nightly regression failed because of an issue with a svn issue with jbig2dec/stamp-h1. SOrry I didn't notice. | 16:31.44 |
| kens | NP | 16:31.54 |
| henrys | so for marcosw we need the usefastcolor results and some sort of AA testing? | 16:32.24 |
| Robin_Watts | This seems like the path of least resistance. | 16:32.27 |
| henrys | chrisl:I'll search my email | 16:33.09 |
| marcosw | I'll send out the usefastcolor results later today and thought we already had regression testing of antialising, but presumably not. | 16:35.03 |
| henrys | chrisl:did you have a subject for the email on that? | 16:35.43 |
| | If we can get them not to use it is quite good - it's dog slow. | 16:36.08 |
| chrisl | henrys: no, sorry, I just vaguely remember it coming up before | 16:36.24 |
| henrys | marcosw:do you want to try and pass on ray_laptop's no aa suggestion to the customer. | 16:38.27 |
| | or was he talking directly with mvrhel_laptop | 16:38.42 |
| | ? | 16:38.43 |
| marcosw | I can do so (presuming my email starts working again). | 16:38.59 |
| Robin_Watts | henrys: Any news on moving away from gmail ? | 16:39.21 |
| henrys | Robin_Watts:ah yes thank you for reminding me. The current recommendation is communication with our customers and stay with email. Would you like me to forward out the discussion with the lawyer? | 16:40.16 |
| | s/email/gmail | 16:40.28 |
| Robin_Watts | i'd be very interested to read it. | 16:40.38 |
| henrys | will do. | 16:40.49 |
| Robin_Watts | I find it really hard to believe that we can seriously tell our customers "Oh, by the way, any confidential information you send to us is immediately shared with google." | 16:41.29 |
| henrys | kens I hope we aren't keeping you. | 16:41.33 |
| kens | Nope, but I was about to go anyway | 16:41.44 |
| ray_laptop | bye, kens | 16:41.58 |
| kens | G'night all | 16:42.08 |
| ray_laptop | (got it in early today) :-) | 16:42.10 |
| Robin_Watts | night kens | 16:42.21 |
| henrys | Robin_Watts:we will tell customers we use google as an mail host if you are concerned about the security of a particular message provide other means to send it to us. Probably need a contract update - miles won't like that. | 16:43.51 |
| | should I forward the correspondence to tech? Anyone else interested? | 16:44.50 |
| marcosw | I have to run, will be back in an hour. | 16:45.47 |
| alexcher | Why not just ask the users to encrypt sensitive communication? | 16:46.27 |
| henrys | alexcher:yes that will be one option. | 16:46.56 |
| Robin_Watts | alexcher: I can ask my dog to dance, but that doesn't mean she'll do it. | 16:47.18 |
| chrisl | It would complicate mails going to support | 16:47.31 |
| Robin_Watts | When scott sends out enquirys to customers, the response he gets probably contains commercially confidential information. (expected sales, details of business plans) | 16:48.29 |
| | so no more doing that by email. | 16:48.33 |
| | Henrys: One of your stated objections to running our own domain was that it couldn't go anywhere where someone might read your email because you have salary information in there. But it's OK for google to read that? | 16:49.28 |
| henrys | I don't consider the google threat as a real concern nor does the lawyer for reasons he stated. I see a legal issue that could come up with a litigious customer which I'd like to avoid with upfront language. | 16:51.16 |
| | google is one of the few companies actually using retinal scans on the folks that read your email ;-) | 16:55.54 |
| Robin_Watts | gets whiplash between reading the lawyers answer and miles' response. | 16:57.03 |
| | I think Miles has misunderstood "hosting" - but your subsequent emails cover the right ground. | 16:58.44 |
| henrys | yes that's why I jumped in. | 16:58.55 |
| Robin_Watts | So, a contract change would cover us for existing customers. | 16:59.17 |
| | I consider that there is probably a "reasonable expectation of confidentiality" when communicating in the runup to a contract though, and a customer could argue that by using google we are not meeting that standard. | 17:00.17 |
| | But IANAL, so... | 17:00.25 |
| henrys | your point is reasonable and I did not consider it, but I think we'll live with that glitch. | 17:01.15 |
| ray_laptop | generally, emails are assumed to only be somewhat secure, and anything really sensitive should be encrypted, right ? Every server that passes the data along can peek at it | 17:05.28 |
| henrys | ray_laptop:yes that is true. | 17:06.35 |
| | but I think the customer would have legal remedy in the case of eve packet sniffing. Google is saying they can read your stuff and it's okay. | 17:07.45 |
| ray_laptop | Does Amazon promise not to peek at our data on our server instance ? | 17:07.52 |
| henrys | I believe so. | 17:09.58 |
| | bbiab | 17:13.11 |
| Robin_Watts | gs/debugbin/gswin32c.exe -dFirstPage=1 -dLastPage=1 -r200 -sDEVICE=tiffsep -o ref.tif ../MyTests/pdf_reference17.pdf | 17:13.28 |
| | That's giving me a corrupt tif file (according to windows previewer at least), even when I back out my changes. | 17:13.53 |
| | Can anyone sanity check that please? | 17:14.00 |
| | hmm. gimp reads it OK. | 17:17.26 |
| | ray_laptop: You have windows 7, right? | 17:29.20 |
| ray_laptop | Robin_Watts: right. Win 7 Pro 64bit | 17:31.07 |
| Robin_Watts | Could you run the above command please and see if you can open the resulting ref.tif if the windows photoviewer? | 17:31.41 |
| ray_laptop | Robin_Watts: sorry -- I don't see a "Windows Photo Viewer". The "Program Files (x86)\Common Files\microsoft shared\PhotoEd.exe" opens it without complaint | 17:41.22 |
| Robin_Watts | ray_laptop: Just double click it in an explorer window. | 17:41.42 |
| | (Or right hand button on it and "Preview") | 17:43.08 |
| | The thumbnail I see is fine. | 17:43.19 |
| ray_laptop | damn. That opened it with Adobe Photoshop (which took forever to launch) | 17:43.31 |
| Robin_Watts | paint opens it. | 17:43.55 |
| | I think it's just something with photoviewer. Gah. That's wasted hours :( | 17:44.07 |
| ray_laptop | Robin_Watts: right-click and Open with.. shows me Windows Photo Viewer, and yes, it says the file is corrupt or too large | 17:45.07 |
| Robin_Watts | Right, fab. | 17:45.17 |
| | Thank you. | 17:45.22 |
| ray_laptop | Robin_Watts: but XnView, Photoshop and Quicktime PictureViewer and even MS "Paint" open it fine | 17:46.58 |
| | bbiab. | 17:53.55 |
| | mvrhel_laptop: henrys: I went ahead an posted the server mode timings on http://bugs.ghostscript.com/show_bug.cgi?id=693036 | 18:26.26 |
| mvrhel_laptop | wow | 18:27.22 |
| | that should put their issues to rest | 18:27.49 |
| ray_laptop | basically running from a single invocation of gs for 100 jobs is 5x faster and UseFastColor doesn't help the single invocation startup-shutdown timing at all | 18:28.05 |
| mvrhel_laptop | right | 18:28.19 |
| | that seems odd | 18:28.31 |
| | oh this is high level though | 18:29.23 |
| ray_laptop | mvrhel_laptop: the script I used (msys shell) was: time ( x=0 ; while [ $x -lt 100 ] ; do gswin32c -q -sDEVICE=ljet4 -q -o out/x-%d.pcl -dJOBSERVER -dUseFastColor ; x=$(($x+1)) ; done ) | 18:29.47 |
| mvrhel_laptop | with the high level devices, I don't really expect fastcolor to make much diff | 18:29.52 |
| | since you are really not doing any color conversions | 18:30.03 |
| ray_laptop | mvrhel_laptop: ljet4 is NOT high level | 18:30.04 |
| mvrhel_laptop | oh yes | 18:30.12 |
| | sorry | 18:30.14 |
| | I was thinking of their case | 18:30.22 |
| | that is even more puzzling then | 18:30.37 |
| ray_laptop | mvrhel_laptop: that is the mode on that bug | 18:30.40 |
| mvrhel_laptop | ah ok | 18:30.46 |
| | where fastcolor has a problem | 18:30.58 |
| | gotcha | 18:31.00 |
| ray_laptop | bbiab... | 18:32.37 |
| Robin_Watts | ok, that's tiffsep pushed. I'll do psdcmyk tomorrow. | 18:40.37 |
| | Time to render the first 10 pages of pdf_reference17.pdf at 200dpi and output to tiff = 5.2s | 18:41.25 |
| | Time to render the first 10 pages of pdf_reference17.pdf at 600dpi and downscale to tiff = 7.2s | 18:41.57 |
| | (downscale by a factor of 3, that is) | 18:42.16 |
| | oh, crap. pushed the wrong thing. some git patching will follow. | 18:43.35 |
| | Down to 6.5seconds. | 19:00.47 |
| marcosw | henrys: you around? | 19:22.21 |
| henrys | woops missed marcosw | 20:12.59 |
| dadada | hey | 21:15.24 |
| | I'm a coder in need of cash, and read about the bounty program, is there a fixed amount for p3 p4 p5 bugs? | 21:16.25 |
| | it can't hurt to learn something new either | 21:18.33 |
| henrys | http://www.ghostscript.com/Bug_bounty_program.html | 21:32.56 |
| dadada | k ty | 21:40.27 |
| | Forward 1 day (to 2012/05/23)>>> | |
IRC Logs