| | <<<Back 1 day (to 2012/12/10) | 2012/12/11 |
| phiscribe | ray_work_, sorry my ex showed up. looking at the file its does not have PS-Adobe or PDF-1.x in the begining it has "cush" followed on another line by "M.a.l.t." Does not seem to be a variant. | 01:02.39 |
| tor8 | Robin_Watts: http://ded.increpare.com/~locus/MMMMMM/ | 11:35.24 |
| paulgardiner | Coo! What a great game. That's this evening wiped out. | 11:46.01 |
| Robin_Watts | paulgardiner: Did you play VVVVVV ? | 11:46.31 |
| paulgardiner | Not that I know of. I've never heard of MMMMMM before. | 11:46.56 |
| Robin_Watts | VVVVVV is on steam. MMMMMM is a riff on it. | 11:48.04 |
| paulgardiner | ah right. | 11:49.40 |
| sebras | paulgardiner: but vvvvvv has a great soundtrack by souleye, so you really ought to try it! :) | 12:24.08 |
| paulgardiner | I definitely will, although I might wait for the Android version they are promising. | 12:25.01 |
| tor8 | paulgardiner: Robin_Watts: it's also on the humble store (same version as in the bundle, cross platform, unlike the steam one) | 12:25.04 |
| | http://thelettervsixtim.es/purchase.html | 12:25.04 |
| Robin_Watts | tor8, paulgardiner, henrys: "Forms" meeting in 15 mins? | 15:47.33 |
| Robin_Watts | fetches more caffiene. Unicode and jetlag are not a good mix. | 15:47.57 |
| paulgardiner | fetches decaffeinated tea, since he has neither Unicode or jetlag to deal with | 15:49.19 |
| Robin_Watts | You know the company we visited last week? Call them company X. The security team from company X has (indepenently of us visiting them) been testing MuPDF for memory issues etc. | 15:56.36 |
| henrys | paulgardiner:we ought to drag you along for one of these outings occasionally | 15:56.38 |
| Robin_Watts | They've just shared a 475Meg zip file of files with problems with me. | 15:57.16 |
| kens | Intriguing | 15:57.26 |
| paulgardiner | henrys: Yeah sure. I think I'd welcome being dragged. | 15:57.38 |
| kens | all security problems ? Or other stuff too ? | 15:57.39 |
| Robin_Watts | kens: I think they have their own memory tester stuff (like valgrind ish?) and they are trying it on open source projects. | 15:58.02 |
| kens | we did drag Paul to Heathrow | 15:58.12 |
| Robin_Watts | Sunny, far flung Heathrow. | 15:58.47 |
| henrys | well that's the dangerous part ;-) | 15:58.50 |
| paulgardiner | Robin_Watts: does that include leaks, or is it all segvs and overruns? | 15:59.49 |
| henrys | I've always been nervous about flying even though statistically I know the trip to the airport is more likely to get me. | 16:00.00 |
| Robin_Watts | paulgardiner: No idea. Still downloading the zipfile. | 16:00.05 |
| henrys | Robin_Watts: can you forward the message? | 16:00.23 |
| kens | http://www.theregister.co.uk/2012/12/11/scan_offers_tardis_pc_case/ | 16:00.58 |
| henrys | actually to support would be best | 16:00.59 |
| Robin_Watts | Suppose I was to sit in a 747 in normal service 24/7. For how long would I need to be flying on average for me to be involved in a fatal accident? | 16:01.33 |
| kens | wonders if 'Compasny X' will do Ghostscript too.... | 16:01.54 |
| Robin_Watts | kens: It may require us to run on their OS... | 16:02.14 |
| | (not sure) | 16:02.21 |
| kens | Hmm, good point | 16:02.37 |
| Robin_Watts | kens: actually... I have both gs and mupdf zips it seems. | 16:02.52 |
| kens | I guess we could do that :-) | 16:02.53 |
| | I suppose that answers the question then | 16:03.27 |
| Robin_Watts | and the gs one is the 475Meg one. Told you I'm suffering from jetlag... | 16:03.28 |
| | I'll upload them to casper. | 16:03.41 |
| henrys | paulgardiner:so we will change gears with this. Anything from them is top priority and we decided at the meeting getting the droid app on google play is high priority: with that we wanted XPS and being able to choose the app from a file selection. | 16:04.19 |
| Robin_Watts | (We want to be able to get the XPS intent stuff to work - click on an XPS file to launch the app) | 16:05.04 |
| | (and we want the existing file list to extend to other directories) | 16:05.33 |
| paulgardiner | henrys: Right. So put submission back on the shelve fore revisiting when we've sorted those things out. | 16:05.48 |
| Robin_Watts | paulgardiner mentioned that it may be possible to use the OpenIntent file viewer with mupdf. | 16:05.57 |
| henrys | II think that is the right thing to do. | 16:06.08 |
| Robin_Watts | In the mails from Raph he pointed out 2 problems with blending files. | 16:06.41 |
| | The first is due to us not supporting transfer functions (content is present, just not quite right) | 16:06.58 |
| paulgardiner | Robin_Watts: Yes, thought about it a bit more, and it may be very easy to create are own. Difficult to know whether that would be more effort than configuring the OI one the way we want it. | 16:07.22 |
| Robin_Watts | The second was due to a bug causing text to be missing (I have a fix, but the final colors are wrong due (I believe) to us always blending in the RGB space) | 16:08.02 |
| | BUT he said that those were probably not a priority and we might get a more urgent request for text selection. | 16:08.33 |
| henrys | Robin_Watts: presumably you or tor8 should handle the two bugs. | 16:08.42 |
| Robin_Watts | ... and annotation creation. | 16:09.16 |
| | henrys: right. | 16:09.25 |
| | I was just going to say that text selection/annotation creation may want to be ahead of submission too (whoever gets to code them) | 16:09.56 |
| | text selection is a purely android app thing - the core supports enough already. | 16:10.43 |
| henrys | right the annotations, now you said just an api but what about something demo like? it doesn't have to be full featured. | 16:10.52 |
| Robin_Watts | annotation creation is a bit of both. | 16:10.59 |
| | We need a core API to let us add them, and then UI work to hook up to that. | 16:11.36 |
| | The latter is (I suspect) a larger job. | 16:12.00 |
| paulgardiner | Both may involve a fair amount of work because of the appearance stream creation. | 16:12.39 |
| Robin_Watts | I was imagining that the API would work by taking an app created appearance stream. | 16:13.23 |
| paulgardiner | But that means the app needs to know details of PDF internal format. | 16:14.04 |
| tor8 | Robin_Watts: Hm, I'd have assumed the API would take a normal widget dictionary with the /Border and color and /Content set and create the AP | 16:14.14 |
| | Robin_Watts: or at an even higher level, pdf_create_circle_annotation() | 16:14.53 |
| Robin_Watts | paulgardiner: It would mean the app needs to know the pdf page marking operators, yes. | 16:14.53 |
| | The alternative is to duplicate all those operators within an interface: fz_move, fz_line, fz_color etc. | 16:15.36 |
| tor8 | Robin_Watts: I disagree. :) | 16:15.58 |
| Robin_Watts | tor8: As with everything there are a spectrum of possibilities. | 16:16.35 |
| tor8 | Robin_Watts: see table 8.20 (page 615 in pdfref17) | 16:16.56 |
| Robin_Watts | We could certainly have a 'simple' API for creating text annotations (rectangle, color, text, font etc), but to generate annotations in full generality, we need to be able to take appearance streams. | 16:17.34 |
| | And having the API for taking appearance streams does not preclude us having 'simpler' options later. | 16:18.00 |
| paulgardiner | As it's relevant to this, I should mention I've been wondering about the approach I've taken to AP generation for forms: I wonder if I'd have been better to create a display list and convert it to an AP | 16:18.09 |
| tor8 | the higher level annotation types must be supported for editing annotations | 16:18.26 |
| | the AP I believe is just a way for viewers who can't synthesize annotations to render new annotation types | 16:18.50 |
| paulgardiner | If not display lists, some sort of simple PDF-independent structure that can be converted into an AP | 16:19.29 |
| tor8 | now we should be able to preserve the existing AP unless you edit an annotation, but if you edit it I would imagine the client wanting to edit the high level info and get the AP generated automatically | 16:19.37 |
| paulgardiner | ... but is easier to construct and edit | 16:19.39 |
| tor8 | and an unsupported /Subtype would be read-only | 16:19.56 |
| henrys | Robin_Watts: are the memory problem cored mupdf or the gui? | 16:20.07 |
| | s/cored/core | 16:20.14 |
| Robin_Watts | tor8: Hmm. I hadn't considered editing existing annotations. You're right of course. | 16:20.29 |
| tor8 | Robin_Watts: for just creating annotations, punting the work to the client is reasonable. but we do want a proper api to be able to edit them, which means having to generate content streams for all types | 16:21.06 |
| Robin_Watts | paulgardiner: If we want to offer a format-independent way of defining annotations appearance streams then a display-list based method seems reasonable. | 16:21.53 |
| | Does XPS have a concept of annotations ? | 16:22.01 |
| | henrys: Dunno yet. | 16:22.30 |
| paulgardiner | Robin_Watts: I've never looked at the form of our display lists, but I'd guess that it was the right sort of thing. | 16:22.32 |
| tor8 | Robin_Watts: not that I've seen, no. and hopefully given the amount of attention XPS gets these days, I don't think it ever will. thankfully. | 16:22.38 |
| Robin_Watts | hmm. The mupdf test file is 1.4Gig - so I can't answer henrys question until I've downloaded it. | 16:23.37 |
| tor8 | Robin_Watts: paulgardiner: so basically a PDF Annotation Presentation content stream generating fz_device | 16:23.38 |
| | which only supports the basic vector and font operators | 16:24.01 |
| Robin_Watts | tor8: A content stream generating fz_device sounds like a subset of the pdfwrite device. | 16:24.11 |
| tor8 | or maybe it can be abstracted up to something easier than that | 16:24.13 |
| | Robin_Watts: indeed it does :) | 16:24.21 |
| paulgardiner | tor8: that does sound like the beast we need | 16:24.23 |
| tor8 | we'd have to have some rudimentary text layout engine that creates fz_text nodes | 16:24.55 |
| paulgardiner | Robin_Watts: Yes. good point | 16:25.01 |
| Robin_Watts | I have such a device (supporting vectors and text (with no font choice)) | 16:25.07 |
| tor8 | paulgardiner: did you get around to what we discussed ages ago about built-in fonts in APs? | 16:25.24 |
| paulgardiner | tor8: Hmmm, no. :-( | 16:25.57 |
| tor8 | paulgardiner: right. cause that would probably tie into this as well. but you could probably hold off on fixing it until we implement the fully general annotation creation api. | 16:26.32 |
| | I think we should always use one of the base14 fonts for annotation streams, maybe reuse the existing font descriptor objects if they meet our criteria about being base14 and having a proper font encoding. | 16:27.33 |
| | otherwise create a new set of standard templated font descriptors | 16:27.47 |
| paulgardiner | Presumably for form text widgets, we don't want to use builtin fonts unless we have to, because we want the text to display in the font the form designer chose | 16:28.12 |
| tor8 | paulgardiner: we should scan through our existing forms files and see which fonts they actually use | 16:28.46 |
| | it would be good to know | 16:28.49 |
| paulgardiner | Yes | 16:29.10 |
| tor8 | my guess is they're all winansi or pdfdocencoding based | 16:29.16 |
| | on the base14 or standard windows fonts that map trivially to the base14 | 16:29.29 |
| Robin_Watts | presumably with forms we should use whatever font is defined for each given field (possibly, we should scan to check that all the chars in the data have glyphs defined, and if not, drop back to a base font?) | 16:29.49 |
| tor8 | Robin_Watts: well, the problem is what happens when we try to encode new text? | 16:30.13 |
| Robin_Watts | In case someone adds a name with an accent or something that would mean that char would be dropped. | 16:30.33 |
| tor8 | if devilishly constructed, we'll get garbage or missing characters due to illegible encodings or subset fonts | 16:30.45 |
| henrys | I'd like to drop out at the 1/2 hour - do we agree paul should work toward getting us to google player state next week and not worry about the list until that is done? | 16:31.03 |
| Robin_Watts | yes. | 16:31.12 |
| tor8 | Robin_Watts: yeah. that's what we shouldn't. or maybe just a toggle for "use old font / replace with new font" in the API | 16:31.16 |
| | henrys: yes. | 16:31.35 |
| paulgardiner | Ok. I'll get on to that. | 16:32.01 |
| henrys | Robin_Watts: share whatever you get with marcos if it breaks mupdf it should be looked at in ghostscript also. | 16:32.25 |
| paulgardiner | Robin_Watts, tor8: there's a couple of commits on paulg/master btw, when you get a chance. | 16:33.16 |
| tor8 | Robin_Watts: depending on whether we expose pdf_obj's or some higher level pdf_annotation_font object as the API, we could just use a pdf_obj that's an indirect reference for the font, have a function to create a new base14 font and fontdescriptor, and call it a day | 16:33.23 |
| | so you'd pdf_obj *times = pdf_create_annotation_font("Times Roman"); pdf_annot_set_font(annot, times); | 16:34.04 |
| | makes sense? | 16:34.09 |
| | Robin_Watts, paulgardiner: we should probably set up a skype call to discuss the annotation API later on once paul's dealt with the google playability issues | 16:35.40 |
| Robin_Watts | tor8: sure. | 16:36.24 |
| paulgardiner | I'd better get a skype account. :-) | 16:41.49 |
| tor8 | paulgardiner: is it difficult to launch a browser activity? | 16:41.54 |
| | (re the GoToR / URI link types) | 16:42.07 |
| paulgardiner | tor8: I don't think so. Are you thinking external links? | 16:42.19 |
| tor8 | paulgardiner: I'm thinking external hyperlinks pointing to http:// yes | 16:42.39 |
| paulgardiner | Yeah, I don't think it's any harder than opening the outline intent | 16:43.16 |
| | Done in exactly the same way I imagine, although I haven't checked | 16:43.37 |
| tor8 | GoToR is a bit tricky though, the targets can be embedded PDF documents and all sorts of other crap | 16:45.56 |
| | oh wait, that's GoToE | 16:46.14 |
| Robin_Watts | tor8: I think we can usefully ignore the page/rectangle targets in GotoR for now. | 16:46.53 |
| tor8 | file specifications will need to be cracked and converted somehow | 16:47.08 |
| | Robin_Watts: could we use/abuse the uri#fragment syntax for page numbers? | 16:47.25 |
| Robin_Watts | tor8: Possibly, yes. | 16:47.40 |
| | request probably better? | 16:47.55 |
| tor8 | how does acrobat do it? :) | 16:48.04 |
| Robin_Watts | ?page=1&rect_x0=0&rect_x1=0 etc | 16:48.18 |
| | no idea how acrobat does it. | 16:48.25 |
| tor8 | #pagenumber or ?page=X would both be fine I think | 16:48.54 |
| | maybe ever #NamedDestination | 16:49.05 |
| | even* | 16:49.09 |
| Robin_Watts | ? would allow us to pass rectangles etc too. | 16:49.39 |
| | but either way is probably fine, yes. | 16:49.49 |
| | The Unicode/Windows comments from Sags can be found here: http://bugs.ghostscript.com/show_bug.cgi?id=692381#c8 | 16:55.03 |
| | A and B are simple fixes, and I think he's right. | 16:55.24 |
| | C is where the problem is. | 16:55.34 |
| | I think the 'push back' thing needs fixing. | 16:55.53 |
| | But I'd really like to solve for multi-byte inputs too. | 17:03.51 |
| chrisl | tkamppeter: ping | 17:20.35 |
| henrys | hmph ./gs @ | 18:47.56 |
| | Segmentation fault: 11 | 18:47.57 |
| | alexcher:will you look at that or should I create a bug? | 18:49.02 |
| Robin_Watts | I'm in the middle of the arg processing code at the moment. | 18:49.48 |
| henrys | this could be funner than unicode but I doubt it. | 18:50.23 |
| Robin_Watts | It's cos of the unicode stuff that I'm here :( | 18:51.04 |
| henrys | it is a user error but it shouldn't crash | 18:51.07 |
| | yes I know | 18:51.13 |
| ray_work_ | henrys: so it's using the @ with no following argument (for the file to take further args from) ? That should be really easy -- someone not checking argc | 19:06.29 |
| | henrys: does it bomb on PCL as well ? | 19:06.40 |
| Robin_Watts | ray_work_: You've not looked at the gs arg handling code recently, have you? :) | 19:07.20 |
| ray_work_ | Robin_Watts: are you looking at Wndows unicode issues (command line args) for PCL ? | 19:07.44 |
| Robin_Watts | for both gs and pcl, yes. | 19:07.56 |
| ray_work_ | Robin_Watts: no, not in the last couple of years | 19:07.58 |
| henrys | both pcl and gs crash on the mac | 19:09.07 |
| ray_work_ | Robin_Watts: arg_next _should_ return NULL if there are no more args. And imainarg.c checks psarg for NULL and exits | 19:14.16 |
| Robin_Watts | ray_work_: Right, but arg_next is a nasty rats nest of quoting code, push backs, nested @ files etc. | 19:15.09 |
| | and I'm making it worse :) | 19:15.34 |
| ray_work_ | Robin_Watts: oh, yes. I see in the "at:" code: | 19:19.25 |
| | result++;/* skip @ */ | 19:19.27 |
| | f = (*pal->arg_fopen) (result, pal->fopen_data); | 19:19.28 |
| | without checking that *result in not 0 | 19:19.30 |
| Robin_Watts | ray_work_: Ah. I've not even started to look yet as it's all in pieces around me, but yes, that seems plausible. | 19:20.14 |
| ray_work_ | oops have to go | 19:20.19 |
| | bbiab | 19:20.26 |
| mvrhel_laptop | bbiaw | 20:39.05 |
| alexcher | henrys: there's already a bug about SEGV when the command file cannot open. | 23:02.57 |
| | henrys: the segv is caused by an attempt to search library files before the associated structures are initialized. | 23:04.17 |
| | henrys: It's bug 693026 - @filename option fails | 23:38.35 |
| | Forward 1 day (to 2012/12/12)>>> | |
IRC Logs