| | <<<Back 1 day (to 2015/09/07) | 20150908 |
| Robin_Watts | hopes kens is feeling better this morning. | 08:48.40 |
| kens | Better..... | 08:49.38 |
| | well enough to sit up an take notice anywy. Thanks :-) | 08:49.53 |
| _wiz_ | hi robin. any idea on jbig2dec vs. memento.h vs. mupdf yet? | 08:50.56 |
| Robin_Watts | _wiz_: Not even looked. | 08:58.21 |
| | I'm buried in other stuff at the moment. | 08:58.27 |
| | at least 2 tasks deep. sorry. | 08:58.33 |
| _wiz_ | sure, no problem. is that something I should file a bug report about? | 09:03.46 |
| Robin_Watts | _wiz_: That would ensure it wasn't forgotten, yes. | 09:04.19 |
| | Chaos here today; 3 different trades working in the kitchen. | 11:24.28 |
| | 1 of them is the electrician. | 11:24.36 |
| | It's possible I may have to disappear later to help him. | 11:24.52 |
| | If I miss the meeting because of it, I apologise. | 11:25.04 |
| | I have nothing to report for gs/mupdf this week anyway, except to say that I should try and look at the memento/jbig2 stuff again. | 11:25.37 |
| henrys | kens2: take off early if you want, nothing crucial at the meeting. | 13:15.44 |
| kens2 | henrys I'm feeling 'OK' today, actually writing some code :-) | 13:16.04 |
| | But thanks | 13:16.13 |
| henrys | chrisl: I'm seeing the build use shared libraries in the new build where it didn't before, and worse the build fails if the libraries aren't available (i.e. freetype). Is that something you know about? | 13:25.40 |
| | s/shared/systme | 13:28.00 |
| | s/shared/system | 13:28.04 |
| chrisl | henrys: no, there shouldn't be any change in what Ghostscript is using | 13:28.31 |
| henrys | chrisl: ldd shows freetype, expat, png are system libs for me with the regular build | 13:39.57 |
| | chrisl: should I make a bug? | 13:40.32 |
| chrisl | henrys: I doubt Ghostscript is using the system libraries | 13:40.47 |
| | In fact, I know it isn't because I have debugged both freetype and png since the build changed | 13:41.15 |
| henrys | oh so some contrib thing or something is pulling them in | 13:41.38 |
| chrisl | IIRC, fontconfig links to freetype and maybe expat. Not sure about png.... | 13:42.14 |
| henrys | chrisl: that makes sense I'm accustomed to see no system libraries with pcl,but the new build brings in more stuff... | 13:43.00 |
| chrisl | Oh, right, of course. OTOH, the configure script should leave out such things if they are not available, so the build shouldn't fail | 13:43.55 |
| henrys | on a fresh ubuntu it does fail. We have the old X11 problem discussed with Robin_Watts a while back but now I get a link fail with xps... my laptop is powered down right now and I can give you the specifics after the meeting. | 13:46.07 |
| chrisl | I can't think why XPS would fail, if the others work..... | 13:47.01 |
| henrys | chrisl: they might very well I just know xps failed | 13:47.40 |
| chrisl | There is something hooky about the X11 deps - I *think* the original hierarchy of dependency (as reflected in our configure checks) no longer applies - I have a note to look at it when I have a chance | 13:48.06 |
| henrys | chrisl: can't we just create a stub with the include files we use and compile it at configure time? | 13:48.46 |
| | for X11 that is | 13:49.04 |
| chrisl | That's essentially what we do (but we use the predefined autoconf macros to do it). But there's an assumption that one of the X libraries can't be installed without another one, and I'm *sure* that was true once, but appears not to be now | 13:50.28 |
| | I just haven't gotten around to it because it means setting a new VM (so I don't break my everyday system), and then the test builds take ages (in a VM) | 13:51.43 |
| henrys | yeah the pcl build fails outright as well /usr/bin/ld can't find fontconfig, freetype, idn.. probably would have more problems if I started from a completely fresh system | 13:54.06 |
| chrisl | Um, but if they are not available, configure should not have added them to the build - that's confusing :-( | 13:55.20 |
| | Can you mail me the config.log? | 13:55.48 |
| henrys | yup | 13:56.52 |
| chrisl | Hmm, the log says it didn't find libpaper, fontconfig, idn.... why the hell is the build including them? :-( | 14:01.37 |
| Robin_Watts | henrys: Which makefile are you calling? :) | 14:02.32 |
| henrys | Robin_Watts: the one make picks ;-) | 14:03.47 |
| Robin_Watts | henrys: Does the date on Makefile correspond to the time you ran configure? And does make -f Makefile give the same results? | 14:05.18 |
| | (I'm just guessing at things here, but using an old makefile left over from before the rearrangement would explain things. Kinda thing I'd get wrong) | 14:06.06 |
| chrisl | I just uninstalled libpaper and fontconfig and configure correctly spotted they're not available, and they were not included in the build..... | 14:06.45 |
| henrys | Robin_Watts: yes both are the same date | 14:08.50 |
| | it is possible there is old cruft around but I'd like to understand why autogen.sh didn't blow it away. | 14:10.21 |
| | or at least cause it to be outdated | 14:10.39 |
| chrisl | Because that's not the way it works. autogen.sh does stuff out of make's ken, and that means it's really not a good idea to re-run autogen.sh/configure with stale make results floating around | 14:12.08 |
| | Nevertheless, this should be more robust, but making it so without forcing stuff to be rebuilt unnecessarily is going to be very time consuming | 14:13.50 |
| henrys | chrisl: right it's coming from a stale .tr file but I do think that should be outdated and rebuilt | 14:14.01 |
| | chrisl: but not a big deal | 14:16.33 |
| chrisl | That's partly an issue with how the .tr files are made - they are not "real" targets, and they need to be for it to work | 14:16.51 |
| henrys | yup | 14:17.17 |
| chrisl | I do know (mostly) what to do to make it work, but it's a fair amount of shuffling around and stuff, and getting it to work reliably could be unpleasant. It's related to an open bug report I have | 14:19.24 |
| henrys | I've spent the past week disemboweling plmain.c, and have no idea what's going on so I'm afraid the meeting will be lacking for entertainment. | 14:21.06 |
| kens2 | is happy with a quiet meeting | 14:21.56 |
| mvrhel_laptop | morning | 14:24.00 |
| | tor8: did you seem my question late last week about getting some information about the text positioning within the widget bounding box? | 14:26.08 |
| henrys | mvrhel_laptop: so altona visual should have the 3 transparent circles and I see opaque in gsproof? | 14:26.16 |
| mvrhel_laptop | henrys: I see them transparent with gproof | 14:26.35 |
| fredross-perry | which altona file? | 14:27.11 |
| mvrhel_laptop | tor8: I suppose I could run through a text device with the bounding box of the widget | 14:27.22 |
| henrys | mvrhel_laptop: altona_visual | 14:27.35 |
| mvrhel_laptop | but I did not know if there was something else I could use/do | 14:27.42 |
| | henrys: right. let me open it now | 14:27.58 |
| marcosw | morning | 14:28.43 |
| fredross-perry | in android the three overlapping circles are opaque. before proofing. | 14:28.49 |
| tor8 | mvrhel_laptop: no, sorry. | 14:29.24 |
| Robin_Watts | Henrys: So, you open altona in gproof, and you see the normal mupdf view (opaque). Then you hit the 'proof' button, and go into proofing mode. You still seem them opaque then? | 14:29.41 |
| fredross-perry | and transparent *after* proofing. | 14:29.51 |
| mvrhel_laptop | tor8: so no, I should do the text device with the bounding rect of the widget? | 14:30.13 |
| fredross-perry | why should they be different before and after proofing? | 14:30.50 |
| henrys | okay my bad | 14:31.15 |
| tor8 | mvrhel_laptop: which day was this? or could you repeat your entire question? | 14:31.17 |
| mvrhel_laptop | fredross-perry: ah, mupdf does not handle the overprinting | 14:31.18 |
| henrys | I assumed we were proofing by default, it seemed that ghostscript was preprocessing when I ran the file ... are we running gs on the file for both? | 14:32.14 |
| mvrhel_laptop | tor8: essentially, I have the bounding box of the widget, I can get the text that is in it with pdf_text_widget_text and I can finding out what length is allowed with pdf_text_widget_max_len and that is all fine. But I want to know where the letters are getting placed as I typed so that I can ensure my cursor is at the proper location | 14:33.04 |
| fredross-perry | henrys: no I donât think so | 14:33.22 |
| mvrhel_laptop | I don't want to do a pop up box for text entering | 14:33.25 |
| tor8 | mvrhel_laptop: ah, right. you're adding inline text editing for the widgets? | 14:33.38 |
| mvrhel_laptop | that is what I would like to have | 14:34.05 |
| tor8 | mvrhel_laptop: I'm not all up to speed with the widget and forms code; but I'm in the same situation as you. I'm about to get this to work on the basic linux viewer. | 14:34.22 |
| henrys | mvrhel_laptop, fredross-perry looks fabulous but gs is a little pokey, I guess we'd expect that. | 14:34.52 |
| mvrhel_laptop | yes | 14:35.19 |
| fredross-perry | henrys: yes itâs a little pokey. It would be great to speed that up somehow. | 14:35.29 |
| tor8 | mvrhel_laptop: sebras wrote some experimental code to do inline text editing on forms a while ago | 14:35.32 |
| | it's in his repo on sebras/forms | 14:35.40 |
| | might be worth looking at that code | 14:35.45 |
| mvrhel_laptop | tor8: ok I will take a look at that. thanks | 14:35.51 |
| tor8 | but from a simple glance, it looks like it's actually adding a "|" character for the cursor position... | 14:36.27 |
| henrys | fredross-perry: I'm not sure if we want to fool with it... if it gets attention at the show I guess we will. | 14:36.55 |
| tor8 | this is really a question for paulgardiner, since you need to replicate the text layout he does when creating the annotation stream from the text buffer | 14:36.56 |
| fredross-perry | henrys: right. Not suggesting we do it before the show. You can try using lower resolutions when you demo. | 14:37.35 |
| henrys | mvrhel_laptop, fredross-perry : are you fairly comfortable with the quality of this? should it work exactly as well as ghostscript. I can't control the demo, somebody *will* ask me to display their file. | 14:38.29 |
| mvrhel_laptop | henrys: it should work as well as ghostscript. | 14:39.24 |
| | does on the command line | 14:39.30 |
| tor8 | mvrhel_laptop: to get metrics, the pdf_measure_text function is what you want | 14:39.35 |
| | possibly somewhat changed so you can get the cursor position from a partial string | 14:39.51 |
| henrys | no meetings next Tuesday in advance of the in person meeting. I'll be at the show next week. | 14:40.00 |
| paulgardiner | I'm struggling to see what question I might help with | 14:40.05 |
| kens2 | have fun henrys | 14:40.18 |
| fredross-perry | henrys: it seems to work well from my perspective. If you have a range of files you can try beyond the Altona set, thatâd be good to try. | 14:40.20 |
| tor8 | mvrhel_laptop: but this code is in need of improvement -- it doesn't cope with unicode etc | 14:40.24 |
| paulgardiner | Ah! | 14:40.47 |
| mvrhel_laptop | tor8: ok. My thought was to update the annotation display list as the user types and have the xaml c# code set a cursor at the appropriate spot. tor8: I was wondering about the unicode. there was a file that I noticed an issue with that | 14:41.26 |
| paulgardiner | I guess we'd need to add a function that returned a doc position given an index into the text, or something like that. | 14:41.27 |
| tor8 | mvrhel_laptop: you'd probably want to start by looking at create_text_appearance in pdf-appearance.c | 14:41.55 |
| henrys | anything else meeting wise? I'll review the workflowy this week and make sure it is current. | 14:42.20 |
| tor8 | it might even be possible to add cursor graphics and selection highlights to that function, and then just regenerate the appearance for each edit | 14:42.22 |
| paulgardiner | Sounds clunky. | 14:42.58 |
| tor8 | and then you'll just need a mouse x,y -> string index mapping function to map clicks to text positions | 14:42.58 |
| | paulgardiner: yeah, but it's the easiest way to get something working quickly | 14:43.12 |
| henrys | marcosw: customer stuff? | 14:43.39 |
| mvrhel_laptop | I don't know. I do prefer the flashing cursor which I can have set with native code at a specified location | 14:43.43 |
| tor8 | it's going to be dreadfully inefficient. the proper way would be to replicate the text drawing in the app layer, and make sure that it matches what goes into the appearance stream once done | 14:43.58 |
| mvrhel_laptop | yes | 14:44.04 |
| | that would be ideal | 14:44.06 |
| paulgardiner | I remember thinking that maybe we should use a separate display list while editing and then turn the display list into an appearance stream when finished | 14:44.10 |
| | ... but we'd need better font support from the pdf device to do that. | 14:44.36 |
| | IIRC | 14:44.40 |
| tor8 | I was thinking of temporarily turning off drawing the input field while it has focus and use a "native" text field for editing | 14:44.49 |
| | and when you lose focus or press enter, update the text form object and lose the native widget | 14:45.11 |
| mvrhel_laptop | I was thinking that too. | 14:45.18 |
| | but do you think people would have an issue with the font change? | 14:45.31 |
| tor8 | mvrhel_laptop: the biggest "problem" with the current code is that it can't cope with weird font encodings and unicode | 14:45.58 |
| paulgardiner | Native text string is not likely to match the final result well. Acrobat matches exactly | 14:46.08 |
| mvrhel_laptop | or am I missing something there | 14:46.14 |
| | right | 14:46.22 |
| henrys | chrisl: I'll be pushing the pcl language switch changes to my repo and soliciting feedback soon. This is going to be a big change, no way it can go this release. | 14:46.26 |
| tor8 | my suggestion has been to enforce use of either times, helvetica or courier as CID-fonts and use a 16-bit unicode encoding | 14:46.39 |
| | but that means having to update quite a bit of code | 14:46.51 |
| chrisl | henrys: I'm expecting it to be a fairly monster change..... | 14:47.30 |
| tor8 | but knowing we'll always end up with a known font where we control the encoding, matching it with system drawing code is at least possible | 14:47.44 |
| Robin_Watts | henrys: sorry, got called away. gsproof only calls gs for the proofing mode. | 14:48.16 |
| tor8 | if you implement your own text editing, you can use our embedded fonts and font rendering to draw to a bitmap that you just draw ontop of the page | 14:48.28 |
| Robin_Watts | So you open a file, and can navigate around it quickly using mupdf. Then you just check the page you want by going into proofing mode. | 14:48.49 |
| tor8 | no need to mess with display lists there, you could make a case for rendering straight out of our glyph cache onto the native window | 14:48.53 |
| mvrhel_laptop | tor8: that is an idea | 14:49.07 |
| henrys | Robin_Watts: great it seemed to be very slow on one load but now I can't reproduce that. Probably something else going in the system at the time. | 14:49.19 |
| tor8 | it's what I'm planning to do with the linux based viewer--just draw text strings using our builtin fonts and the mupdf font renderer | 14:49.37 |
| Robin_Watts | AIUI, the layout of text within a widget is done with paulgardiners code in the forms stuff. | 14:50.03 |
| tor8 | and do the same metric calculations that match what the pdf-appearance code will generate | 14:50.10 |
| Robin_Watts | Hence to exactly match the positions, we need a measure string based on the same logic. | 14:50.28 |
| tor8 | Robin_Watts: pdf_measure_string | 14:50.42 |
| | that's the underlying function that paul's code uses | 14:50.58 |
| Robin_Watts | tor8: Ah, perfect. | 14:51.04 |
| tor8 | it takes a byte string and a length | 14:51.30 |
| mvrhel_laptop | hmm I cant find pdf_measure_string | 14:51.39 |
| tor8 | so sadly only works for 8-bit encodings, not for CID fonts | 14:51.43 |
| | mvrhel_laptop: pdf-font.c | 14:51.52 |
| Robin_Watts | tor8: Would fixing that require a change to the API ? | 14:52.26 |
| paulgardiner | I don't know how this impinges on the problem, but form fields have many different modes: some can wrap, some can altert the font size to fit the text in a box. The layout code isn't trivial. | 14:52.54 |
| tor8 | Robin_Watts: probably, remains to be seen how much | 14:53.08 |
| Robin_Watts | henrys: Things to be aware of... | 14:53.25 |
| tor8 | I expect I will have to do some fairly extensive reworking to get this to work with unicode | 14:53.43 |
| Robin_Watts | 1) Changing the separations used on a proofed page does not call gs again. So it's not as slow as a complete rerendering. | 14:54.01 |
| | 2) If you change the separations used on a proofed page, the results are no longer color correct (as mupdf is having to do the mixing). | 14:54.30 |
| henrys | chrisl what do you guys think of making NOPAUSE a device parameter and having gs_ouput_page() the library deal with the prompt business? I'd like to just remove that from the languges if possible. | 14:54.42 |
| | rayjj also ^^^ | 14:55.03 |
| tor8 | paulgardiner: yeah. we should probably split the layout code out so it can be reused for both text editing and the final appearance stream creation. | 14:55.17 |
| Robin_Watts | 3) If you flip forward a page, then back again, it should still be in cache, so gs is not hit again. If you flip forward 2 pages, then back, it will hit gs. | 14:55.24 |
| chrisl | henrys: won't that cause issues with Ghostscript in interactive/executive mode? | 14:55.30 |
| Robin_Watts | (/then back/then back 2/) | 14:55.37 |
| rayjj | henrys: no objection, I suppose. It does make it more like PCL/XPS that way | 14:55.44 |
| Robin_Watts | 4) Whenever it hits gs, it resets the separation selection. | 14:55.51 |
| paulgardiner | tor8: I believe there are two copies only because the pdf device cannot handle text completely. | 14:56.31 |
| Robin_Watts | 5) The separation selections are page specific. (If you pick 'just black' on page 1, and flip to page 2, you'll see all the separations for page 2). | 14:56.48 |
| paulgardiner | One version creates a display list (the one we want to keep) and the other creates the appearance stream directly | 14:57.06 |
| tor8 | mvrhel_laptop: how urgent is this project of yours? if it can wait a couple of months I might have better answers for you. | 14:57.09 |
| rayjj | chrisl: I would think that the user would not be able to tell. The output_page would determine that NOPAUSE was set, then issue the prompt to stdout, and read stdin for the entry | 14:57.28 |
| henrys | Robin_Watts: okay let me march through all that on the device to see I understand it. | 14:57.40 |
| mvrhel_laptop | tor8: If you end up with a better solution than what I have in a couple months that would be great. I am going to put together something in the short term that may not be ideal but should give more or less the feel of inline editing | 14:58.17 |
| tor8 | paulgardiner: I thought the appearance stream creation created content streams directly by printfing | 14:58.20 |
| mvrhel_laptop | tor8: there is no shortage of other things to do in the meantime | 14:58.33 |
| chrisl | rayjj: but we end up with Ghostscript doing I/O for the executive, and the graphics lib doing another bit of I/O for the NOPAUSE prompt - I'm not saying it can't work, but I could see things getting messy | 14:58.39 |
| rayjj | henrys: the one 'gotcha' is that gs_output_page doesn't have the i_ctx_p that is needed for stdout/stdin (that may be redirected) | 14:58.42 |
| tor8 | mvrhel_laptop: yeah. just don't spend too much time investing in the current architecture. I expect to do some big rewrites in the area soon-ish. | 14:58.47 |
| mvrhel_laptop | ok good to know thanks | 14:58.58 |
| henrys | rayjj: oh isn't that in the lib_ctx? | 14:59.15 |
| rayjj | henrys: so it would have to be in the zoutputpage layer | 14:59.20 |
| paulgardiner | tor8: in most cases we draw to the pdf device to create the appearance stream | 14:59.25 |
| chrisl | rayjj: sure in zoutputpage(), it's not better than it is now | 14:59.49 |
| | s/sure/surely | 14:59.56 |
| paulgardiner | e.g., we create the appearance stream for the logo we use when signing a doc by creating a path and drawing it to the pdf device | 15:00.44 |
| rayjj | henrys: gs_output_page just gets pgs. While we _could_ drill down into the pgs->memory-gs_lib_ctx it's rather unclean | 15:01.09 |
| Robin_Watts | rayjj: Why is that unclean? | 15:01.36 |
| tor8 | paulgardiner: right. from my cursory reading of pdf-appearance.c we create some by using the pdf_device and some by printfing? | 15:01.40 |
| henrys | I was waiting for Robin_Watts to say something... | 15:01.51 |
| Robin_Watts | The whole point of having the lib_ctx in the gs_memory_t's is that we can get it from anywhere. | 15:02.07 |
| chrisl | s/anywhere/almost anywhere (!!) | 15:02.26 |
| rayjj | Robin_Watts: it just has a bad smell, but it really isn't any worse than all the rest of the places that we resort to finding the gs_lib_ctx that way | 15:02.31 |
| paulgardiner | tor8: yes. the printf stuff is older code, that I'd hoped to replace with the new method, but I believe the pdf device needs work before that can be done | 15:02.31 |
| Robin_Watts | There is a function to get the lib_ctx from the memory_t IIRC (which is nicer than just dereffing it) | 15:02.59 |
| rayjj | henrys: chrisl: but it does get it out of the language layer | 15:03.11 |
| mvrhel_laptop | bbiab | 15:03.24 |
| tor8 | paulgardiner: there's also a new layer where you can call pdf drawing commands directly, that would work like the printf version but the output can land in either a display list or a buffer depending on what's on the other side | 15:03.37 |
| marcosw | rayjj: I sent you an email as well but could you take a look at peeved? It's running very slowly, even an ssh from peeves takes 10 seconds to get to the login prompt. | 15:04.39 |
| tor8 | paulgardiner: it's the pdf_processor interface that has been inserted between the interpreter and the fz_device. | 15:04.54 |
| paulgardiner | I'd defer to you for deciding what's the overal best way | 15:05.57 |
| tor8 | paulgardiner: I won't know that until I've jumped into the snake pit myself :) | 15:06.36 |
| rayjj | marcosw: yeah, I see that too. It just started happening. Also I sometimes get the wrong (old) IP address for peeved | 15:07.23 |
| paulgardiner | I'll stay up here and point the flash light for you, hold the ladder still, stuff like that :-) | 15:08.13 |
| tor8 | paulgardiner: thanks! :) | 15:08.32 |
| paulgardiner | your welcome :-) | 15:08.43 |
| | you're even | 15:08.50 |
| Robin_Watts | Is anyone checking luggage to fly to Chicago? | 15:09.34 |
| marcosw | Robin_Watts: no, but why are you asking :-) | 15:09.49 |
| Robin_Watts | I need to order some Bacon Salt. | 15:09.59 |
| | My UK supplier has stopped importing it. | 15:10.09 |
| marcosw | and it can't be carried on board? Is bacon salt now on the TSA watch list? | 15:10.43 |
| Robin_Watts | marcosw: We go through quite a lot of it. | 15:11.13 |
| paulgardiner | I would have questioned the work "need"... but then again with Bacon Salt maybe that's fair | 15:11.23 |
| | s/work/word/ | 15:11.48 |
| marcosw | I can check a bag; it doesn't cost anything for me on United and I won't be in any hurry to get to the hotel. | 15:12.03 |
| | makes it slightly easier to pack my toiletries as well. | 15:12.23 |
| Robin_Watts | marcosw: Thanks. That would be much appreciated. | 15:12.27 |
| marcosw | should I be buying bacon salt as well? now that my daughter is off to college we don't have any vegetarians in the house. | 15:13.17 |
| jogux | rayjj: the two artifex nameservers give different IPs for peeved, so that'd be why. peeves gives 64.183.45.165, ns1.ghostscript.com gives 100.9.62.165... | 15:14.51 |
| | http://dns.squish.net/traverses/3b0657a43a302fc6fa4e5ce6ebbdf14d | 15:15.15 |
| Robin_Watts | marcosw: bacon salt is vegan, and kosher. | 15:16.27 |
| | and fantastic. | 15:16.37 |
| marcosw | Robin_Watts: but does it taste like bacon? my daughter doesn't even like the smell, so can't imagine she would like the taste. | 15:16.56 |
| Robin_Watts | marcosw: Wierdo! | 15:17.10 |
| marcosw | and if it doesn't taste like bacon what's the point? | 15:17.15 |
| rayjj | jogux: I'll check peeves. I thought I had that all fixed. | 15:18.37 |
| marcosw | jogux: that's obviously a problem but even when I ssh to peeved using its ip address the connection takes a long time. | 15:20.06 |
| | BTW, I'm now thinking the connectivity problems to casper that have been causing cluster problems since Friday might be comcast's fault. I think all of the cluster machines that have been failing to connect have been at Miles' office or my house, and we both have comcast. | 15:20.32 |
| | speedtest.net says I only have 5Mbps download speed, which is about 20x less than I should. | 15:20.56 |
| jogux | marcosw: yeah, unrelated, definitely. when I ssh to peeved it takes ages before asking for my password. I'd hazard a guess it's taking ages to do the reverse dns lookup on the incoming connection, could be a resolv.conf problem maybe... | 15:22.01 |
| marcosw | I'm going to fiddle with routers and whatnots in my house, so will be dropping in and out. | 15:23.53 |
| rayjj | jogux: I think I have it straightened out. Can you check the 'traversal' again and see what you get ? | 15:26.33 |
| jogux | rayjj: still looks bust to me | 15:27.45 |
| henrys | rayjj: why do folks buy 25mbs fiber when cable is 50mbs | 15:27.55 |
| | ? | 15:27.56 |
| Robin_Watts | henrys: availability | 15:29.24 |
| henrys | I'm supposed to be getting 1G in a couple weeks some of my neighbors already have it. | 15:29.48 |
| | Robin_Watts: in LA wtf? | 15:30.18 |
| rayjj | henrys: I can get > 100Mb fiber and with cable I could only go up to 20Mb (and they wanted > $800/mo for that). I was paying $200/mo for 12/1.5 and with fiber I pay $100 for 25/25 | 15:32.00 |
| henrys | rayjj: I'm getting a G for $50. | 15:33.54 |
| | rayjj: I am surprised they don't have better deals where you are. | 15:34.16 |
| rayjj | henrys: yeah, me too :-( | 15:34.27 |
| henrys | rayjj: of course comcast was on a price increase march here until the city started the fiber program and suddenly the cable prices went down and bandwith went up. | 15:35.43 |
| rayjj | henrys: that's probably the issue here. All of the municipal efforts around here have been fought by the cable providers | 15:36.37 |
| marcosw | Robin_Watts: order me a small quantity of bacon salt from your preferred vendor. I'll pay you back in Chicago. | 15:41.50 |
| Robin_Watts | marcosw: I've got an extra one for you sat in my order basket as a thank you for carrying it. | 15:42.19 |
| henrys | marcosw: we need a good speaker solution for Joseph and Pete next meeting in Chicago. Do you have something we can use? | 15:49.55 |
| | marcosw: we'll be using skype | 15:50.45 |
| marcosw | I can bring some usb speakers. What about a mic? it's going to be hard to capture all of our voices around a table. | 15:54.16 |
| jogux | marcosw: robin suggested http://www.amazon.com/Jabra-SPEAK410-Speakerphone-Skype-other/dp/B007SHJIO2 | 15:54.42 |
| | (which still won't get everyone, but it'll work for 4-5 or so hopefully) | 15:55.02 |
| sebras | tor8: mvrhel_laptop: yes, you'd probably be better off forgetting about sebras/forms. | 16:08.34 |
| mvrhel_laptop | ok | 16:08.43 |
| sebras | it was just an attempt, and didn't get very far. | 16:09.17 |
| mvrhel_laptop | I know what that is all about... | 16:15.28 |
| | bbiaw | 16:15.32 |
| henrys | marcosw: so do you want to get that speakerphone or I can do it if you want or another idea? | 16:39.16 |
| marcosw | henrys: I can get the spakerphone. | 16:41.21 |
| henrys | marcosw: super | 16:41.30 |
| marcosw | it has 4.8 out of 5 stars with 230 reviews. | 16:42.20 |
| Robin_Watts | marcosw: Yeah, it doesn't seem like a bad bit of kit to have available to us. | 16:43.01 |
| jogux | marcosw: great, thanks! | 16:43.36 |
| amish | Looking at moving from 1.6 to 1.7 in our reader using MuPDF. We used to add highlights by adding display nodes into the display list. how do we do port this over to the array mechanism? | 16:53.07 |
| Robin_Watts | amish: You can't. | 16:55.09 |
| | At least, not easily. | 16:56.01 |
| amish_ | do we have to add the highlights on top of the words now? | 16:56.18 |
| Robin_Watts | That's the easiest solution, yes. | 16:56.35 |
| | If you really want to be able to highlight behind the words, there is a way, I guess... | 16:56.54 |
| amish_ | we had problems with the highlights being harder to read | 16:57.06 |
| Robin_Watts | you write another device that just passes calls through - trivial to do. | 16:57.16 |
| | Then you make that device spot the call to display the text you want to highlight. | 16:57.37 |
| | and rather than passing that call through, you make the device calls to do the highlight, and *then* you pass it through. | 16:58.05 |
| | So you don't have to change the displaylist at all. | 16:58.14 |
| | Does that make sense? | 16:58.18 |
| amish_ | yeah | 16:58.25 |
| | is there an example? | 16:58.38 |
| Robin_Watts | Hold on. I'll look. | 16:58.52 |
| amish_ | seems like the custom device "decorates" calls to the existing one | 16:59.29 |
| Robin_Watts | exactly. | 16:59.37 |
| amish_ | how do we port our existing highlights over to the new scheme? | 17:00.15 |
| Robin_Watts | If you look at source/fitz/trace-device.c, that's a simple device. | 17:00.25 |
| | All it does is printf details of the values it's called with. | 17:00.47 |
| | amish_: Not sure I follow your question... | 17:01.15 |
| amish_ | ok thanks | 17:01.16 |
| | we have highlights generated by users using 1.6 saved in our database | 17:01.35 |
| Robin_Watts | amish_: In what form are they stored? | 17:01.50 |
| amish_ | When they upgrade to 1.7, we need to be able restore them | 17:01.56 |
| | so that they can view these highlights | 17:02.07 |
| Robin_Watts | I understand the requirement now, thanks. | 17:02.19 |
| | What information is stored for each highlight? | 17:02.28 |
| amish_ | we used to use the textspan and texttoken to restore this | 17:02.29 |
| | but it looks like the model has changed | 17:02.46 |
| | so we need to upgrade them to the new model | 17:02.57 |
| Robin_Watts | How did you go from textspan/texttoken to display list position? | 17:03.04 |
| | textspans are given by running the page (or displaylist) through the text extraction device. | 17:03.57 |
| amish_ | we get the textspan and text token for the start and end of the highlight positions | 17:04.01 |
| Robin_Watts | The order of textspans in the output of the text extraction device does not necessarily match up with the order of the text within the displaylist. | 17:04.39 |
| amish_ | we have to get the text also fromthe highlths | 17:04.43 |
| | hmm. interesting did not know this | 17:05.11 |
| Robin_Watts | Hence you must have some way of knowing where in the displaylist you have to put the highlight for a given bit of text. | 17:05.30 |
| | amish_: PDF basically says "put glyph G of size S at (X,Y)" | 17:06.08 |
| | and it does that for every char in the page. | 17:06.15 |
| amish_ | i see | 17:06.35 |
| Robin_Watts | Nothing is guaranteed about the order in which the glyphs on a page are generated. | 17:06.38 |
| | Now, *most* of the time, *most* files generate *most* of their text in a *mostly* sane order. | 17:07.00 |
| amish_ | yeah we have seen this as well | 17:07.11 |
| | right, for some books we see that the text order is just very bad | 17:07.43 |
| Robin_Watts | We *try* to collate text into a sensible reading order as part of the text extraction device, but it relies on heuristics and sometimes it falls down. | 17:07.47 |
| | amish_: Yeah. It's one thing to cope with books where text is in a single column, but when you have multiple columns etc (like a newspaper) it all gets more hairy. | 17:08.26 |
| amish_ | right, we have seen calculus books are particularly bad for us | 17:08.59 |
| Robin_Watts | So, what exact information do you have in the highlight database? | 17:09.19 |
| amish_ | mupdf seems to do ok with multi-columns most of the time | 17:09.27 |
| Robin_Watts | amish_: Yeah, the code we have tries to cope with multiple columns. | 17:09.49 |
| amish_ | startPosition - {"textSpanIndex":8,"textTokenIndex":3} | 17:10.03 |
| Robin_Watts | (and most pdf generators tend to send all the first column then all the second column) | 17:10.09 |
| amish_ | endPosition - {"textSpanIndex":16,"textTokenIndex":5} | 17:10.43 |
| henrys | Sabrina is off to South Park for an art show, yes it really does exist! It has been nicknamed the "The Real South Park", spectacular place: https://en.wikipedia.org/wiki/South_Park_(Park_County,_Colorado), wish I thought to recommend it for you guys while you were here, just a bit over an hour from Denver. | 17:10.50 |
| amish_ | we store the color separately | 17:11.02 |
| Robin_Watts | so textSpanIndex is 'the number of the textspan in the text extraction device output where the highlight should start' ? | 17:11.39 |
| amish_ | exactly | 17:11.46 |
| | for the page of course | 17:11.54 |
| Robin_Watts | That's really fragile. Any change to our text extraction algorithm will render those values changed :( | 17:12.13 |
| amish_ | its worked so far for 4 yrs :) | 17:12.34 |
| Robin_Watts | Yeah, cos you're 4 years out of date with your source code :) | 17:12.50 |
| amish_ | we are at 1.6 | 17:13.07 |
| Robin_Watts | If I change the heuristics to better spot columns etc, then the order of textspans will change. | 17:13.29 |
| amish_ | on our mobile clients at least | 17:13.32 |
| Robin_Watts | and hence your highlights will be wrong :( | 17:13.36 |
| amish_ | yeah I get that | 17:13.36 |
| | what's the better way? | 17:13.49 |
| Robin_Watts | Not sure, need to think about it. | 17:14.23 |
| henrys | bbiab | 17:14.34 |
| amish_ | ok thanks. my email is amish.shah@intel.com | 17:14.45 |
| Robin_Watts | So, how do you know at what point in the displaylist to add your highlights ? | 17:14.47 |
| amish_ | based on the x,y position we look for a text node that maps to that | 17:15.19 |
| Robin_Watts | You run through looking for a text call that includes displaying a char at the position? | 17:15.25 |
| | amish_: Right. | 17:15.32 |
| | I'd be tempted to store highlights as a set of rectangles. | 17:15.56 |
| amish_ | hmm, you mean x,y,width,height | 17:16.35 |
| | of all the words? | 17:16.53 |
| Robin_Watts | A highlight would be a set of x,y,width,height values, yes. | 17:17.05 |
| | Then your custom highlight device would know about the set of highlights on a page. | 17:17.34 |
| | You'd run the display list into your device. | 17:17.47 |
| | Whenever you get a text marking operation, you check to see if it would mark within one of your highlight rectangles. | 17:18.19 |
| | If it does, you draw the highlight rectangle, and mark it as being drawn. Then you pass on the call. | 17:18.40 |
| | That way all the rectangles get drawn 'just in time'. | 17:18.48 |
| | and if we later change the order of text extraction, the highlight database stays valid. | 17:19.16 |
| | Does that make sense? | 17:19.22 |
| amish_ | yeah unfortunately so | 17:19.39 |
| | :( | 17:19.43 |
| Robin_Watts | The device itself is pretty simple to write. I can probably knock up a basic version for you in a couple of hours if you want. | 17:20.32 |
| amish_ | sure thanks | 17:20.41 |
| Robin_Watts | Converting from the old format to the new format shouldn't be too hard either - you must presumably have code to go from the old version to rectangles anyway? | 17:21.04 |
| amish_ | problem is we will have to support both models for a while | 17:21.10 |
| Robin_Watts | amish_: Whenever you meet the old version, you rewrite it into the new version. | 17:21.34 |
| | Or do you need to ensure the database ports both ways? | 17:21.52 |
| amish_ | Not sure how to rewrite to new version | 17:22.02 |
| | yeah we need both ways | 17:22.09 |
| Robin_Watts | amish_: Well, your existing code must know how to get a rectangle (or rectangles) from the 'startIndex/endIndex' stuff, right? | 17:22.50 |
| amish_ | oh yeah right | 17:23.09 |
| Robin_Watts | You could possibly just keep both startIndex/endIndex *and* rectangles in the database? | 17:23.44 |
| | And that would work for old and new versions. | 17:23.57 |
| amish_ | yeah right we could do this | 17:24.21 |
| Robin_Watts | If we ever change the order in which text is extracted, then the startIndex/endIndex would give screwy results, but hopefully by then people will have upgraded to the new versions. | 17:24.47 |
| amish_ | yeah ok thanks | 17:25.41 |
| Robin_Watts | amish_: OK. I'll have a quick look at that device for you. Are you going to be around for a couple of hours? | 17:26.02 |
| amish_ | yes. beginning of my day. I am PST | 17:26.46 |
| | thanks | 17:26.52 |
| Robin_Watts | amish_: No worries. | 17:27.07 |
| amish_ | what the performance improvement in 1.7 over 1.6? | 17:27.17 |
| Robin_Watts | amish_: Memory usage, lots. | 17:27.30 |
| | Displaylists are much smaller now. | 17:27.37 |
| amish_ | cool. | 17:27.47 |
| | that's great. It will make this worth while :) | 17:28.12 |
| Robin_Watts | amish_: Oh, and 1.7 does epub too, which may or may not be of interest to you. | 17:39.09 |
| mvrhel_laptop | so I have a form pdf file here which mupdf is giving me garbage for the text content in the widgets (initially) . I wonder if this is some unicode issue? For example the windows app populates its selection box for the combo box with garbarge | 18:13.08 |
| | bbiab. | 18:13.12 |
| Robin_Watts | amish_: Email with first version in sent. | 18:16.14 |
| | There are 3 FIXMEs showing areas that you'll need to fill in. | 18:16.27 |
| | Hopefully this should get you going. Please don't hesitate to ask more questions. | 18:16.41 |
| | amish_: I'm in the UK, so coming towards the end of my day now, but I'll be back online tomorrow. | 18:17.14 |
| | mvrhel_laptop: Does the same pdf work under Android MuPDF? | 18:17.35 |
| mvrhel_laptop | Robin_Watts: I will give it a try | 18:49.36 |
| Robin_Watts | mvrhel_laptop: It wouldn't surprise me if some PDFs fail to work because of the encodings they use for text. | 18:51.42 |
| mvrhel_laptop | need to charge my android device before testing... | 19:01.12 |
| henrys | can somebody undo the fred commit notifications? | 19:07.06 |
| | I think we just need notifications for the main repo | 19:07.57 |
| _wiz_ | robin: I filed http://bugs.ghostscript.com/show_bug.cgi?id=696183 about the memento.h problem. | 19:11.16 |
| Robin_Watts | _wiz_: Thanks. | 19:13.30 |
| _wiz_ | is that enough info in there? | 19:13.37 |
| Robin_Watts | _wiz_: Yes, thanks. | 19:14.02 |
| | henrys: I have done. | 19:15.09 |
| henrys | thank you | 19:16.22 |
| Robin_Watts | It's been bugging me for ages, but I didn't feel right acting unilaterally :) | 19:16.41 |
| _wiz_ | ok, enjoy your hacking! | 19:16.47 |
| | cu | 19:16.48 |
| amish_ | thanks | 20:33.19 |
| fredross-perry | mvrhel_laptop: Robin_Watts: check an email I just sent you. Thanks. | 20:41.04 |
| mvrhel_laptop | fredross-perry: no email | 21:44.50 |
| fredross-perry | try this: http://ghostscript.com/~fred/gsview-proof.png | 21:47.22 |
| | even so, turning on individual separations seems to render correctly. | 21:49.09 |
| mvrhel_laptop | fredross-perry: what is wrong with the alpha rgb values? | 22:18.05 |
| | alpha is ff | 22:18.30 |
| | the order is odd I suppose | 22:18.53 |
| | for cyan red is 00 | 22:19.06 |
| | g is ae | 22:19.11 |
| | b is ef | 22:19.14 |
| | I suppose that order matches up with the cmyk order there | 22:19.54 |
| | where c is ff | 22:20.08 |
| | and the rest are 00 | 22:20.12 |
| | ah stumble upon a memory leak in gsview... | 22:21.13 |
| fredross-perry | so for cyan Iâd expect alpha to be ff, and to see two more ffâs for g and b. If the value is really abgr, then Iâd expect ffffff00, not ffefaeoo | 22:21.55 |
| | and black should be ff000000 | 22:22.38 |
| | Working now. âMuPDF returns RGBA as bytes. Android wants a packed BGRA intâ. Apprently the same holds tru for Qt. | 22:31.20 |
| mvrhel_laptop | fredross-perry: no the rgb are color managed | 22:31.53 |
| | so it is not a simple 255-X type of thing | 22:32.00 |
| fredross-perry | got it. | 22:32.08 |
| | this is working on OSX: http://ghostscript.com/~fred/gsview%20OSX%20proofing.png | 23:14.53 |
| Robin_Watts | Cool. | 23:16.44 |
| | fredross-perry: Just saw your mail. Sounds like mvrhel explained stuff and there isn't a problem? | 23:17.08 |
| fredross-perry | mvrhel_laptop: Robin_Watts: I realized that mupdf is keeping track of which separations are disabled, so I added some plumbing to make that data accessible to the app to manage the check boxes on that dialog. | 23:17.36 |
| | yes, I am all set there. Just simple byte swapping (but different from Android) to get colors that I can use to reder swatches. | 23:18.05 |
| Robin_Watts | You mean plumbing from the C core into the C++ world ? | 23:18.43 |
| | fredross-perry: are macs still big endian? | 23:19.07 |
| | no, intel now. | 23:19.18 |
| fredross-perry | yes, intel now. | 23:19.27 |
| | plumbing = int fz_separation_disabled_on_page (fz_context *ctx, fz_page *, int sep); in document.h, and all that that entails. | 23:19.54 |
| Robin_Watts | ok. I'm going to bed. workmen arriving in less than 8 hours :( | 23:19.59 |
| | fredross-perry: Gotcha. Cool. | 23:20.03 |
| fredross-perry | Iâll check something in so you can see. I followed fz_control_separation_on_page as an example. | 23:20.20 |
| | ânight | 23:20.30 |
| | Forward 1 day (to 2015/09/09)>>> | |
IRC Logs
