| | <<<Back 1 day (to 2013/04/22) | 2013/04/23 |
| henrys | mvrhel_laptop:yes it removes everything not actually part of the tree I use it a lot but it is dangerous, obviously. | 00:17.53 |
| ray_laptop | mvrhel_laptop: I tripped over the same BS last week (and henrys reminded me to consult chrisl's email). IMHO, breaking the git repo so you need to do "git clean -f- -x -d" is almost as bad as breaking the build, but maybe I'm expecting too much of git. | 05:11.22 |
| | but it also cost me a few hours of trying to make sure my repo was up to date and then mentioning it on IRC (where henrys clued me in to chrisl's email) | 05:12.38 |
| mvrhel_laptop | ray_laptop: I was scratching my head on that one | 05:13.49 |
| | I only burnt up about 20 minutes though | 05:14.00 |
| ray_laptop | but since the windows build didn't need it, the email had drifted into the list of old emails. It wasn't until I tried a build on peeves that I had problems | 05:14.04 |
| mvrhel_laptop | ray_laptop: so I didn't get a chance to show you the odd thing I found with high level images | 05:15.06 |
| | we can chat about it tomorrow | 05:15.53 |
| ray_laptop | mvrhel_laptop: well, since peeves takes a while to rebuild from clean (I don't use -j5 after a problem since that occludes build issues) and I forgot to redo the "autogen.sh" it was a couple of hours (allowing for interruptions) | 05:15.55 |
| mvrhel_laptop | ah ok | 05:16.06 |
| ray_laptop | before henrys responded to me | 05:16.08 |
| | so tomorrow we can chat about any remaining HL image issues. That OK ? | 05:17.16 |
| mvrhel_laptop | yes. that is fine | 05:17.22 |
| | I have a pile of segvs that came up for some odd reason that I am going to look at now | 05:17.43 |
| | once I figure that issue out, then I am hoping to push this off to you ray_laptop | 05:18.02 |
| | I did get all the unpack cases in place btw | 05:18.20 |
| ray_laptop | great. I found an issue with the psdcmyk and BGPrint=true that was a simple fix, but trying to get my repo back to run a test | 05:18.23 |
| | OK, I think I have my repo close enough to clusterpush. Trying it now | 05:21.41 |
| mvrhel_laptop | aha. found my problem | 05:36.32 |
| | ok things seem to be running this time | 06:07.50 |
| | darn still some issues | 06:26.44 |
| | will tackle those tomorrow | 06:26.48 |
| Robin_Watts | tor8, paulgardiner: ping | 11:21.31 |
| paulgardiner | hi | 11:21.40 |
| Robin_Watts | tor8: I pushed my commit, and your one, thanks. | 11:21.44 |
| | paulgardiner: I pushed a commit this morning that I'd hoped would solve the occasional segvs in mujstest, but they don't appear to have gone away. | 11:22.17 |
| | which is annoying, cos in my cluster runs I thought they had. | 11:22.29 |
| | but to another problem... | 11:22.44 |
| | I have the code so its extracting images in with the text. | 11:23.02 |
| | (no attempt to reorder the images, just in the order they are emitted) | 11:23.15 |
| | and I thought I'd output them as data URLs within the html to save having to do separate files. | 11:23.47 |
| | but it turns out that data URLs are very limited. | 11:23.57 |
| | some browsers limit them to 2Meg, some to 32K, officially I think the html limit is 2Kish for the whole image tag. | 11:24.32 |
| | so unless we can think of a smarter solution, we may have to start outputting multiple files. | 11:25.06 |
| | any ideas? | 11:25.13 |
| | mhtml ? | 11:25.42 |
| paulgardiner | Yeah, mhtml is my only thought so far. | 11:26.46 |
| | If we ever create our own reflow view then we can use whatever format we like. | 11:27.39 |
| Robin_Watts | paulgardiner: Right. This is specifically for reflow via "html" | 11:28.05 |
| paulgardiner | Ah, this is not just for reflow | 11:28.07 |
| | Oh it is! | 11:28.28 |
| | Do you know what limit webview has fore data urls? | 11:28.48 |
| Robin_Watts | The output of the text device is our "page contents" structures; (blocks/lines/chars/etc, images) | 11:29.07 |
| | The other routines to output that to text, xml, html etc are all separate things. It just happens that for reflow we are currently using the html one. | 11:29.47 |
| | but we could write a native reflow thing. | 11:29.54 |
| | (Or we could write our own javascript based reflow thing within an html page. Put the page contents out as 'divs' of html and then have the javascript juggle it around the page) | 11:30.37 |
| | I don't know about webview. | 11:30.50 |
| paulgardiner | I was just thinking, if your target is only to support reflow, then it is only the webview limit you care about, not other browsers | 11:31.37 |
| Robin_Watts | except we use it in the windows 8 viewer too. | 11:32.20 |
| | and potentially in ios. | 11:32.27 |
| Anderssen | hi @all, I was wondering if it's the case that ghostscript cannot directly convert a png into a pdf file? | 11:32.52 |
| paulgardiner | Robin_Watts: they may all be based on the same engine. | 11:33.05 |
| Robin_Watts | Anderssen: gs cannot no. but... | 11:33.19 |
| paulgardiner | not that necessarily helps | 11:33.21 |
| Anderssen | ok, then I might use convert from imagemagick | 11:33.38 |
| Robin_Watts | there is a tool provided with gs in the lib directory called (something like) viewlib.ps | 11:33.40 |
| Anderssen | oh ok | 11:33.53 |
| Robin_Watts | and if you run that in gs, you can convert jpegs and (I think) pngs. | 11:34.06 |
| Anderssen | @Robin_Watts: thanks, I'll look into it | 11:34.47 |
| Robin_Watts | paulgardiner: the android webview browser is based on the same thing chrome is, I believe, which is WebKit. | 11:35.06 |
| | or was webkit until they forked it a couple of weeks back, IIRC. | 11:35.20 |
| | ios is based on safari, which is again webkit. | 11:35.33 |
| | Win8 will be IE based. | 11:35.39 |
| paulgardiner | I have some (possibly incorrect) memory if iOS webview being based on webkit | 11:35.55 |
| | You said that. :-) | 11:36.05 |
| Robin_Watts | mhtml seems a sensible way to go. I shall experiment with that. | 11:37.16 |
| | First I should check to see if webview can view html of course :( | 11:37.35 |
| | paulgardiner: When you did the PDF fonty stuff for our previous employers, did you do anything with vertical motion? | 11:38.11 |
| paulgardiner | No. I don't think we ever handled that. | 11:39.04 |
| Robin_Watts | I'm sure we did handle it - we were big in Japan, right ? | 11:39.42 |
| paulgardiner | Hmmm, I can't remember viewing any test documents that used it. | 11:41.50 |
| Robin_Watts | me either, but I can't believe we wouldn't have had bug reports about it, given their primary area of success was selling into CJKV markets. | 11:42.31 |
| paulgardiner | I also think I can remember the dread of thinking it was something I might have to add support for. | 12:13.04 |
| natronite | quick question. How can I use RGB_565 in mupdf? | 12:33.50 |
| tor8 | natronite: you can't. we don't support 16-bit color. | 12:40.18 |
| natronite | too bad. but thanks :D | 12:40.37 |
| tor8 | your best option is to render to RGB and then convert down to 565 | 12:40.40 |
| | there's a function to do it in apps/x11_image.c | 12:40.57 |
| natronite | Ok. I'll check it out | 12:41.19 |
| tor8 | we need to support converting to 565 for display on some X11 servers, but we don't render using that pixel format internally | 12:41.42 |
| | so that conversion happens in the X11 viewer | 12:41.56 |
| natronite | well I'm on Android | 12:42.21 |
| | and I'd just like to have smaller bitmaps, that's why | 12:42.40 |
| | but we'll work with what we have | 12:42.51 |
| tor8 | right. so the OS will probably have some way to convert the bitmaps. I'm not an android expert though. | 12:42.58 |
| | or just work with what you have. if you don't care about color, you can render to grayscale as well. | 12:43.11 |
| | that halves the memory used by the pixmaps | 12:43.20 |
| paulgardiner | Robin_Watts, tor8: So do I add some sort of signature checking function to MuPDF's API, which would be simple for app writers, but will make MuPDF depend on openssl, or do I add a number of signature interrogating functions to MuPDF that will allow apps to get the information they need to perform the check (although that still means the apps depend on openssl)? | 12:50.06 |
| Robin_Watts | paulgardiner: It would be bad to have mupdf depend on openssl in all cases. | 13:13.08 |
| paulgardiner | Yes. I'll go for option 2. We can always roll up the checking routines as a small separate library if we want to share them among apps. | 13:14.20 |
| Robin_Watts | Having generic signature interrogation routines sounds good, as that allows other people to integrate with their own functions if they have them. | 13:15.03 |
| paulgardiner | Or make them optionally compiled | 13:15.10 |
| Robin_Watts | (I could imagine that embedded devices would probably have some sort of signature thing built in) | 13:15.24 |
| | and providing some helper functions that integrate them with openssl helps app writers. | 13:15.47 |
| | Akin to how we (you) did the js stuff. | 13:16.05 |
| paulgardiner | Yeah | 13:20.07 |
| tor8 | yeah. I'd rather not require openssl as a thirdparty dependency. | 13:25.19 |
| | so go with option 2 for now | 13:25.26 |
| paulgardiner | Ok good. | 13:26.11 |
| Robin_Watts | I got the data URLs working in chrome. | 13:26.55 |
| | but I think I should move to base64ing them as it'll save space overall. | 13:27.31 |
| pgogna | hello every one | 14:00.38 |
| | I tried Robin's suggestions to implement smart zoom in muPDF | 14:01.23 |
| | I have some questions | 14:01.30 |
| | I would be grateful if someone could answer them | 14:02.00 |
| Robin_Watts | pgogna: Go for it. (In general, just ask questions, don't ask to ask. irc has a degree of lag built in) | 14:02.36 |
| pgogna | First Question : Is there any way to detect images on double tap? Or, can we only get the bounding box of text? | 14:03.29 |
| Robin_Watts | pgogna: At the moment, only text. When I get the commit in that I'm working on, then you'll be able to detect images too. | 14:04.30 |
| pgogna | 2nd Question : Can you point us to a resource where I can learn to compile muPDF for iOS? Or is there a resource to download precompiled (fat?) library? | 14:04.37 |
| | 3rd question : By when can we expect this commit for detecting changes? | 14:05.11 |
| Robin_Watts | pgogna: iOS questions need to be directed at tor8, who will probably mumble and grumble a lot about how crap apple are at keeping Xcode projects working between revisions. | 14:05.31 |
| | what commit for detecting what changes ? | 14:05.44 |
| | for detecting *images* ? | 14:05.59 |
| pgogna | Bounding box of image | 14:06.06 |
| | yes | 14:06.11 |
| Robin_Watts | a few days to a week, I guess. | 14:06.43 |
| pgogna | thanks | 14:06.52 |
| Robin_Watts | possibly less if we know we have someone waiting for it. | 14:06.53 |
| pgogna | :) | 14:07.01 |
| Robin_Watts | We have a meeting scheduled here at 4pm (and another at 5), so tor8 should look ircwards around about then. You may be able to catch him just before/just after the meetings. | 14:08.06 |
| pgogna | What time zone? | 14:09.30 |
| | Robin, please excuse my ignorance, I am new to PDF. I have written some code. Do you mind reviewing if that is correct or that I am on the right path? | 14:09.31 |
| Robin_Watts | pgogna: Sorry. I'm in the UK. so 4pm is a little under an hour away. | 14:10.04 |
| | pgogna: Feel free to put it online for us to look at. I can't promise to devote huge amounts of time to it, but I will try to have a look, sure. | 14:10.43 |
| pgogna | I understand, thanks anyways, it would be great however it would be nice to have smart zoom in mupdf, i am sure for someone fimiliar with pdf library creation it could be a small task | 14:11.42 |
| | thanks | 14:11.45 |
| henrys | I wonder if it will ever stop snowing we're headed for a record April | 14:13.16 |
| kens | snow ? :-O | 14:13.23 |
| pgogna | JNIEXPORT void JNICALL JNI_FN(MuPDFCore_calculateBoundingBox)(JNIEnv * env, jobject thiz) { globals *glo = get_globals(env, thiz); fz_context *ctx = glo->ctx; fz_document *doc = glo->doc; int pagenum = glo->current; fz_rect fz_infinite_rect = { 1, 1, -1, -1 }; fz_matrix fz_identity = { 1, 0, 0, 1, 0, 0 }; fz_text_page *text = NULL; fz_page *page; fz_display_list *list = NULL; fz_device *dev = NULL; fz_cookie cook | 14:13.46 |
| | Sorry | 14:15.23 |
| | try this | 14:15.27 |
| | http://pastebin.com/miwqMcDb | 14:15.31 |
| Robin_Watts | pgogna: OK, you are right to wrap the calls with fz_try/fz_catch | 14:16.46 |
| | This means that if the library has problems, it will throw exceptions and you'll catch them. | 14:17.26 |
| | You can't then rethrow them from your catches however, as there is no enclosing fz_try/fz_catch to handle them. | 14:17.59 |
| pgogna | thanks, hmm | 14:18.28 |
| Robin_Watts | fz_try/fz_catch, while looking superficially similar to the java exception stuff, are actually completely different. | 14:18.29 |
| pgogna | Will we get bounding box in fz_infinite_rect? | 14:19.17 |
| Robin_Watts | In the code as written there, you will always have list == NULL | 14:19.59 |
| | In practice, when you're running, I'd expect that the viewer will always have the display list for the current page around. | 14:20.37 |
| | hence you can probably avoid the fz_load_page call. | 14:20.47 |
| | and just use fz_run_display_list | 14:21.02 |
| pgogna | hmm | 14:21.03 |
| Robin_Watts | So, your code gets the page, and runs the page. | 14:21.52 |
| | The output from this is that the fz_text_sheet and fz_text_page structures are filled out. | 14:22.15 |
| | You'll need to walk those structures to find out where the text is, with the bboxes etc. | 14:22.49 |
| | In your code as written fz_infinite_rect is never even used. | 14:23.09 |
| | as list is NULL. | 14:23.19 |
| pgogna | But to run the fz_run_display_list we need "dev" and for that we need "text" and for that we need page and to get the page i am trying to load it | 14:23.28 |
| | ok | 14:23.37 |
| Robin_Watts | even if list was non-NULL fz_infinite rect would never be altered. | 14:23.39 |
| | pgogna: Right. | 14:24.08 |
| | So either you need to fz_load_page, or the viewer app will have the current page around somewhere. | 14:24.28 |
| | I suspect the latter. | 14:24.32 |
| pgogna | ok i will try to find out the current page around | 14:25.13 |
| Robin_Watts | henrys: we've got a nice really sunny day here. makes a change. | 14:26.34 |
| tor8 | d'oh. missed pgogna so I lost my chance to grumble and mumble about Xcode :( | 14:36.56 |
| Robin_Watts | :) | 14:37.20 |
| tor8 | anyway, the Xcode project in the "ios" directory should work out of the box | 14:37.37 |
| | if the conjunction of stars is just right so that apple hasn't broken something | 14:38.07 |
| Robin_Watts | tor8: I'm tweaking fz_write_png so that it calls a subsidiary function to do the work. | 14:38.30 |
| | the subsidiary function will write to an fz_output rather than to a file. | 14:38.45 |
| | That way I can have another wrapper function that calls the same subsidiary to do pixmap -> png in a buffer. | 14:39.06 |
| kens | henrys could you reduce a PCL file for me ? | 14:39.51 |
| henrys | kens:yes | 14:40.08 |
| kens | I have a class of problems edxhibited by ieee0495.pcl, there are rectangles filled with a btimap pattern | 14:40.48 |
| | If you could get me a file with just one of those I would be grateful. The ones in ieee0495 are on page 1 | 14:41.15 |
| henrys | kens:okay I'm reviewing now for the mupdf meeting but will get to it soon. | 14:43.46 |
| kens | No rush | 14:43.52 |
| | I have 85 pages of diffs to look at | 14:44.05 |
| tor8 | Robin_Watts: sounds good | 14:44.12 |
| Robin_Watts | woo hoo! text + image extraction => html is working (using data URLs) | 14:45.24 |
| | tor8: Should fz_print_text_page_html automatically do images too? | 14:46.54 |
| tor8 | Robin_Watts: didn't you run into a size limit on data urls? | 14:47.04 |
| Robin_Watts | or do we want another function (fz_print_text_page_html_with_images) ? | 14:47.14 |
| | tor8: I thought I did, but it transpired to be me cocking up my encoding. | 14:47.30 |
| tor8 | I'd let it do images too | 14:47.32 |
| | maybe have a flag to the text device to ignore images instead | 14:47.45 |
| Robin_Watts | It's still quite possible that we'll hit data url limits on some things. | 14:47.49 |
| tor8 | which would be handy for text search etc so we don't have to decode images | 14:47.59 |
| Robin_Watts | tor8: We never decode the images. | 14:48.10 |
| tor8 | or load them into memory :) | 14:48.26 |
| Robin_Watts | We get passed an fz_image over the device interface - so they are in memory by then. | 14:48.35 |
| | all we do is take a reference to them, which holds them in memory. | 14:48.50 |
| | so yes, a flag would be good. | 14:48.54 |
| | for JPEGs we can just parrot the data out again, so no decode is required. | 14:49.11 |
| | for PNGs too (though we don't get pngs in pdf) | 14:49.21 |
| | for any other type I get it as a pixmap, and output it as a png. | 14:49.36 |
| tor8 | Robin_Watts: the text device sets a device flag for the interpreter to skip images and shadings | 14:49.55 |
| Robin_Watts | With this code in now, we're in a position to move forwards a bit with pdfwrite in that we can now parrot out pretty much all images without recompressing. | 14:50.19 |
| | tor8: yeah. | 14:50.30 |
| | tor8: eh, hold on... | 14:50.48 |
| tor8 | so unless you've changed that, something must be buggy if you're getting images out :) | 14:51.10 |
| Robin_Watts | the text device can't be setting that flag to ignore images, otherwise I wouldn't be seeing images :) | 14:51.11 |
| | right. | 14:51.55 |
| | If we go via the display list, I get images. | 14:52.08 |
| henrys | kens:as I look at this pattern stuff it won't make any difference - pcl patterns are always bitmaps at 300 or 600 dpi bitmaps but it's good to have PCL work like the other languages I suppose. | 14:52.09 |
| Robin_Watts | If we don't, then I don't :) | 14:52.14 |
| kens | henrys : yes and some results are much improved | 14:52.25 |
| henrys | kens:I do know we have some non deterministic behavior with patterns pcl -> pdfwrite | 14:53.20 |
| Robin_Watts | 8 minutes to meeting. tea time | 14:53.27 |
| henrys | kens:I'm hoping those go away. | 14:53.36 |
| kens | henrys its not so much non-dxeterministic as improved rendering | 14:59.08 |
| henrys | isn't there a documented limit on url limits or is is implementation dependent? | 14:59.12 |
| Robin_Watts | henrys: There is a documented limit on the length of any given html tag. | 14:59.43 |
| | specifically 2K or so. | 14:59.49 |
| | so an image tag that includes a data URL is limited to 2K. | 15:00.06 |
| henrys | kens:every cluster job I send shows indeterms in pcl patterns with the pdfwrite device. At least the bmpcmp leads me to believe that. | 15:00.26 |
| Robin_Watts | but (from reading between the lines of my googling) it seems that most current engines are fine. | 15:00.31 |
| kens | henrys, yes on a very small number of jobs that is true, I think its more to do with palettes than patterns | 15:01.00 |
| Robin_Watts | mhtml looks like a non-standard pit of snakes that we could brave if we want to. | 15:01.00 |
| henrys | so I'll start the meeting with the obligatory localization nagging for tor8 and Robin_Watts. | 15:01.13 |
| Robin_Watts | henrys: OK, we're almost in a position to press the button. | 15:01.31 |
| | It's all a question of how much we want to spend. | 15:01.38 |
| | Doing everything will cost us ~ $1000 I think. | 15:01.53 |
| henrys | Robin_Watts:that's the one yes. | 15:02.09 |
| Robin_Watts | so I'll press the button and give 'em my card details and send Miles an invoice. | 15:02.34 |
| henrys | if we start selling this thing you guys won't have to work on ghostscript ;-) | 15:02.36 |
| Robin_Watts | but I like working on ghostscript (sometimes). | 15:02.54 |
| mvrhel_laptop | good morning | 15:03.05 |
| henrys | mvrhel_laptop:what is the status of the windows viewer. I think paulgardiner should have a review of it to make sure you guys are going in the same general direction. Would that make sense? | 15:05.01 |
| mvrhel_laptop | henrys: give me another week. I need to do some serious clean up | 15:05.26 |
| henrys | mvrhel_laptop:okay | 15:05.35 |
| mvrhel_laptop | this auto color in gs has delayed me a bit | 15:05.40 |
| | I am hoping to have that wrapped up today | 15:05.47 |
| henrys | paulgardiner: I was going to suggest you also look at itext but it looks like you are digging yourself out of signature hell. | 15:06.08 |
| Robin_Watts | mvrhel_laptop: I sent a "holding" message to Raed today about the winmd stuff. | 15:06.20 |
| mvrhel_laptop | Robin_Watts: ok. I will look at that today | 15:06.51 |
| paulgardiner | henrys: I'm possibly still digging myself INTO signature hell. Not confident I've as yet found how deep it goes. :-) | 15:07.14 |
| henrys | well itext seems to have java code to do everything for pdf signing haven't looked carefully. | 15:07.50 |
| paulgardiner | But what is itext, though? | 15:07.51 |
| Robin_Watts | http://itextpdf.com/ | 15:08.27 |
| henrys | itextpdf.com | 15:08.30 |
| tor8 | paulgardiner: library for creating pdf files | 15:08.38 |
| paulgardiner | Oh right. Useful | 15:09.05 |
| tor8 | and doing some basic manipulations, somewhat like pdfclean does | 15:09.20 |
| henrys | bbia second | 15:09.20 |
| tor8 | sorry, mutool clean :) | 15:09.27 |
| henrys | back sorry | 15:13.21 |
| Robin_Watts | ok, I've set the first batch of translations going on oneskyapp. This for the google play description. | 15:13.24 |
| | It's not clear to me from the interface whether we also get a translation for all the strings too in that price. | 15:13.50 |
| | so I'm going to wait for this to complete (should only take a day) before spending any more money. | 15:14.07 |
| | tor8: Company 530 were asking whether you'd had any luck with the polygon plotter rewrite ? | 15:15.03 |
| henrys | so I also wanted to talk about svgwrite which we have a customer request for now. I'd like to make that a mupdf project if the customer would use mupdf for svg writing needs. | 15:15.55 |
| Robin_Watts | My (aged) memory of SVG is that it's a lot easier to write than pdf. | 15:16.38 |
| tor8 | Robin_Watts: sorry, got distracted by having to unclog the kitchen sink drain so I may not get that done until tomorrow | 15:16.46 |
| Robin_Watts | tor8: ok. I'll tell them it's next on your list then. | 15:17.28 |
| | henrys: What is the relative priority of svgwrite vs text/image extraction ? | 15:18.07 |
| paulgardiner | henrys: I've downloaded the itext source. Were you thinking it might answer some questions regarding signatures, or did you have other purposes in mind? | 15:18.46 |
| Robin_Watts | We also have a vertical text motion bug that I've got to look into. | 15:19.07 |
| | I *hope* I've solved customer 530s problems with multi-threading, but we'll have to see. | 15:19.29 |
| henrys | Robin_Watts:It seems like you have plenty on your plate what about tor8? | 15:20.26 |
| | I don't know about the priority yet. | 15:20.58 |
| Robin_Watts | henrys: I just farmed a customer 530 problem out to tor8. They have some files that are stupidly heavy on shadings. | 15:21.19 |
| | we've done various tweaks to the code to make it faster, and they are happy, but it has revealed a problem in that lots of files that use shadings have 'poor' mesh quality | 15:22.01 |
| | and consequently you can get white pixels showing through. | 15:22.11 |
| henrys | more generally is this something we all have confidence is doable? We have a huge headstart in gs, I was more at the stage of discussing this, not assigning and implementing. | 15:22.26 |
| Robin_Watts | tor8 is going to try a rework of the underlying triangle renderer we use that might help with that. | 15:22.37 |
| | henrys: svgwrite should be doable without too much pain, I think. | 15:23.05 |
| henrys | It also depends on what the customer wants right? Text is huge right? | 15:23.36 |
| Robin_Watts | How limited is svg with font formats? | 15:23.59 |
| | Ah, SVG has "SVG fonts" | 15:25.33 |
| henrys | from what I understand it about as muddled as html. | 15:25.39 |
| Robin_Watts | equivalent to PDFs type 3. | 15:25.47 |
| | so it should be easy enough to convert all fonts to SVG fonts. | 15:26.22 |
| henrys | so I guess marcosw can ask the customer if mupdf is going to serve their needs as it is consistent with our future direction with svg stuff⦠tor8 do you want to weigh in on this? | 15:28.08 |
| | Do you see any issues with doing and svgwriter? | 15:28.18 |
| | tor8 ^^^ | 15:29.12 |
| kens | Are we sure the customer only requires PDF input ? | 15:29.48 |
| henrys | mvrhel_laptop: are you going to get sucked into the GS stuff? It would be good to move the viewer along but I know the priorities are with the new printer customer. | 15:30.35 |
| | kens:that's for marcosw to find out. Also, they may just want a gs solution to have one app | 15:31.08 |
| | kens:I was going to bring it up with marcosw at the gs meeting, he doesn't attend this one. | 15:31.55 |
| mvrhel_laptop | henrys: the auto color stuff is pretty much done (at least my part). I am hoping to hand it of to ray_laptop today | 15:31.56 |
| tor8 | Robin_Watts: all non-type3 fonts at least. though doesn't svg support webfonts? | 15:32.21 |
| marcosw | henrys: the customer had previously said they were looking for pdf -> svg. It's possible they meant ps/pdf, I'll clarify. | 15:32.24 |
| henrys | mvrhel_laptop: oh good. | 15:32.35 |
| tor8 | svgwrite for pdf should follow on easily enough once robin has pdfwrite working | 15:32.47 |
| Robin_Watts | tor8: Supposedly it does support webfonts. | 15:32.50 |
| tor8 | for mupdf | 15:32.52 |
| Robin_Watts | tor8: I think svgwrite would be easier to to than pdfwrite. | 15:33.02 |
| tor8 | Robin_Watts: quite probably so | 15:33.09 |
| mvrhel_laptop | henrys: the only other gs thing I was going to look at was the winrt question from raed | 15:33.10 |
| henrys | mvrhel_laptop: oh right that is fist and foremost sigh hopefully that will go fast. | 15:33.56 |
| Robin_Watts | All the building blocks that I've put in place for pdfwrite will make svgwrite straightforward (I hope). | 15:34.01 |
| henrys | mvrhel_laptop: this could be a sneaky way to get paulgardiner into ghostscript ;-) that football seems to be getting tossed around quite a bit. | 15:35.15 |
| tor8 | henrys: I started a branch to suck in ghostsvg into mupdf, haven't spent more than a few hours on it but the code is "saved" for mupdf if you want to go ahead and nuke ghostsvg in gs | 15:35.16 |
| henrys | tor8:it's on chrisl's schedule to do that. | 15:35.41 |
| mvrhel_laptop | henrys: true. if he wants to jump on that, that is fine | 15:35.54 |
| henrys | paulgardiner: a break from signatures? | 15:36.11 |
| tor8 | Robin_Watts: I got the oneskyapp receipt to my email | 15:36.20 |
| | I'll forward it back to you | 15:36.29 |
| marcosw | bbitft9m | 15:36.32 |
| paulgardiner | exposed simultaneously to gs and winrt. That's just cruel! :-) Oh go on then. | 15:36.48 |
| henrys | paulgardiner: are you up and running with 8 and rt? | 15:37.24 |
| chrisl | paulgardiner: please don't ask me to explain the the Ghostscript build system! | 15:37.31 |
| henrys | and all the wonderful stuff. | 15:37.33 |
| paulgardiner | henrys: No, but I guess I could be fairly quickly. I should warn you I know pretty much nothing about winrt... but that's a common starting point. | 15:38.32 |
| henrys | paulgardiner:this will surely make you appreciate your mupdf work, fast days will be easier, you'll breeze through all forms of hell. | 15:38.51 |
| Robin_Watts | paulgardiner: Amazon are the cheapest place to get win 8 from I could find, and if you have Amazon Prime it's next day delivery. | 15:39.20 |
| paulgardiner | henrys: :-) You make it sound so atractive. | 15:39.52 |
| mvrhel_laptop | henrys: so should I go back to the winrt viewer and not worry about raed now? | 15:39.52 |
| henrys | mvrhel_laptop:I think so. | 15:40.14 |
| paulgardiner | So what is this raed thing? | 15:40.15 |
| mvrhel_laptop | hehe | 15:40.20 |
| Robin_Watts | haha! | 15:40.29 |
| henrys | paulgardiner:is paulgardiner on support? | 15:40.35 |
| Robin_Watts | raed is a customer. | 15:40.40 |
| paulgardiner | Yeah, but what's the task? | 15:40.56 |
| henrys | Robin_Watts:why don't you forward the emails since you had an exchange that didn't include support. | 15:41.10 |
| | I'll put paulgardiner on support now. | 15:41.22 |
| Robin_Watts | henrys: I will forward everything (though I think everything went to support in the end) | 15:41.28 |
| henrys | sorry long meeting⦠I don't have anything else. | 15:42.24 |
| chrisl | Robin_Watts: don't you just add a linker option to get a winmd file? | 15:44.27 |
| Robin_Watts | chrisl: I tried that. No winmd file produced. | 15:44.44 |
| | My working theory is that you only get a winmd file out if you have C++ or C# source, as they have 'interfaces' that can be exposed. | 15:45.11 |
| | As we are written in C, we don't have an obvious interface that can be exposed. | 15:45.25 |
| chrisl | Don't you have to define an interface for a DLL? | 15:45.41 |
| Robin_Watts | (certainly all the docs I've found online talk about C++/C#) | 15:45.46 |
| | chrisl: Yes, but I can find no reference to it working with C. | 15:45.59 |
| | It's quite possible that there is something else going on though. | 15:46.29 |
| chrisl | Robin_Watts: do you need Windows 8 for this? | 15:46.36 |
| mvrhel_laptop | I think we need to add a c++ project to create a DLL that interfaces properly to the C library | 15:46.39 |
| Robin_Watts | chrisl: You need both windows 8 and vs2012 | 15:46.54 |
| mvrhel_laptop | to create winrt you are going to need windows 8 and the newest visual studio I suspect | 15:46.55 |
| henrys | we need to refactor our email addresses staff = tech + Miles + Scott etc. if things were set up that way we wouldn't revisit this email stuff constantly. | 15:46.59 |
| paulgardiner | I have both VMWare and Windows Virtual PC on my machine. Any ideas which is likely to best host Windows 8? | 15:48.57 |
| henrys | paulgardiner: you're on support - lucky day! | 15:49.11 |
| Robin_Watts | I use VMWare Player and it seems to work. No experience of the other. | 15:49.39 |
| kens | was about to say that VMWare works | 15:50.33 |
| mvrhel_laptop | I would use VMWare | 15:52.28 |
| ray_laptop | morning, all | 15:58.24 |
| kens | Hi ray | 15:58.48 |
| henrys | next meeting start | 15:59.29 |
| | ray_laptop:I assume you are going to field or assign stuff from the new printer customer. right? | 16:00.33 |
| | there were a few emails yesterday | 16:00.52 |
| ray_laptop | henrys: those all look fairly simple to respond to | 16:01.58 |
| henrys | ray_laptop:last time I think marcosw was waiting for you and you waiting for him which is to be avoided. | 16:02.28 |
| ray_laptop | henrys: I will reply (and cc support). | 16:04.08 |
| henrys | so the other thing for the meeting: I wonder if we can compromise on review - require reviews for code changes outside ownership as per who_owns_what.txt (duck) | 16:04.47 |
| ray_laptop | I agree with submitting for review. But how long do we wait for a reviewer before we can go ahead and push the commit ? | 16:06.07 |
| henrys | I'm going to live with that henceforth I guess others can think about it. | 16:06.09 |
| Robin_Watts | ray_laptop: If your reviewer doesn't get back to you within 24-48 hours, then it's their fault if you break their code :) | 16:07.32 |
| henrys | ray_laptop:I don't think we need any special rules for that. | 16:07.49 |
| chrisl | ray_laptop: when I ask for review, I tend to say "if I don't here back within x days, I'll take that as a 'yes'"...... | 16:08.37 |
| ray_laptop | henrys: Robin_Watts: sounds fine. | 16:09.10 |
| chrisl | Hmm, I find it discomforting that VS 2012 wants 7Gb of my disk space :-( | 16:09.34 |
| henrys | I also think it is a good idea to push to your personal repo for review. | 16:11.54 |
| Robin_Watts | chrisl: http://www.ebuyer.com/339426-hitachi-4tb-touro-dx3-desktop-hard-drive-0s03400 | 16:12.03 |
| chrisl | Robin_Watts: can I get a virtual one for my virtual machine :-) | 16:12.40 |
| Robin_Watts | henrys: reviewing via the personal repo is the way we tend to work for mupdf. People can just look at the webview without needing to wrangle git locally. | 16:12.55 |
| henrys | mvrhel_laptop, ray_laptop: are you guys good with mvrhel_laptop switching back to the windows viewer? | 16:12.57 |
| | Robin_Watts: yes I think the review will also include the commit message when you go that route. | 16:13.32 |
| mvrhel_laptop | I am good with it. ray_laptop: I am about ready to commit this. cleaning up a few compiler warnings now | 16:13.45 |
| Robin_Watts | chrisl: That drive is about 30 quid cheaper than I could find any other 4TB drive for. I broke the case apart and fitted it internally. | 16:13.47 |
| ray_laptop | mvrhel_laptop: is the color detection stuff done ? | 16:13.50 |
| | mvrhel_laptop: I typed too slowly :-( | 16:14.04 |
| mvrhel_laptop | ray_laptop: it seems to be working | 16:14.07 |
| ray_laptop | mvrhel_laptop: thanks. | 16:14.09 |
| Robin_Watts | henrys: yes, it does. everything nicely on one webpage: e.g. http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commitdiff;h=22e516aa7adfa665d549f95c9e7feb831b9965a9 | 16:14.09 |
| mvrhel_laptop | ray_laptop: also I included a fix so that 16 bit images can actually get encoded as high level images now | 16:14.37 |
| | previously they were never | 16:14.45 |
| ray_laptop | mvrhel_laptop: Oh, good. | 16:14.49 |
| mvrhel_laptop | very odd to find that | 16:14.54 |
| ray_laptop | I suppose I am not that surprised. | 16:15.21 |
| henrys | I had one more thing for ray_laptop - I think a user has done some bountiable work on romfs and I'd like to pay him if it okay. | 16:15.32 |
| | s/it/the work is/ | 16:16.13 |
| ray_laptop | henrys: which bug ? | 16:16.41 |
| kens | mvrhel_laptop : did you test the 16-bit images with pdfwrite ? | 16:18.01 |
| mvrhel_laptop | kens: I did a cluster push. but pdfwrite does not use the clist does it? | 16:18.22 |
| henrys | ray_laptop: looking | 16:18.22 |
| kens | mvrhel_laptop : no it doesn't (at the moment) | 16:18.33 |
| mvrhel_laptop | ok. kens this is only for clist high level images | 16:18.45 |
| henrys | 690969 | 16:18.50 |
| kens | OK np then | 16:18.51 |
| ray_laptop | henrys: thanks. looking... | 16:19.04 |
| henrys | ray_laptop:he was starting to become an active contributor. | 16:19.24 |
| | that's all I got for this meeting. Anybody else? | 16:20.12 |
| alexcher | Fuzzing bugs are arranged inconveniently. Perhaps, we can retest the files and group them by the Valgrind warnings. | 16:21.43 |
| henrys | alexcher:good question for marcosw but I don't think he is back yet. | 16:22.26 |
| marcosw | I'm here | 16:22.40 |
| | alexcher: I can do as you suggest. | 16:24.28 |
| alexcher | marcosw: It would be great. At least pdfwrite and a raster device should be tested. | 16:25.31 |
| henrys | marcosw:okay so you also have the followup with Raed right? In short our future direction is to have svg processing in/our done with mupdf, does that work for him. | 16:25.43 |
| | s/our/out | 16:26.08 |
| marcosw | henrys: yes, confirm with Raed that he doesn't need ps -> svg and he'd be okay with using mupdf for pdf -> svg. He might not want to support two different pdf interpreters... | 16:26.53 |
| alexcher | We need a native speaker to rephrase the paragraph about /CropBox, bug 693926. This won't take too long. | 16:35.09 |
| pgogna | Updates: I was able to make a small snippet to create a device & call display list. Now I am not sure what should be my next step to get bounding box for the tapped element? Please help. | 16:36.39 |
| chrisl | alexcher: can't we just quote the reference manual? | 16:37.08 |
| tor8 | pgogna: so now you have a fz_text_page object? | 16:38.02 |
| | filled out from the run_display_list call | 16:38.11 |
| pgogna | text = fz_new_text_page(ctx, fz_bound_page(doc, page, &bounds)); dev = fz_new_text_device(ctx, sheet, text); fz_run_display_list(glo->pages[glo->current].page_list, dev, &fz_identity, &afz_infinite_rect, &cookie); | 16:38.52 |
| | Yes. I think so | 16:38.57 |
| alexcher | chrisl: fine for me. That's mostly what's already done there. | 16:39.31 |
| chrisl | alexcher: assign it to me, then - I seem to end up with the doc bugs anyway! | 16:40.03 |
| tor8 | then you can iterate through text->blocks and test their bounding boxes for if your hit lies within | 16:40.03 |
| Robin_Watts | pgogna: OK, so look in fitz/dev_text.c at fz_print_text_page_xml | 16:40.04 |
| tor8 | fitz/fitz.h at "struct fz_text_page_s" you can see the layout of the structs | 16:40.31 |
| Robin_Watts | The code there (as tor8 says) iterates through the blocks and outputs bboxes for each span. | 16:40.33 |
| | and indeed for each line. | 16:40.44 |
| | You probably want to look at the line ones. | 16:40.51 |
| pgogna | Ok I understand. Let me try this. | 16:42.15 |
| kens | OK goodnight folks | 16:47.38 |
| mvrhel_laptop | ray_laptop: I just pushed the auto color stuff | 17:08.18 |
| | I will send you some details in an email | 17:09.01 |
| ray_laptop | mvrhel_laptop: thanks | 17:10.18 |
| | mvrhel_laptop: do you have time for a quick question (another one, that is) ? | 17:19.21 |
| mvrhel_laptop | writing your email now. but yes. | 17:19.46 |
| ray_laptop | do I need to copy the icc_table for a background rendering thread, or can it be shared with the parsing thread ? | 17:20.26 |
| mvrhel_laptop | hmm. the icc_table is altered during clist writing. and only read from during clist reading but there is no mutex around it | 17:22.05 |
| ray_laptop | in multi-threaded rendering, all the threads share the icc_table (just copy the pointer), but is it safe to share with the parsing thread ? | 17:22.09 |
| | OK. Then I need to copy the table for the rendering thread | 17:22.35 |
| | since the next page will be building a new table, right ? | 17:22.51 |
| mvrhel_laptop | ray_laptop: yes a new page would be building a new table | 17:23.09 |
| ray_laptop | don't know why this doesn't cause problems on windoze, but ... | 17:24.08 |
| | mvrhel_laptop: thanks. I'll add that in and see if things get better | 17:24.28 |
| pgogna | Wondeful news, I found the matching bounding box. Next challenge, how do I zoom to this rect? | 17:25.01 |
| ray_laptop | only 5,079 segfaults :-) | 17:25.52 |
| mvrhel_laptop | :( | 17:25.59 |
| Robin_Watts | pgogna: just a warning; the data structure you have just walked to find the text bboxes is going to change slightly in order to accomodate images too. | 17:26.59 |
| | but not by much. | 17:27.07 |
| mvrhel_laptop | ray_laptop: so I sent you the details | 17:27.16 |
| ray_laptop | mvrhel_laptop: got it. Thansk | 17:28.25 |
| | or Thanks | 17:28.33 |
| Robin_Watts | pgogna: IIRC you were feeding in fz_identity for the matrix. hence the bboxes you get will be for document space. (i.e. without any zooming applied). | 17:28.44 |
| | You might want to feed in the current page transformation instead. That way the bboxes you get will correspond to the current zoom. | 17:29.15 |
| | Then you can compare the width of the bbox that you hit with the width of the screen. | 17:29.47 |
| | Then you can adjust the current page transformation as appropriate. | 17:30.02 |
| | Does that make sense ? | 17:30.05 |
| ray_laptop | mvrhel_laptop: you wrote "during the clist playback, we should set pageneutralcolor = false". So that isn't done currently ? How does it work ? | 17:32.05 |
| | mvrhel_laptop: i.e., how come you don't end up checking colors during playback now ? | 17:32.39 |
| mvrhel_laptop | why would you check during playback ray_laptop ? | 17:32.52 |
| | ray_laptop: the project is not done yet you realize | 17:33.10 |
| ray_laptop | mvrhel_laptop: not expressing myself very well. | 17:33.13 |
| mvrhel_laptop | I was looking for help from you | 17:33.23 |
| ray_laptop | mvrhel_laptop: Oh, I see. OK | 17:33.33 |
| | mvrhel_laptop: so the email outlines some things that still need to be done (including fixing clist playback) ? | 17:34.03 |
| mvrhel_laptop | yes | 17:34.09 |
| | sorry I was not clear on that ray_laptop | 17:34.22 |
| ray_laptop | mvrhel_laptop: OK. I thought it was done. | 17:34.31 |
| mvrhel_laptop | no. I was not sure how best to handle all of that with new pages starting etc | 17:34.47 |
| ray_laptop | mvrhel_laptop: np. I'll contact you if I hve questions | 17:34.48 |
| mvrhel_laptop | ok | 17:34.55 |
| | thanks | 17:34.57 |
| ray_laptop | mvrhel_laptop: have fun getting back to the windoze viewer :-) | 17:35.38 |
| mvrhel_laptop | yes. I need to do some major refactoring on it | 17:36.00 |
| ray_laptop | I usually break one or two things doing that | 17:36.32 |
| | but, strangely, in refactoring the setup of devices for threads, somehow the windows fopen problem with clist files just "went away" :-/ | 17:37.22 |
| pgogna | Robin: This is lot to digest, let me think and get back to you. | 17:37.55 |
| ray_laptop | it's on my list to see if I can figure out what's different (or if the problem still exists on master) | 17:38.12 |
| Robin_Watts | pgogna: At the moment, when you run the display list you're feeding in fz_identity right? | 17:38.25 |
| ray_laptop | but if that is now working, then we might be able to make the clist files "auto delete on close" | 17:38.45 |
| tkamppeter | mvrhel_laptop, hi | 17:38.54 |
| mvrhel_laptop | hi tkamppeter | 17:39.12 |
| pgogna | Yes, I am feeding in fz_identity | 17:39.42 |
| mvrhel_laptop | so I am set to be at the open printing meeting wed the 15th of may | 17:39.56 |
| | I will plan to talk about whats new in gs and also mupdf | 17:40.14 |
| Robin_Watts | Right, so you're saying "process the display list with no additional transformations". | 17:40.15 |
| mvrhel_laptop | tkamppeter ^^ | 17:40.27 |
| Robin_Watts | So the bboxes you get back are the bboxes that would be given in the page was unzoomed. | 17:40.46 |
| | BUT the page is (pretty much always) displayed zoomed to fit the screen (or maybe zoomed in further if the user has been zooming it). | 17:41.22 |
| | So you should really pass in the current page transformation there instead. | 17:41.33 |
| | That way, the bounding boxes you get back will be in screen coordinates. | 17:41.54 |
| pgogna | I got it. I think I can fix this. However I am not sure how do I zoom to a particular bonding box rectangle | 17:43.11 |
| Robin_Watts | Ok, so let's suppose you have a 320x240 screen. | 17:43.28 |
| | and you get a bbox back that's (50,50) -> (200, 200) | 17:43.53 |
| pgogna | Ok, I am listening | 17:44.11 |
| Robin_Watts | You want to translate it left by 50, then scale it up by 320/200 right? | 17:44.59 |
| | (actually, you probably want to translate it by (-50, -50) then scale it, then translate it back so that the scaled bbox is in the middle of the screen) | 17:45.43 |
| | so translate by (-50,-50), then scale by (320/200,320/200) then translate by (0, 240 - (200-50)*320/200) or something. | 17:46.55 |
| | actually that might be (240 - (200-50)*320/200)/2 :) | 17:48.04 |
| pgogna | Have you done translation of the page before anywhere in the code? | 17:48.19 |
| Robin_Watts | pgogna: yes, we translate the page all the time. | 17:48.36 |
| | the way you translate the code is to alter the current transformation matrix. | 17:48.49 |
| | Look for fz_scale, fz_translate, etc. | 17:49.24 |
| | tor8: OK, image extraction changes all pushed to robin/master. This clears my plate to be able to look at the vertical motion stuff tomorrow. | 17:59.15 |
| tkamppeter | mvrhel_laptop, will you give a presentation about GS and MuPDF state of the art, and also about color management state of the art on the OpenPrinting Summit? | 18:52.18 |
| | mvrhel_laptop, OK, let me see in which session you will do your presentation. | 18:54.39 |
| mvrhel_laptop | tkamppeter: what do you mean about "color management state of the art" | 18:54.56 |
| tkamppeter | mvrhel_laptop, yes, in the afternoon session. Please send us the slides before the Summit, so that we can upload them for remote attendees. | 18:55.35 |
| mvrhel_laptop | tkamppeter: I can certainly focus on what is the state of color management in gs and mupdf | 18:55.35 |
| | and I can give a general talk about color management | 18:56.02 |
| tkamppeter | mvrhel_laptop, yes, as far as we are now we need the CM support in GS and MuPDF, I will look into whether some CM guy will also come or call in to talk about general CM, but if I do not find a volunteer I define you as the volunteer. | 18:57.39 |
| mvrhel_laptop | ok. | 18:58.10 |
| tkamppeter | mvrhel_laptop, thanks. | 19:01.50 |
| henrys | of 693932. Was there a change to the tiff devices that would cause it not to work stdout as a stream? Something like that seems familiar but I can't remember. | 19:10.08 |
| Robin_Watts | Did libtiff not cause tiffs to only work with random access? Compressed encodings etc. | 19:20.08 |
| henrys | right the comment about tiff_output_page() | 19:22.44 |
| | s/about/above | 19:22.52 |
| tor8 | Robin_Watts: there are a ton of comments on the onesky translation I got as emails | 19:52.21 |
| Robin_Watts | looking at them online now. | 19:53.21 |
| | looks like the translation is all moving along nicely. | 19:54.12 |
| tor8 | I've set up a filter so you should get all oneskyapp emails automatically | 19:56.09 |
| | Forward 1 day (to 2013/04/24)>>> | |
IRC Logs