| <<<Back 1 day (to 2013/07/23) | 2013/07/24 |
kens | chrisl is ther a 'make soinstaall' on the Mac build ? | 07:48.18 |
| Stack Overflow question: | 07:48.35 |
| http://stackoverflow.com/questions/17823655/compile-ghostscript-9-07-share-library-on-mac | 07:48.35 |
chrisl | There might be, but I doubt it would work correctly on the Mac | 07:48.53 |
| kens: I'll reply in a bit... | 07:50.36 |
kens | OK thanks | 07:50.48 |
bremby | hello | 09:07.32 |
| I'm trying to convert PNG images into EPS files for use in Latex | 09:07.51 |
| I use imagemagick for that | 09:08.06 |
| the resulting image appears stretched, though | 09:08.22 |
| when I open the resulting EPS file in gv, or resulting PS or PDF file after tex compilation, the image is obviously larger than the original and so blurry | 09:09.41 |
| can anyone shed some light on this, please? | 09:10.01 |
sebras | Robin_Watts: ehm.. what made ghostbot do that?! | 09:11.27 |
bremby | sebras: looks like IRC thinks I am logged in as root at my domain | 09:12.51 |
| sebras: I have no idea why | 09:13.29 |
Robin_Watts | tor7: So, the opengl app that you have tigering... | 09:27.15 |
| Is that doing software rendering and then displaying textures with opengl? | 09:27.52 |
| or are you doing path rendering in opengl? | 09:28.01 |
tor7 | just started doing path rendering in opengl | 09:28.52 |
| but using the existing software scan converter and just turning the lines into quads | 09:29.05 |
Robin_Watts | tor7: right. | 09:29.23 |
| traps or rects ? | 09:29.38 |
tor7 | right now I'm paused between two choices | 09:29.45 |
| write a path -> trapezoid converter that does proper trapezoid scan conversion | 09:30.06 |
| or hack up everything to use a backwards compatible opengl context and the nvidia path extension | 09:30.23 |
Robin_Watts | personally, I would try the nvidia path extension. | 09:30.51 |
| because that has the most potential for speed. | 09:31.07 |
| I could imagine that the overhead of constructing many quads would mean we didn't actually gain anything. | 09:31.29 |
tor7 | I suspect that creating a path extension path object is going to be just as slow though :( | 09:31.56 |
| we'll need some way to cache these things for good re-rendering speed | 09:32.11 |
Robin_Watts | tor7: Possibly - but that would be good to know too. | 09:32.16 |
tor7 | then again, line art is hardly ever the bottle neck | 09:32.22 |
Robin_Watts | tor7: possibly we want an 'opengl-display-list' device ? | 09:32.46 |
tor7 | Robin_Watts: that's a possibility | 09:33.04 |
| or if using ancient opengl we could use opengl's built-in display lists | 09:33.18 |
| but neither the path extension, nor ancient opengl is available on mobile | 09:33.44 |
Robin_Watts | I'm sure the path extension will appear on mobile eventually - or at least, if it doesn't, we can write an equivalent. | 09:34.30 |
| New opengl spec out today. see slashdot. | 09:34.48 |
tor7 | yeah, read about it yesterday | 09:34.57 |
| it has stuff that can't be done on most commodity hardware yet IIRC | 09:35.17 |
| like shared virtual memory address space between GPU and CPU. | 09:35.33 |
| I did spend some time looking at OpenCL as well. that may end up being more useful than OpenGL for us, if we can find out how to parallelize the software renderer enough to make use of it | 09:36.48 |
sebras | bremby: that might be the reason, yes. I didn't notice that. :) | 09:58.32 |
bremby | sebras: I was so hoping you were about to reply to my question :( | 10:01.24 |
Robin_Watts | essentially your question seems to be of the form "why doesn't imagemagick work?" | 10:02.20 |
| If you can recast it into a "why doesn't ghostscript work?" then we might be able to help. | 10:02.45 |
bremby | sorry about that | 10:03.28 |
| but I don't really understand what's going under the hood, and I know ghostscript is needed to generate PS files | 10:03.53 |
| from my point of view, the problem is with representation | 10:04.22 |
| if you, guys, don't have any idea where the problem could be, that's fine | 10:05.01 |
Robin_Watts | bremby: It is possible that imagemagick is calling gs to do the conversion. | 10:05.06 |
| If you can find the exact command that imagemagick is calling, then we may be able to help. | 10:05.21 |
| There may be a --verbose flag or something that will show that. | 10:05.36 |
Robin_Watts | goes for a run, while waiting for SVN to download a 127Meg test file at what feels like modem speeds. | 10:07.48 |
bremby | hmmm | 10:09.57 |
| you were right | 10:10.01 |
| "gs" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72" -g237x214 "-sOutputFile=/tmp/magick-6277Yz5Kjc6J8mKC%d" "-f/tmp/magick-62775itoTzHjyZWD" "-f/tmp/magick-6277O1tuPbenPP9E" | 10:10.03 |
Robin_Watts | bremby: OK, so that's feeding 2 temporary files into gs. | 11:41.38 |
| and producing a png file. | 11:42.08 |
| which doesn't seem to fit with your original description of the problem | 11:42.38 |
chrisl | 1 | 11:48.51 |
bremby | Robin_Watts: I've been discussing it with sebras and we've figured it out | 11:49.47 |
| probably | 11:49.49 |
| it's caused by different DPIs and bad scaling | 11:50.33 |
Robin_Watts | bremby: Fab. Thanks sebras. | 11:51.00 |
bremby | in gv you can select Pixel based scaling, in which it works as expected | 11:51.01 |
| I just need to figure out why PDF viewers render it badly scaled | 11:51.35 |
| it seems it's only about rendering | 11:51.47 |
| anyway, thanks for caring | 11:52.27 |
| hey, I just noticed - MuPDF is a related project | 11:56.04 |
| can you explain it somehow? | 11:56.58 |
| it seems the EPS file has DPI 72 | 11:57.14 |
| my display has DPI 128x130 | 11:57.24 |
| you can just try convert any PNG image into EPS yourself and see it in gv | 11:58.02 |
| Robin_Watts | 11:58.11 |
kens | EPS (PostScript) files don't havae resolution, though images contained within might | 11:58.16 |
Robin_Watts | MuPDF is indeed a project developed by us. | 11:58.30 |
| brembly: With gs, you can try using -dDOINTERPOLATE to improve the rendering. | 12:05.32 |
| or mupdf should scale decently anyway. | 12:05.42 |
bremby | Robin_Watts: here's an EPS file from sebras: http://ge.tt/3nf2vhm/v/0 | 12:14.25 |
| try opening that in gv | 12:14.36 |
kens | bremby what happens if you openthe file in GS ? | 12:14.57 |
bremby | https://upload.wikimedia.org/wikipedia/commons/f/fe/06-02-05-embr-entry-1.png | 12:15.04 |
| that's the original | 12:15.10 |
chrisl | bremby: that eps looks fine in gv to me..... | 12:16.07 |
bremby | isn't it blurry? | 12:16.27 |
chrisl | There is aliasing, if that's what you mean | 12:17.02 |
bremby | both sebras and me can see how it got larger than the original | 12:17.08 |
Robin_Watts | bremby: I don't have gv installed. | 12:18.12 |
sebras | chrisl: in gv if you select natural size vs pixel size you get different renderings. | 12:18.13 |
kens | Rendering the EPS with Ghostscritp at 72 dpi gives essentially identical output to the original PNG | 12:18.58 |
sebras | chrisl: as I read gv's manual they scale the image to the measurements (pixels * dpi) of the input file when set to natural size. when set to pixel size there is no scaling. | 12:19.10 |
| chrisl: so using pixel size makes the file look ok. | 12:19.22 |
chrisl | sebras: but that makes no sense since PS doesn't have a "natural size" | 12:19.35 |
kens | I'm guessing 'natural size' = 72 dpi | 12:20.04 |
sebras | chrisl: well, the embedded png has dimensions in pixels and is set to 72 dpi, no..? | 12:20.08 |
chrisl | sebras: there's no embedded png | 12:20.24 |
kens | chrisl thre's something in there which oudl be a PNG | 12:20.49 |
sebras | chrisl: embedded pixel data then. | 12:20.52 |
kens | THeres a PS program to read it | 12:21.00 |
| Itisn't a regular image | 12:21.08 |
sebras | http://www.gnu.org/software/gv/manual/gv.html#Scales this is the part of the gv manual I interpreted as doing the scaling. | 12:21.22 |
chrisl | It doesn't really tell us how gv is driving ghostscript for the two settings | 12:22.07 |
kens | Ick, it uses colorimage | 12:22.11 |
sebras | chrisl: no I know. | 12:22.26 |
kens | chrisl I reckon it just uses different resolution, compare the output at 72 dpi vs teh output at 96 dpi | 12:22.35 |
| (using GS) | 12:22.45 |
chrisl | kens: very likely. | 12:23.07 |
kens | Using -DDOINTERPOLATE produces nicer output | 12:23.46 |
chrisl | It does seem that somewhere in the process, the original image is being downsampled | 12:24.39 |
bremby | chrisl: what makes you think that? | 12:25.42 |
chrisl | bremby: the quality of the image in your EPS is much lower than the original PNG | 12:26.04 |
bremby | but if you select Pixel based scaling, then the image is the SAME | 12:26.37 |
| same resolution, same size, same image | 12:26.47 |
chrisl | bremby: I don't really understand what pixel/natural scaling is doing - it *seems* to be doing more than just changing the resolution | 12:29.29 |
kens | chrisl the image in the EPS seems to be the same size as the PNG, 237x214 | 12:29.43 |
chrisl | kens: and what is the image matrix? | 12:30.10 |
kens | DOn't know. I meant the raw data in the image is the same as the raw data in the PNG fikle. | 12:30.31 |
chrisl | Okay, so not being downsampled - I get some strange rendering in gv at different zoom levels, which looked like downsampling | 12:31.55 |
kens | matrix is 237 0 0 -214 0 214 | 12:32.23 |
| I see different results depending on resolution | 12:32.41 |
| Because, if you scale the image data in non-integer factors, then some vertical/horizontal lines end up wider than others | 12:33.17 |
| Depending on how the user space co-ordinates map to device space | 12:33.31 |
| Obviously I'm not running Linux so I'm not tetsing gv, but presonally I do not see any indication of a bug. | 12:33.57 |
chrisl | So, yes, it does seem that "natural size" is probably 96dpi, and pixel based is 72dpi..... hence "natural size" appears larger | 12:34.25 |
kens | Yes, that seems to be what I see | 12:34.39 |
| scaling by 1.333 gives unpleasant results. But if you use -DDOINTERPOLATE, then its all good | 12:35.20 |
sebras | gv_real_xdpi = 72.0 * 72.0 * (float)gv_screen_width / (25.4 * sizeX); | 12:37.20 |
| gv_real_ydpi = 72.0 * 72.0 * (float)gv_screen_height / (25.4 * sizeY); | 12:37.20 |
| gv_pixel_xdpi = 72.0; | 12:37.20 |
| gv_pixel_ydpi = 72.0; | 12:37.20 |
| gv_screen_height and sizeX and sizeY appears to be fetched from X11 by gv. | 12:37.42 |
| I think this is the root of the problem. | 12:37.50 |
chrisl | sebras: usually that's 96dpi | 12:37.57 |
sebras | chrisl: doesn't sound unreasonable, no. but it is not a fixed dpi. | 12:38.14 |
kens | OK that's the inital code for pdfwrite with colour management done, possible ColorConversionStrategy values are now LeaveColorUnchanged, UseDeviceIndependentColor, Gray, RGB or CMYK. All seem to work with my test file (which exercises linework, image types 1,3 and 4 and shading types 1, 2 and 3). THere are some odd looking colour values which I need to check, and I would like to see if I can do a better job with sahdings, but th | 12:38.44 |
| is no longer crashes, and produces plausible looking output in almost all cases. | 12:38.44 |
kens | fetches a celebratory coffee | 12:39.20 |
chrisl | Ah, gv is using Graphics/TextAlphaBits so images don't get any anti-aliasing treatment...... | 12:39.33 |
| sebras: if you edit the gs options in the gv anti-aliased device to include "-dDOINTERPOLATE" you get much nicer results selecting anti-aliased viewing | 12:41.12 |
sebras | chrisl: confirmed. | 12:42.17 |
chrisl | So, again, I'm not really seeing any problems here | 12:44.52 |
bremby | so how do I convert the image? | 12:46.19 |
chrisl | In what way? | 12:46.30 |
bremby | in your way, with that interpolate option | 12:46.53 |
kens | Ths isn't 'converting' the image, its rendering the EPS | 12:47.32 |
bremby | ah, ok | 12:47.41 |
| ok, works | 12:49.15 |
chrisl | bremby: imagemagick might allow you to set the "interpolate" flag in the PS image dictionary | 12:49.44 |
bremby | chrisl: ok, thanks | 12:50.11 |
| hmmm | 12:50.19 |
| ok, thanks guys | 13:03.31 |
| thank you very much | 13:03.58 |
kens | You're welcome | 13:04.16 |
bremby | too bad there's no donate button on your webpage | 13:04.58 |
kens | We make money through commercial licencing | 13:05.23 |
bremby | ok | 13:05.34 |
tor7 | Robin_Watts: tiny bugfix on tor/master | 13:26.55 |
Robin_Watts | looking... | 14:01.09 |
| So you've changed the clip, but not the bbox. | 14:01.44 |
| ok. | 14:03.55 |
| looks good to me. | 14:04.03 |
henrys | kens:wow congratulations! nice | 14:07.46 |
kens | thx henrsy | 14:08.25 |
| looking at some of the odd colour conversions now | 14:08.56 |
Robin_Watts | tor7: Small fix on robin/master, plus the CHANGES file. | 14:20.00 |
sebras | Robin_Watts: not that it matters, but why not sizeof(name)? | 14:27.56 |
Robin_Watts | sebras: That would be nicer. | 14:28.21 |
sebras | Robin_Watts: and trailing whitespace in the CHANGES file... | 14:28.28 |
Robin_Watts | BUT it makes me worry about C :) | 14:28.39 |
sebras | Robin_Watts: it does? | 14:28.50 |
Robin_Watts | In most contexts in C name is treated as a char * | 14:28.58 |
| and sizeof(char *) is not the same as sizeof(array). | 14:29.11 |
sebras | ah. | 14:29.45 |
tor7 | Robin_Watts: "sizeof buf" is pretty commonly used | 14:30.22 |
| and preferable to a magic constant number | 14:30.31 |
Robin_Watts | I'll change it if people prefer. | 14:30.33 |
tor7 | I think we usually have 'buf' in the variable name for those situations, to make more clear it's a static buffer rather than a pointer | 14:31.17 |
| statically sized | 14:31.26 |
Robin_Watts | tor7: Fixed versions of the commits on robin master then. | 14:36.17 |
tor7 | Robin_Watts: you've backup up lots of thirdparty modules this time... | 14:37.24 |
| fixes look good otherwise | 14:37.57 |
Robin_Watts | bah. | 14:38.44 |
| stupid git submodules. | 14:38.48 |
tor7 | are you using git add -a or -u or something like that? | 14:40.51 |
Robin_Watts | yeah, I'd backtracked in history, to check something earlier. My bad. | 14:41.13 |
| fixed versions up. | 14:41.21 |
henrys | is google having problems again - I can't do a web search | 14:41.52 |
tor7 | Robin_Watts: fab. they look good to go. | 14:42.19 |
henrys | nvm it's back | 14:42.46 |
chrisl | Okay, can someone remind me (once again - sorry!) how to update the thirparty submodules in mupdf? | 14:49.22 |
Robin_Watts | git submodule update --init | 14:50.03 |
sebras | tor7: btw, was there anything apart from the rewording of the commit message (Have... do...) that you wanted me to update on sebras/master? | 14:50.13 |
chrisl | Robin_Watts: ta | 14:50.29 |
Robin_Watts | git config alias.dothatsubmodulethang="submodule update --init" | 14:50.43 |
| tor7: Did you cluster test the edge list min/max change? | 14:51.45 |
chrisl | Robin_Watts: that's only going to be useful if I remember what I put for "dothatsubmodulethang" | 14:51.45 |
tor7 | Robin_Watts: no. without the change I couldn't do the opengl tiger (since I hadn't set up a scissor rect) | 14:52.42 |
Robin_Watts | tor7: It upsets mujstest | 14:52.55 |
| will investigate. | 14:52.58 |
dogisfat | I have an image that is intercepted in my driver in the begin_typed_image portion. The image is clipped into a shape in the original drawing. | 14:53.36 |
| I would have thought the gx_clip_path provided in the begin_typed_image call would have contained the clipping path, but when I look at the data in the provided path, it is empty. | 14:53.59 |
| Where else might I find the clip path for the image? | 14:54.44 |
kens | In the device clip method | 14:55.27 |
dogisfat | Which device would be best to look at for an example? | 14:56.17 |
kens | pdfwrite ? | 14:57.14 |
dogisfat | Thank you. | 14:57.33 |
Robin_Watts | kens: Which device proc is that? | 14:58.51 |
kens | Don't know offhand | 14:59.03 |
Robin_Watts | I can't see an obvious one. | 14:59.11 |
| dogisfat: Is this a PDF file as input or a PS file? | 14:59.33 |
sebras | Robin_Watts: echo -e '#!/bin/sh\ngit submodule update --init' > .git/hooks/post-checkout && chmod 755 .git/hooks/post-checkout | 15:00.40 |
dogisfat | Robin_Watts: PS | 15:10.21 |
Robin_Watts | ok, so it won't be a wierd transparency thing. | 15:10.35 |
| It could be a pattern. | 15:11.00 |
| but I would have thought you should have seen some indication of that in the previous calls to the device. | 15:11.24 |
dogisfat | Robin_Watts: GS correctly handles it, at least in the bmp16m device. I am just trying to figure out how to properly handle it myself. | 15:11.39 |
| Robin_Watts: It is definitely a typed image. | 15:12.13 |
Robin_Watts | dogisfat: You could try running it through the bmp16m device, with a breakpoint on every device function within that device. | 15:12.47 |
| Then as each one is hit, you can check whether you implement that one in your device. | 15:12.59 |
kens | Looks like ita the path method and you check the reason | 15:13.57 |
dogisfat | The bmp device relies on some other device to rasterize it. By the time it makes it to the bmp device it is already in a raster buffer. | 15:14.21 |
Robin_Watts | tor7: Another fix. | 15:25.44 |
| monxalo: Did you see my musings in the logs just after you left yesterday ? | 16:02.21 |
monxalo | ah, yes, paulgardiner has linked me a patch to do that, but don't know if that is enough. | 16:04.23 |
Robin_Watts | monxalo: I would hope that that should be enough, but paulgardiner is the expert. | 16:05.20 |
monxalo | sure, you can show them 2 side by side, and change the gaps between pages to show them side-by-side, but don't know if it enough for the zooming. | 16:10.03 |
Robin_Watts | ah, you may need to tell both pages to zoom at the same rate. | 16:10.46 |
| paulgardiner: ping? | 16:11.20 |
| monxalo: He'll be here in a mo. | 16:13.00 |
monxalo | Thanks :). | 16:13.20 |
sebras | tor7: no response on my patches? | 16:13.25 |
| tor7: they seem harmless to take on before the release. | 16:13.37 |
| tor7: they affect the debian platform files and the documentation. | 16:13.52 |
paulgardiner | monxalo: hi | 16:16.02 |
monxalo | paulgardiner: hi | 16:17.18 |
paulgardiner | Did I point you to miha's patch for 2 up? | 16:18.28 |
monxalo | yes, but i wasn't convinced it would be enough, at least for the zooming part. | 16:19.23 |
| *it wouldn't. | 16:19.32 |
paulgardiner | Possibly not. What happens when you attempt zooming with the patch applied? | 16:20.09 |
monxalo | it zooms correctly the active page, but you still have the perception that you're changing pages, instead of being one A3 landscape page, like magazines or news paper. | 16:22.59 |
paulgardiner | Right, so for your application you want the pages paired. | 16:24.54 |
| ? | 16:25.02 |
monxalo | Yes, exactly. | 16:25.10 |
| that's why i was trying to combine 2 bitmaps, it worked well but now comes the zooming part. | 16:25.54 |
paulgardiner | Rather than combine two bitmaps, you could render pairs of pages to a single bitmap. | 16:26.34 |
Robin_Watts | monxalo: I feel a better solution would be to 'pair' pages. | 16:27.02 |
paulgardiner | Much of the code would then be working as though viewing a document with double-width pages. | 16:27.12 |
Robin_Watts | so that changing the scale on one view would change the scale on the paired view. | 16:27.36 |
paulgardiner | The single-bitmap approach might turn out to be the path of least resistance | 16:29.23 |
Robin_Watts | paulgardiner: Where is the 'scale' calculated for a view? | 16:29.41 |
monxalo | paulgardiner: What do you mean by the approach 'render pairs of pages to a single bitmap' ? | 16:29.47 |
Robin_Watts | In the view itself? | 16:29.52 |
paulgardiner | Android has a system of laying out using measureView calls. | 16:32.13 |
Robin_Watts | paulgardiner: So the view calculates it's own scale as part of measureView ? | 16:32.46 |
| Surely the view calculates it's own scale as a result of a gesture or something, and then, on the next measureView uses that scale. | 16:33.26 |
paulgardiner | ReaderView first asks the page views how big they'd like to be and then forces them to that size * scale | 16:33.38 |
Robin_Watts | I was thinking that when the view calculates it's scale, that could tell it's paired pages of the scale they should adopt. | 16:34.24 |
| or (perhaps better) when it CHANGES scale, that change is propogated to all the paired pages. | 16:35.12 |
paulgardiner | Other than in reflow mode, the page views aren't told their scale. They are told to fit to a size and then internally scale so as to obey | 16:35.25 |
Robin_Watts | paulgardiner: So the next level thing up (the adapter?) could arrange for views to scale in sync? | 16:36.12 |
paulgardiner | I'm pretty sure the paired-pages approach could be made to work, just not sure it has advantages over rendering to a two-up bitmap | 16:37.04 |
monxalo | Yes, it's merely preception. | 16:39.14 |
paulgardiner | Robin_Watts: Yes. The system calls ReaderView's measureView method. I response, ReaderView calls measure twice on each page: once to find out what size they want to be, and secondly to tell them to be a certain size, that size being the scale times what they wanted to be | 16:39.34 |
Robin_Watts | It feels nice to me having "views" be "pages". | 16:40.31 |
paulgardiner | s/I/In/ | 16:40.33 |
Robin_Watts | and it would allow us to animate between different page layouts more easily, I'd imagine, if we ever wanted to do that. | 16:40.58 |
| In a double page view mode, I'd expect to see a small gap between pages, not to have them exactly abutting. | 16:42.34 |
| with view-per-page that's no problem | 16:42.44 |
| with 2pages-in-a-view that means the view is transparent. | 16:43.02 |
| which is bad for speed. | 16:43.07 |
| having 2pages-in-a-view, you have to have 'duplexing' code within views; 2 hq redraws, 2 lowq redraws, have to check which page clicks etc are on. | 16:44.27 |
| My gut says that for the sake of a little complexity to cope with zooming pairs of pages in sync, it'll be overall simpler that way. But I could be wrong. | 16:45.18 |
paulgardiner | Yeah. That's a point, especially the click handling could get messy. | 16:45.21 |
| I was just looking for ways to avoid too much change to ReaderView, because it's quite complicated and difficult to work on. | 16:47.14 |
| Making a big change to how it choreographs page movement could be almost a rewrite. | 16:47.47 |
monxalo | paulgardiner: Exactly, that's why i was opting to have my own TwoPageView and take care of that. | 16:48.15 |
| the downside is much code will be duplicated. | 16:48.35 |
kens | Night all | 16:48.42 |
monxalo | unlesss i could somehow extend PageView to reuse some functionality. | 16:49.09 |
paulgardiner | The TwoPageView may be good but doesn't have the easy extension to on-the-fly layout changes. | 16:49.53 |
| monxalo: I was assuming you meant TwoPageView to be a ViewGroup containing two PageViews | 16:52.56 |
| It would also need to support the MuPDFView interface | 16:53.49 |
monxalo | paulgardiner: I tried that, but has too many weird behaviours. | 16:54.13 |
paulgardiner | In what way? | 16:54.35 |
| You'd need to pass on calls to measureView and layout very carefully. | 16:55.25 |
| but I'd have thought it could be made to work. | 16:55.40 |
monxalo | I can't recall exactly, but i couldn't render the pages correctly, they would stretch. | 16:56.07 |
paulgardiner | measureView (in the UNSPECIFIED case) would want to sum the widths of the two subviews. | 16:56.18 |
monxalo | Yes, i extended the MuPDFView interface to support some aditional methods. | 16:56.36 |
paulgardiner | monxalo: yeah, stretching is exactly the sort of thing that would happen if the measureView and layout calls weren't quite wired up correctly. | 16:57.09 |
| measureView in the EXACT case is probably quite nasty. It would need to reask the subviews what size they want to be, then work out the scale and split up the sent-down width between them | 16:58.54 |
| So, if that wasn't what you meant by TwoPageView, what were you intending? One view with two pages on a single bitmap? | 16:59.59 |
| I don't know. Maybe it would be better to bite the bullet and do all the change in ReaderView: introduce the pairing only within ReaderView's view-placement calculations. | 17:01.34 |
monxalo | Yes, what i tried was reuse much of code of the PageView, and create my TwoPageVIew where basically onMeasure just duplicates the width. | 17:01.38 |
paulgardiner | At least that way all the rest of the code remains the same. | 17:01.46 |
| monxalo: All three of these approaches should be possible, but they all have disadvantages. | 17:02.40 |
Robin_Watts | paulgardiner: Can I distract you for a mo? In pdf-form.c line 441 you get a pdf_field_value | 17:03.51 |
| I am seeing that leaked. | 17:04.00 |
monxalo | That advantage with this is that i'm not changing any the existing code :), just adding basically a TwoPageView, and an TwoPageAdapter. | 17:04.06 |
Robin_Watts | (I don't know if it's always leaked or whether it's just sometimes leaked) | 17:04.23 |
monxalo | But thanks for the inputs and insights, i'll try these and see how it works out :). | 17:04.55 |
paulgardiner | Robin_Watts: my pdf-form.c has changes. What's there? | 17:05.07 |
Robin_Watts | ok.not always leaked. | 17:05.11 |
| This is inside pdf_update_appearance, in the PDF_WIDGET_TYPE_TEXT | 17:05.31 |
paulgardiner | monxalo: the problem with Page pairing of both types we've discussed is that you might get the basic display working, but then run into lots of nasty fiddling to get search and link following working | 17:06.29 |
Robin_Watts | and selections. and annotations. | 17:06.57 |
paulgardiner | monxalo: yes, as Robin_Watts says, all that may be difficult. | 17:08.02 |
Robin_Watts | Ah! Always leaked, I think. | 17:09.05 |
| I suspect I just need an fz_free(ctx, e.value) after the pdf_js_setup_event? | 17:10.04 |
| pdf_js_setup_event strdups e.value and then it's never used again. | 17:10.50 |
paulgardiner | Robin_Watts: Yes, that's a leak alright. Looks like it needs a try/catch | 17:11.01 |
Robin_Watts | because the pdf_js_setup_event may fail to strdup? | 17:11.25 |
paulgardiner | I hadn't looked inside the calls, but I'd imagine it strdups, and yes that could fail | 17:12.39 |
Robin_Watts | ok. testing fix now. | 17:13.07 |
| paulgardiner: fix (actually 2 fixes) on robin/master then. | 17:15.42 |
paulgardiner | Probably, we should change the name of pdf_field_value to reflect that the result need freeing | 17:16.34 |
ray_laptop | I think peeves is sick. It's taking minutes 3+ to build gs after one file changed. Hung up linking | 17:17.11 |
| it took almost a minute to save a file and exit vim | 17:17.39 |
Robin_Watts | Load average of 13 | 17:17.51 |
paulgardiner | Robin_Watts: both look fine | 17:17.56 |
Robin_Watts | ray_laptop: You have a firefox of 494meg, of which only 39 is resident. | 17:19.00 |
| I think you may be swapping :) | 17:19.07 |
| actually, no, swap looks Ok. | 17:19.52 |
| paulgardiner: Thanks. 1 more fix there. | 17:20.32 |
paulgardiner | Robin_Watts: That one fine too | 17:23.45 |
Robin_Watts | paulgardiner: Thanks. | 17:23.53 |
| marcosw: If I clusterpush a "mupdf mujstest" job, is that going to cause problems? | 17:27.47 |
| specifically, will it cause files to be tested in mudraw that otherwise would not? | 17:28.03 |
| I'm guessing that tests_private/pdf/forms/*/*.pdf are not tested in mudraw generally? | 17:28.27 |
Robin_Watts | repeats for marcosw1 :) | 17:28.38 |
| marcosw: If I clusterpush a "mupdf mujstest" job, is that going to cause problems? | 17:28.40 |
| specifically, will it cause files to be tested in mudraw that otherwise would not? | 17:28.44 |
mvrhel_laptop | chrisl: you around still? | 18:03.38 |
| I forgot to test the ARM program yesterday | 18:03.48 |
| I will take care of that today | 18:03.52 |
chrisl | mvrhel_laptop: sorry, was working on the laptop - as I said, no major rush. I'll be a little surprised if it actually works! | 18:20.00 |
| I am going to finish for the day, though - I've got a headache coming on... | 18:22.09 |
marcosw | Robin_Watts: I don't think it will work... | 18:33.16 |
| the regression test is hardwired so that mujstest uses the file from pdf/forms and mupdf uses the same files as Ghostscript (except not the ghostscript ones). I could change it so that mupdf also tests the pdf/forms files. | 18:35.31 |
Robin_Watts | marcosw: No, don't worry. It explains the result I saw earlier. | 18:41.30 |
dogisfat | The paths for the image I was talking about earlier has path_valid as false, yet the PDF image clip-path handler does not check the flag. Why is this? | 18:54.17 |
| Maybe the question should be how do I know that I should look in the path_list portion of the gx_clip_path_s structure for path data as opposed to the path portion of the aforementioned structure? | 19:10.26 |
ray_laptop | MSC doesn't seem to have the POSIX strncasecmp :-( I wonder about other funky compilers, like HP-UX and AIX | 23:00.48 |
| well, it built on windoze :-\ Let's see now | 23:45.50 |
| Wow. i7 is FAST! it even beats fermis getting started | 23:47.55 |
| got 372 jobs completed by the time fermis wen to "Starting jobs" state | 23:48.41 |
| I am looking at getting one of those 1U Dells that Marcos gor for fermis to replace, or supplement peeved | 23:49.34 |
| marcosw: since it is in my office, noise isn't a super concern. Any other reason I shouldn't get one (or more) ? | 23:50.18 |
| henrys: The regression run I'm doing is for saved pages. Finishing up testing (locally) and documentation. About ready to push for comment/review. | 23:51.13 |
| except for documentation, it is "feature complete", so I'd like to get it into the 9.08 release. The primary user benefit is collated copies on jobs | 23:52.48 |
| without re-parsing | 23:52.55 |
| The primary "gotcha" is that it won't affect output to "high-level" printer formats like PXL and PS (PDF is irrelevant). | 23:54.57 |
| Forward 1 day (to 2013/07/25)>>> | |