| | <<<Back 1 day (to 2012/11/26) | 2012/11/27 |
| tor8 | Robin_Watts: sorry, was knee deep in android xml widget wizardry... | 00:23.53 |
| Robin_Watts | nae problem. | 00:24.04 |
| tor8 | Robin_Watts: haven't had a chance to review it yet and now I'm too tired to trust myself. I do have a few commits on tor/master which update the android looks a bit (maybe you hate it, I tried to make it neat and consistent on all devices and sort of windows phone 7 / metro-ish) | 00:25.04 |
| | let me push first though :) | 00:25.09 |
| | Robin_Watts: okay, do give tor/master a try if you got a moment | 00:27.41 |
| Robin_Watts | I'm off to bed in a mo, but I will try tor/master and tor/gamma tomorrow first thing. | 00:28.15 |
| tor8 | Robin_Watts: alright. good night! | 00:28.26 |
| Robin_Watts | http://semiaccurate.com/2012/11/26/intel-kills-off-the-desktop-pcs-go-with-it/ | 10:19.26 |
| kens | Hmm 'kills hte PC' is a bit overstated. | 10:21.51 |
| | Not that many people ever changed the CPU | 10:22.09 |
| Robin_Watts | ahem. | 10:24.45 |
| tor8 | Robin_Watts: morning | 11:29.41 |
| | paulgardiner: morning to you too :) | 11:29.54 |
| | and everyone else | 11:30.01 |
| paulgardiner | hi tor8 | 11:37.21 |
| tor8 | paulgardiner: have you ever tested XPS with the android app? I'm getting odd crashes and behaviour with that... | 11:39.01 |
| | and a warning or too, which is due to a limitation of our XPS parser | 11:39.15 |
| paulgardiner | Ah no, I haven't. | 11:39.23 |
| tor8 | in XPS you don't know where the links are unless you've interpreted the page first :( | 11:39.35 |
| paulgardiner | But I'm guessing the crash you mentioned yesterday was PDF? | 11:39.43 |
| tor8 | paulgardiner: the crash yesterday was PDF, yes | 11:39.54 |
| | it happened during zooming or showing/hiding the ui controls, so might be (yet another...) rare race condition | 11:40.42 |
| paulgardiner | I've hammered various PDFs using latest source here and I haven't managed to repeat it. | 11:40.48 |
| tor8 | paulgardiner: if you try out tor/master I've done some messing about with the layouts and drawables for the android app | 11:41.13 |
| paulgardiner | I'm now madly zooming and tapping for the menu! | 11:42.37 |
| | tor8: Is that aesthetic changes? | 11:43.41 |
| | On thing I may have messed up for XPS is using the result of fz_interact without first testing for NULL. | 11:45.40 |
| | s/On/One/ | 11:45.50 |
| tor8 | paulgardiner: yeah. and I put the link button back, with a simple on/off state for highlighting the links. | 11:46.07 |
| | no inhibit state, but I'm thinking maybe we should inhibit them if the highlight is off | 11:46.24 |
| paulgardiner | tor8: I trust your opinion entirely. Aesthetics are not my strong point. | 11:47.35 |
| | tor8: That makes sense to me: active only if hightlighted. | 11:53.20 |
| tor8 | paulgardiner: okay, I pushed new version which does that | 12:03.19 |
| paulgardiner | tor8: Did my commits get pushed or are there still problems with them? | 12:03.57 |
| tor8 | paulgardiner: I didn't push them, sorry. I thought robin would take a final look and push. | 12:07.22 |
| paulgardiner | No probs | 12:07.47 |
| tor8 | paulgardiner: I've found another really odd bug on my tablet. on one of my files it looks blurry like it's rendered at a lower-than-full-res in portrait mode. until I zoom in and then out, when it renders the page first at blurry low res then later pops in a full res one. without having zoomed the page. | 12:08.30 |
| | does my description make sense or do I need to drink more coffeine first? | 12:08.42 |
| | if I were to make a guess, it's drawing it in landscape size then thinking it's zoomed to get the portrait size rendered | 12:10.30 |
| paulgardiner | I think I understand all of that except "without having zoomed the page". Does that last bit mean it ends up correct? | 12:10.34 |
| tor8 | 1) open pdf, pan between pages. looks blurry. | 12:11.03 |
| | 2) zoom in. zoom back out. pan between pages. looks blurry first render, then pops in with a sharp version half a second later. (it's a slow rendering pdf with lots of images) | 12:11.42 |
| paulgardiner | The main view is supposed to be the perfect res for completely zoomed out, so that there is no need for an hq view | 12:11.44 |
| tor8 | 3) rotate to landscape mode. always sharp. | 12:11.56 |
| | so I'm thinking for this one pdf it thinks the portrait mode nedes an hq view... | 12:12.18 |
| paulgardiner | I was going to ask if it had images. Could it be the core render that is blurry? | 12:12.30 |
| tor8 | the text is blurry too | 12:12.39 |
| | it looks very much to me like the original (non-hq) view is sized for landscape even in portrait mode | 12:13.16 |
| paulgardiner | Not all documents though? | 12:13.18 |
| tor8 | nope. just this one! | 12:13.57 |
| | let me see if I can reproduce it on my phone as well. | 12:14.09 |
| paulgardiner | tor8: does it make a different which way you have the device when opening the document? | 12:15.07 |
| tor8 | Rendering page(13)=799x1014 patch=[0,0,799,1014] | 12:15.23 |
| | Rendering page(13)=806x1023 patch=[6,0,800,1023] | 12:15.29 |
| | that's what I get when I pan in step (2) when it starts out blurry and comes back sharp later | 12:15.53 |
| | nope, it behaves the same way if I start in landscape | 12:16.27 |
| | so that's bigger than landscape version so forget that | 12:17.16 |
| | E/libmupdf( 3695): PageWidth=3.38499e-103 | 12:17.54 |
| | E/libmupdf( 3695): PageHeight=3.38499e-103 | 12:17.55 |
| | is that normal? | 12:17.56 |
| paulgardiner | I think I know what it is. I reckon I calculate the scale from the size I want and then later the size from the scale and in some cases I get a slightly different size. | 12:18.24 |
| tor8 | paulgardiner: yeah. I think I had a similar issue in the ios app once. | 12:18.48 |
| paulgardiner | So zoomed out isn't always an exact match. Then the blurry problem is because the hq render isn't invoked until the first zoom | 12:19.13 |
| tor8 | paulgardiner: http://www.wizards.com/dnd/files/LoD_Rulebook_EN.pdf | 12:19.55 |
| Robin_Watts | tor8: back. | 12:23.20 |
| | so, do you want to push paulgardiners stuff or should I ? | 12:23.37 |
| tor8 | Robin_Watts: push please :) | 12:23.51 |
| Robin_Watts | paulgardiner: Just pushing your stuff. | 12:24.17 |
| paulgardiner | Ta muchly | 12:24.43 |
| Robin_Watts | OK, shower, then tor/master then tor/gamma. | 12:25.02 |
| | tor8: The android logging page width and page height stuff has been doing that for ages. | 12:25.32 |
| | It may even always have been doing it. | 12:25.40 |
| | We've had a user complain before about it. | 12:25.47 |
| tor8 | Robin_Watts: alright, so I'm barking up the wrong tree. I thought that might be what caused the XPS to crash yesterday. | 12:26.14 |
| | we should stop doing that! | 12:26.20 |
| Robin_Watts | crashing? :) | 12:26.41 |
| tor8 | that too :) | 12:26.52 |
| | the links warning it prints (because the app loads the links before the page has been interpreted ... stupid XPS) should be benign, it just means there won't be any links | 12:27.41 |
| Robin_Watts | can never pull --rebase tor master without it dying in loads of conflicts. | 12:29.50 |
| paulgardiner | We could change the jni code to recognise the XPS case and load the page before getting the links | 12:29.57 |
| Robin_Watts | I always end up fetching then cherrypicking. | 12:30.00 |
| tor8 | paulgardiner: the problem with XPS is that you need to run the page first, not just load it :( | 12:30.51 |
| | do you always make a display list for the pages? | 12:31.02 |
| paulgardiner | Not until the render call, but... | 12:31.14 |
| | But it's another thing that is cached, so to do so might not be harmful | 12:32.11 |
| tor8 | paulgardiner: right. another way is to run the page through the null device in the XPS interpreter when the links are requested but haven't been loaded yet. that way the api will work, but slowly. | 12:42.56 |
| | still shouldn't cause crashes though? | 12:43.04 |
| paulgardiner | So does it look like the crashes are from elsewhere? | 12:44.21 |
| tor8 | how do I run gdb on the device? | 12:45.58 |
| Robin_Watts | ndk-dgb | 12:46.03 |
| | or ndk-gdb | 12:46.09 |
| | Start the app, then run ndk-gdb and it attaches automatically. | 12:46.28 |
| | but I haven't actually got anything useful out of it yet. | 12:46.43 |
| tor8 | ERROR: Could not extract package's data directory. Are you sure that | 12:46.58 |
| | your installed application is debuggable? | 12:46.59 |
| Robin_Watts | Are you inside the android dir? (Guessing!) | 12:47.27 |
| | I was running on windows of course. | 12:47.33 |
| tor8 | yes. I'm running on a device though, not the emulator. | 12:47.40 |
| Robin_Watts | So was I. | 12:47.45 |
| tor8 | any special ndk-build invocation to make it debug? | 12:48.18 |
| | urgh. hang on, need to downgrade to 8b, this recompiling bug is driving me nuts too. | 12:48.44 |
| Robin_Watts | tor8: Ah, so it's not just me. That's good to know. | 12:49.39 |
| | tor8: You probably need to change the 'release' line to 'debug' in... Application.mk ? | 12:50.04 |
| | or Android.mk, one of the two. | 12:50.08 |
| | application.mk | 12:50.29 |
| | I'm using r8b, and I *haven't* uncommented the NDK_TOOLCHAIN_VERSION line. | 12:51.12 |
| tor8 | trying r8b now | 12:51.48 |
| | at least it's smart enough to not recompile everything all the time | 12:51.59 |
| | but ant is really nasty in how it leaves stale files around when the layouts are edited, so the id name->number mapping is incorrect leading to all manner of odd bugs unless you clean before building | 12:52.40 |
| | um, can't compile with r8b :( | 12:53.01 |
| Robin_Watts | why not ? | 12:53.08 |
| tor8 | ld: final link failed: Nonrepresentable section on output | 12:53.13 |
| Robin_Watts | Did you clean? | 12:53.21 |
| tor8 | unresolvable R_ARM_THM_CALL relocation against symbol `strcmp | 12:53.22 |
| Robin_Watts | I've just built just fine. | 12:53.27 |
| tor8 | okay, nuking and rebuilding | 12:54.11 |
| Robin_Watts | OK. Look in application.mk | 12:54.12 |
| | OK. If it still won't work, then uncomment the NDK_TOOLCHAIN_VERSION line in application.mk | 12:54.32 |
| tor8 | ./var/folders/x7/cw421l5j1vl25k8h7b_hzd840000gn/T//cc4OK17e.s: Assembler messages: | 12:54.45 |
| | var/folders/x7/cw421l5j1vl25k8h7b_hzd840000gn/T//cc4OK17e.s: Assembler messages: | 12:54.52 |
| | var/folders/x7/cw421l5j1vl25k8h7b_hzd840000gn/T//cc4OK17e.s:2056: Warning: conditional infixes are deprecated in unified syntax | 12:54.53 |
| | var/folders/x7/cw421l5j1vl25k8h7b_hzd840000gn/T//cc4OK17e.s:2078: Warning: conditional infixes are deprecated in unified syntax | 12:54.54 |
| Robin_Watts | infix conditionals? | 12:54.55 |
| | yeah. That's the geniuses at ARM/gcc. | 12:55.05 |
| tor8 | okay, trying the toolchain version now | 12:55.32 |
| Robin_Watts | If you say "ldrgtb" (i.e. the way it has always been for years) it compiles file with all -m ARM options up to armv7 or warns thereafter. | 12:55.49 |
| tor8 | Robin_Watts: btw, I think our wall-of-text ReadMe.txt for android may scare people off with the TL;DR syndrom | 12:55.59 |
| | made a pruned down version http://ghostscript.com/~tor/stuff/android-howto.html | 12:56.16 |
| Robin_Watts | If you say "ldrbgt" (the new way) it gives an error for everything up to armv7 and compiles fine thereafter. | 12:56.43 |
| tor8 | bah. | 12:57.34 |
| | oxygen ~/src/mupdf/android $ ndk-gdb | 12:57.35 |
| | ERROR: Could not extract package's data directory. Are you sure that | 12:57.36 |
| | your installed application is debuggable? | 12:57.36 |
| Robin_Watts | tor8: Yours certainly looks pretty. | 12:58.26 |
| | but it lacks the details of the text version, and you just know we're going to get asked every one of those details again and again and again... | 12:58.53 |
| tor8 | yeah. so we should have a FAQ section at the end with all those details... why does mobile development always bring out the worst programmers in the world? | 12:59.39 |
| Robin_Watts | tor8: Oh please. You're forgetting web developers. | 13:00.00 |
| | in a word, java. or javascript. | 13:00.28 |
| tor8 | Right. PHP. I'd repressed that. | 13:00.34 |
| Robin_Watts | If you give people Fisher Price languages, you get Fisher Price programmers. | 13:00.43 |
| | mupdf is dying on startup for me. | 13:03.48 |
| | ResourcesNotFoundException | 13:04.03 |
| tor8 | Robin_Watts: with tor/master? | 13:04.07 |
| | ugh. | 13:04.10 |
| Robin_Watts | yeah. | 13:04.11 |
| | I'm guessing you forgot to check in a png or two? | 13:04.20 |
| tor8 | maybe I missed some, which resource is it asking for? | 13:04.28 |
| Robin_Watts | W/ResourceType( 6739): Failure getting entry for 0x7f020010 (t=1 e=16) in package 0 (error -2147483647) | 13:04.50 |
| | D/AndroidRuntime( 6739): Shutting down VM | 13:04.52 |
| | W/dalvikvm( 6739): threadid=1: thread exiting with uncaught exception (group=0x4001d5a0) | 13:04.54 |
| | E/AndroidRuntime( 6739): FATAL EXCEPTION: main | 13:04.56 |
| | E/AndroidRuntime( 6739): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.artifex.mupdf/com.artifex.mupdf.MuPDFActivity}: android.content.res.Resources$NotFoundException: Resource ID #0x7f020010 | 13:04.57 |
| tor8 | Robin_Watts: ComponentInfo ... sounds like errors in layout | 13:05.21 |
| | did you clean first? | 13:05.24 |
| | ant clean | 13:05.29 |
| | the layout has changed, so the IDs don't match up, which means you have to ant clean | 13:05.44 |
| | or you get errors like that | 13:05.49 |
| Robin_Watts | I didn't clean the ant stage. Sorry. | 13:06.01 |
| | ok, that works. | 13:08.14 |
| tor8 | phew. | 13:08.19 |
| Robin_Watts | ok. So, I wouldn't have chosen those icons personally, as they aren't really to my taste. BUT they are consistent and clear, so I have no real problem with them. | 13:10.16 |
| tor8 | Robin_Watts: we've had those icons forever :) | 13:10.34 |
| Robin_Watts | really? | 13:10.42 |
| tor8 | but yeah, they are kind of fat :) | 13:10.43 |
| Robin_Watts | The search bar looks very different (very 'metro') | 13:11.05 |
| tor8 | yup. ever since I replaced paul's placeholder icons way way back | 13:11.08 |
| Robin_Watts | Not search bar, page bar. | 13:11.20 |
| tor8 | I figured those icons would look nice with a clean 'metro' style design. all flat with solid colors and no gradients, faux 3d bevels, or drop shadows. | 13:11.54 |
| Robin_Watts | Right, the lack of alpha seems a shame (and not entirely in keeping with android) | 13:12.15 |
| tor8 | Robin_Watts: the solid black backgrounds on the toolbars? | 13:12.38 |
| Robin_Watts | mmm. | 13:12.44 |
| tor8 | it's easy enough to add back in. it doesn't look too good though, when the page sizes make the top of the page end up halfway through the bar | 13:13.02 |
| Robin_Watts | If they are going to have more than 1 device on the stand, it might be nice to have both versions to demonstrate the fact that the UI is not nailed down - scope for OEM customisation. | 13:13.35 |
| tor8 | Robin_Watts: just edit res/values/colors.xml, the first hex number in the 'toolbar' color is the alpha | 13:13.36 |
| | yeah. I just want a slick consistent default UI for that "awe and shock" value :) | 13:14.05 |
| Robin_Watts | It's a shame that in googles almighty wisdom they didn't have a way of having ifdefs in there. | 13:14.08 |
| | tor8, paulgardiner: Can we please, please, please, sort the contents of the file list ? | 13:14.52 |
| | And, would it be possible to put directories in the list too? With an '^' option at the top? | 13:15.33 |
| tor8 | <color name="toolbar">#C0000000</color> | 13:15.45 |
| | Robin_Watts: a full directory browser that starts at /mnt/sdcard/download would be handy :) | 13:16.12 |
| Robin_Watts | tor8: Well, paulgardiner will no doubt say that you can just use a file browser. (ASTRO or ES File Browser for example) | 13:16.40 |
| tor8 | Robin_Watts: yeah, but not too many people have those installed | 13:17.38 |
| paulgardiner | Apparently the way people tend to do this is to import soemone elses file browser. There isn't a stock Android one, and it's a lot of work to implement one. | 13:17.44 |
| | You'd think Android would have one built in, but no. | 13:18.30 |
| tor8 | paulgardiner: I know. it's really annoying though, how a lot of apps make their own file browser. they really ought to step down from their high horse and make a standard file chooser activity. | 13:18.31 |
| paulgardiner | I totally agree | 13:18.45 |
| Robin_Watts | ok, all the files that I tagged as being slow or sluggish in my run through the first half of the test suite are now fine, except one, which is just about OK. | 13:20.10 |
| | IA3Z0302.pdf | 13:20.35 |
| | And that REALLY hammers hash and fz_hash_find | 13:22.34 |
| paulgardiner | We could use the openintents file manager | 13:25.17 |
| Robin_Watts | tor8: Right. I *much* prefer the C000000 alpha thing. | 13:27.28 |
| tor8 | Robin_Watts: I don't :( | 13:27.38 |
| | but I think it depends on what files you run it on | 13:27.45 |
| Robin_Watts | If I see alpha toolbars, I think "well, I could probably turn the alpha off". | 13:27.58 |
| | If I see non alpha toolbars, it's not clear to me that the system is capable of alpha if I wanted it. | 13:28.16 |
| | I'm on a phone here, rather than a tablet. | 13:28.30 |
| | so screen real estate is at a premium. | 13:28.42 |
| tor8 | Robin_Watts: well, for a tech demo we could have a colored alpha toolbar instead of black. | 13:28.45 |
| Robin_Watts | I'm happy with black. | 13:29.16 |
| tor8 | a dark gray works well too, with those icons and the blue highlight color (same blue tint as the mupdf logo) | 13:29.45 |
| Robin_Watts | Right, but the see-throughness is important. | 13:30.05 |
| | We can canvas for other opinions and I can be overruled of course. | 13:30.50 |
| tor8 | but the see-throughness is ugly! :) | 13:31.03 |
| Robin_Watts | but my 2c is that the toolbars should be see-through. | 13:31.10 |
| | Not at all! | 13:31.14 |
| tor8 | alright, we'll canvas around. I'm okay with see-through at least temporarily :) | 13:31.40 |
| | Robin_Watts: more important though, the gamma branch | 13:31.50 |
| Robin_Watts | So, shall I change the colors thing, and push your changes ? | 13:31.57 |
| tor8 | Robin_Watts: hang on with the colors, I'll try more variants here; it may be that a dark gray with alpha makes for better see-through-ness | 13:32.42 |
| Robin_Watts | ok. | 13:32.50 |
| | ok, so can I try the gamma stuff on the desktop? | 13:33.11 |
| | (much faster turnaround that way) | 13:33.18 |
| tor8 | yeah. it clean applies on the android as well. | 13:33.26 |
| | but the desktop has faster turnaround :) | 13:33.32 |
| | the gamma has a huge effect on how things look | 13:33.42 |
| | my first gut instinct was: too grey! but the AA does look nicer with it on. | 13:34.04 |
| Robin_Watts | There may be a cheaper and cheezier way to achieve the same effect. | 13:34.33 |
| | Namely to put the aa through a lookup table. | 13:34.49 |
| tor8 | Robin_Watts: for black-text-on-white you can gamma ramp the alpha values from the font | 13:34.51 |
| | Robin_Watts: the current blend does put the colors through two lookup tables | 13:35.08 |
| Robin_Watts | on the gamma branch? yes. | 13:35.19 |
| tor8 | (not the awful float math with a ton of branches and pow() calls) | 13:35.21 |
| | (that you first saw) | 13:35.38 |
| Robin_Watts | right, but if we do it at aa plotting time, we just lookup the value in blit_aa. | 13:35.50 |
| | Which means we only need a single 8 bit lookup table. | 13:35.58 |
| tor8 | Robin_Watts: we could linearize the input color to some of the plot functions, saves us one lookup there | 13:36.45 |
| | but the destination still needs to be converted both when read and written | 13:36.59 |
| Robin_Watts | My contention is that we can get much of the same effect purely by changing the 'coverage' values. | 13:37.57 |
| tor8 | Robin_Watts: yeah, but only for black text on a white background! | 13:38.28 |
| Robin_Watts | For complex blends it will be incorrect of course, but then until we fix our complex blends to be right, I fear fiddling with the gamma is rearranging the deckchairs on the titanic. | 13:38.50 |
| tor8 | in the case of white text on a black background, it will become worse, shifting the gamma the opposite way of what should be | 13:39.10 |
| Robin_Watts | tor8: If we pick a smart doglegging curve we can have it give the right kind of effect for white on black and black on white. | 13:39.21 |
| tor8 | Robin_Watts: the pdf blend modes stuff? that's ... irrelevant. this is important for text and line art legibility :) | 13:39.40 |
| Robin_Watts | Let me grab your code and experiment. | 13:40.06 |
| tor8 | doing AA in a linear color space is something we should have done ages ago. I did experiment with your suggestion (fiddle with the coverage values) a few years ago. never was happy with the results. | 13:40.39 |
| | ideally, we want to downsample images in a linear colorspace too... | 13:40.57 |
| | but that is already the case for 1-bit black and white images, such as used in type 3 fonts. so I'm happy to leave that as is. | 13:41.47 |
| | but I want to push these blend changes into draw_affine.c as well | 13:42.10 |
| | which is going to mess with type 3 fonts :( | 13:42.31 |
| | or wait, ugh, maybe it already does, since the results of downsampling the 1-bpp images means the grayscale type 3 pixmaps are already in a linear space, and we treat them as srgb. | 13:43.17 |
| | so, grayscale -> alpha conversions (or treating a grayscale pixmap as alpha) should linearise the values | 13:44.52 |
| | since we should always everywhere treat colors as being gamma and alpha values as being linear | 13:45.15 |
| Robin_Watts | Any suggested files to view this with? | 13:45.23 |
| tor8 | pdfref13.pdf, tiger.pdf and VOX something or other in the sane suite | 13:45.55 |
| Robin_Watts | Hmm. pdf_reference17.pdf looks horrid. | 13:46.18 |
| tor8 | thin fonts, is all I can say | 13:46.36 |
| | and yes, it looks ... unusual and too light | 13:46.53 |
| | because we expect it to be darker :) | 13:47.01 |
| Robin_Watts | I have Release built from trunk, and Debug built from gamma, and I'm running them side by side. | 13:48.04 |
| | For pdf_reference17.pdf at the default 72dpi, the trunk looks clearer both with normal and inverted (i) pages. | 13:48.41 |
| tor8 | Robin_Watts: inverted the gamma branch *should* look terrible | 13:49.13 |
| Robin_Watts | (but the inversion is done by inverting the final pixmap, so may not be the same as rendering white on black in the first place) | 13:49.14 |
| tor8 | (since that will double compound the error) | 13:49.49 |
| | in the non-gamma case, both the normal and inverted are equally off from the ideal | 13:50.12 |
| Robin_Watts | There are fewer jaggies for tiger, but that may be because the thin lines just can't be seen as well. | 13:50.54 |
| tor8 | you see less stair stepping on the gamma branch | 13:51.02 |
| | try the VOX.pdf in sane, for white text on black | 13:51.11 |
| Robin_Watts | but I get nasty results on the tigers chin actually in gamma. | 13:51.29 |
| tor8 | please explain, I see nothing odd on the tiger | 13:52.09 |
| Robin_Watts | I suspect it's because with the lines that thick you hit the pattern of the pixies in the monitor. | 13:52.12 |
| | In the middle of the bottom edge of the tigers chin there is an arc. | 13:53.12 |
| tor8 | the black lips? | 13:53.49 |
| Robin_Watts | Looks like an inverted 'U' next to an 'M' | 13:53.52 |
| | No, right at the bottom edge of the tiger graphic. where the white hair has a black outline, and then the gray background. | 13:54.15 |
| tor8 | right, those just under and to the right of the lower left canine? | 13:54.21 |
| Robin_Watts | No. Right at the bottom of the whole graphic. | 13:54.51 |
| tor8 | oh, right. those lines are actually fatter than the other ones! | 13:55.20 |
| Robin_Watts | Drop a line down from the middle of his bottom row of teeth until you hit background gray. | 13:55.22 |
| | Right, Those lines look *really* stepped on my monitor. | 13:55.41 |
| tor8 | some of those arcs are offset or the wrong linewidth | 13:55.52 |
| | there's a 'step' where they meet up the normal width lines | 13:56.11 |
| | either that, or your monitor is worse than mine :) | 13:56.34 |
| Robin_Watts | I have a DELL U2410 (very nice IPS panel) but it's not calibrated. | 13:57.37 |
| tor8 | I have a Del U2713HM (decent IPS panel, high res and biiiig) | 13:58.44 |
| Robin_Watts | nice! | 13:59.57 |
| tor8 | and cheap! | 14:00.05 |
| | only problem is the damn IPS glow | 14:00.13 |
| | why did they stop putting the polarizing film on the IPS panels? | 14:00.35 |
| Robin_Watts | really? Mine was NOT cheap. | 14:00.50 |
| tor8 | well, for a 27" IPS panel it was cheap :) | 14:01.00 |
| | I paid the equivalent of about 530 GBP | 14:01.41 |
| Robin_Watts | right. | 14:01.42 |
| tor8 | ordered several and sent back the ones with dead pixels :) | 14:02.10 |
| | I love consumer rights when ordering online | 14:02.20 |
| Robin_Watts | Well, if my second 1920x1200 one dies (acer cheapy), then I may be tempted. | 14:02.28 |
| tor8 | anyway, the pdfref looking worse is sad, but I think that can be blamed on the source material having really thin fonts | 14:02.54 |
| Robin_Watts | so, where on VOX am I supposed to see an improvement? | 14:03.12 |
| tor8 | the text | 14:03.20 |
| | the images should not really be changed | 14:03.27 |
| | it looks less stair steppy | 14:03.37 |
| | and fatter | 14:03.41 |
| Robin_Watts | FEATURES and SPECIFICATIONS are harder to read on the new one. | 14:04.06 |
| | The white text is more 'solid' on the new one. | 14:04.35 |
| | I'd not swear it was easier to read though. | 14:04.57 |
| | I'm a VERY bad person for this kind of thing. | 14:05.24 |
| tor8 | no, easier to read depends on so many factors. like how we're used to the non-gamma-corrected rendering :) | 14:05.30 |
| Robin_Watts | When I did CrystalType for picsel, I had to rely heavily on getting other peoples opinion on what was an improvement and what wasn't, | 14:06.02 |
| | (CrystalType == our ClearType thing) | 14:06.13 |
| | I'm being called for lunch. back in a bit. | 14:07.02 |
| tor8 | Robin_Watts: look at the / in N/A | 14:07.05 |
| | on the VOX | 14:07.07 |
| | for a drastic difference in stair stepping | 14:07.13 |
| | okay, I'll pop out for a bit too. let's resume in an hour. | 14:07.31 |
| Robin_Watts | tor8: really, if we concerned about this ,we should do LCD optimisation on fonts. | 14:07.56 |
| tor8 | Robin_Watts: LCD optimisation on the full page could be an option | 14:08.33 |
| | but yes, hacking in RGB alpha compositing might be feasible | 14:09.19 |
| | (just not easy when you've got android devices rotating the results all over the place) | 14:09.36 |
| [1]Roman | Can anyone add their insight on http://stackoverflow.com/questions/13493559/ghostscript-postscript-pdf-cut-a-rectangle-from-a-ps-file-rotate-it-45-degree and http://stackoverflow.com/questions/13586726/rotating-a-pdf-file-by-n-degrees-where-n-is-not-a-multiple-of-90 ? | 14:51.57 |
| chrisl | [1]Roman: I doubt that can be easily achieved with Ghostscript, and I really PDF is the wrong format. EPS would be a better choice, IMHO | 14:57.53 |
| [1]Roman | Possibly, I am quite new at this :) So the pipeline would be PDF->EPS, embed EPS info PostScript, preceed with a "rotate" statement? | 14:59.32 |
| chrisl | Well, the purpose of EPS is to be embedded in a larger PS job. You can then rotate/clip as you want in the "larger" PS job | 15:00.42 |
| tor8 | Robin_Watts: back. | 15:01.21 |
| chrisl | [1]Roman: one problem that might arise is if you initial PDF has stuff that can't be represented in Postscript - mainly transparency. | 15:03.12 |
| Robin_Watts | back. | 15:07.29 |
| | tor8: If we wanted to do LCD optimisation, then we'd 'just' render every glyph to a bitmap 3 times as wide. | 15:08.44 |
| tor8 | Robin_Watts: I've implemented cleartype-style filtering before, in another project | 15:09.13 |
| Robin_Watts | Then when we play the glyph back, we map the R G and B through the filtered bitmap. | 15:09.18 |
| | right. | 15:09.21 |
| | It all gets trickier with retina screens though, where they aren't simply "RGBRGBRGB" or "BGRBGRBGR" | 15:09.58 |
| tor8 | it falls flat on AMOLED screens | 15:10.15 |
| | and I'm sensitive to the color fringing, so I absolutely hate it | 15:10.38 |
| Robin_Watts | What pattern is AMOLED ? | 15:11.24 |
| tor8 | it's the one with the pentile pattern | 15:11.51 |
| | twice as many green | 15:11.57 |
| Robin_Watts | right. | 15:12.03 |
| | You can work for that, it's just a different process. | 15:13.11 |
| tor8 | which fails if you scroll :) | 15:13.29 |
| | and I don't think you can really know just how the pattern falls on your pixels | 15:13.44 |
| Robin_Watts | If we were to work as a post process phase (similar to the way we support halftoned output) we could work it. | 15:13.57 |
| | For that one, you'd double the width rather than triple it. | 15:14.25 |
| tor8 | yeah. I think it'll be easier to get to work if you filter the entire page bitmap at the end | 15:14.32 |
| | then we can support any and all funky pixel layouts without having an explosion in the plotting functinos | 15:14.56 |
| Robin_Watts | yeah. | 15:15.15 |
| | and of course it all fails when you rotate to landscape mode. | 15:15.43 |
| tor8 | and if your display is high enough resolution that the memory cost of rendering to the triple width is going to hurt, you don't need it :) | 15:15.44 |
| | Robin_Watts: yeah, so then you'd render twice as high and filter the other way | 15:16.10 |
| Robin_Watts | For tablets landscape is "natural", so that's fine; the subpixel antialiasing gives you what you want. | 15:16.42 |
| tor8 | or render rotated, and un-rotate the pixmap to let the device re-rotate it at the end | 15:16.49 |
| Robin_Watts | For phones landscape is wrong, so the subpixels line up the wrong way. | 15:17.04 |
| | (you want the subpixels to give you more in the 'x' direction. Far less useful for latin text the other way. | 15:17.27 |
| tor8 | quite | 15:17.34 |
| [1]Roman | chrisl: Is there any format I can convert the PDF into, which supports transparency, and is embeddable into another PDF/PostScript file? Maybe some vector image format? | 15:19.33 |
| chrisl | [1]Roman: not that I'm aware of, no. | 15:20.36 |
| Robin_Watts | [1]Roman: Is this a 1 off job, or something you want to automate? | 15:20.52 |
| | tor8: oh, gawd. http://en.wikipedia.org/wiki/File:Galaxy_Note_II_subpixels_representation.png | 15:22.08 |
| | We'd need 2d expansion :) | 15:22.14 |
| tor8 | yeah. let's not bother with it! | 15:22.43 |
| [1]Roman | Robin_Watts: Something I want to automate | 15:34.43 |
| Robin_Watts | tor8: OK, so what are we doing now? | 15:41.13 |
| tor8 | Robin_Watts: deciding whether fixing gamma blending for type 3 fonts and soft masks is worth pursuing, or whether we should just drop it and pretend nothing happened | 15:41.51 |
| | and fix the android crash bugs with XPS... | 15:41.59 |
| Robin_Watts | I don't personally like the gamma results, sorry. but that's not to say that they shouldn't be committed somewhere - an ifdef ? | 15:42.07 |
| tor8 | Robin_Watts: I'm in two minds about them. they do make common text look off to my eyes. | 15:42.36 |
| Robin_Watts | I'd like to have a quick experiment with a dogleg alpha table. | 15:42.41 |
| | Let me scribble on some scrap paper for a bit. | 15:43.00 |
| tor8 | feel free to change the color of toolbars to 0xC0,00,00,00 and push | 15:43.51 |
| | I tried dark grey, it didn't look as good | 15:44.21 |
| Robin_Watts | let me do that now before I forget. | 15:45.05 |
| | did you look at the scan converter stuff? | 15:45.13 |
| tor8 | no, sorry, not yet | 15:45.33 |
| | it requires a big mental context switch, I have to page all that code back in :) | 15:46.01 |
| | or ... I could be lazy, approve it, and let Zeniko deal with any issues that crop up ;) | 15:47.12 |
| Robin_Watts | Potted version of changes: | 15:47.40 |
| | 1) Pull the clip region handling out of the loop (so we have 1 loop that skips until we hit the start of the region, and we stop the second loop when we hit the end) | 15:48.15 |
| | 2) Rather than always stepping up 1 subpixel line at a time, step up as many as we can at a time. (For places with non vertical edges, height == 1 so no change). | 15:49.16 |
| | but a LOT of the time, the edges of the regions we are dealing with are vertical (glyphs like n,m,i,j,l, etc) or are actually rectangular. | 15:50.19 |
| | so we can avoid a whole host of repeated work. | 15:50.37 |
| tor8 | Robin_Watts: well, we don't use it for text. but a lot of times it's clip masks for images or table lines or similar | 15:51.03 |
| | so yeah, I can see the benefit | 15:51.08 |
| Robin_Watts | We use it for text done as vectors. | 15:51.47 |
| [1]Roman | chrisl, Robin_Watts: Does gs support PDF->EPS conversion? | 15:51.48 |
| tor8 | Robin_Watts: oh, right! forgot that. and I implemented it not so long ago... | 15:52.11 |
| Robin_Watts | tor8: I actually meant files where the text is part of an illustration, but you're right :) | 15:52.40 |
| chrisl | [1]Roman: sort of. There is an epswrite device, but it is out of date, and at some point to be deprecated | 15:52.46 |
| [1]Roman | chrisl: So my best bet would be PDF->PS->EPS then? | 15:54.40 |
| | chirls: Is that conversion lossy in any other way that the flattening of transparencies? | 15:55.02 |
| tor8 | Robin_Watts: so 'rh' is the number of subscanlines that are the same? | 15:55.05 |
| Robin_Watts | remaining height. | 15:55.12 |
| chrisl | [1]Roman: what are you planning to use for PS->EPS? | 15:55.16 |
| Robin_Watts | height = number of sub scanlines that can be dealt with in the same hit. | 15:55.35 |
| | remaining height = rh = number of subscanlines left in the current scanline. | 15:55.54 |
| | (I should probably add all this as comments) | 15:56.03 |
| | (just in case my terminology is bad here; we collect fz_aa_vscale subscanlines together into a single scanline which we then blit) | 15:56.47 |
| tor8 | Robin_Watts: okay. I understand what the code is trying to do now, and I don't disapprove. | 16:00.03 |
| | apart from the while (h0 > 0); line, where I'd put the ; on a line of its own to be clear | 16:00.29 |
| Robin_Watts | ? | 16:00.38 |
| tor8 | (just pulling your leg there) | 16:00.39 |
| Robin_Watts | :) | 16:00.47 |
| | Your shell sort there really blows my mind. | 16:01.25 |
| tor8 | don't ask me to explain it! | 16:01.47 |
| | ahem. nor the mixed K&R and allman brace styles in it... | 16:02.32 |
| | odd that zeniko hasn't complained about that one yet | 16:02.40 |
| [1]Roman | chrisl: I am looking into gs lib/ps2epsi . Maybe I haven't found it yet, and there's a better util within ghostscript, so ps2ps flag? | 16:02.44 |
| kens | None of the EPS output options are much good | 16:04.56 |
| Robin_Watts | tor8: OK. Magic function... | 16:05.26 |
| tor8 | Robin_Watts: indeed. once upon a time I understood it. I get stupider as I age. | 16:05.49 |
| Robin_Watts | f(x) = 2a.x^3 -3a.x^2 + (1+a).x | 16:05.52 |
| tor8 | mkay? | 16:06.18 |
| chrisl | kens: lib/ps2epsi doesn't seem to do any conversion. | 16:06.20 |
| Robin_Watts | For a = 0, that's f(x) = x | 16:06.26 |
| kens | chrisl it adds a previweq I hrtink | 16:06.35 |
| Robin_Watts | Always f(0) = 0, f(1) = 1, f(0.5) = 0.5 | 16:06.42 |
| chrisl | kens: it does, yes - I meant, it doesn't use (e)pswrite | 16:07.00 |
| kens | Yes, that's correct | 16:07.20 |
| | Its not much use for anything really | 16:07.28 |
| Robin_Watts | tor8: The idea is we can vary a to create a range of lookup tables for edges. | 16:08.06 |
| chrisl | I assume it just does the usual trick of defining the EPS proscribed operators to null ops - and adding the appropriate comments | 16:08.19 |
| kens | I believe so yes | 16:08.29 |
| Robin_Watts | and it'll give equivalent results for black on white and white on black. | 16:08.44 |
| | Assuming I've got the maths right. | 16:08.56 |
| chrisl | kens: I'd say that's a better bet than epswrite! | 16:08.59 |
| kens | well yes, probably true | 16:09.08 |
| | But yuck. PDF->PS->EPS->PDF :-( | 16:09.23 |
| [1]Roman | So I guess I have to find some external PDF-EPS converter, there seems to be some out there | 16:09.57 |
| chrisl | [1]Roman: they will (almost) all work the same as ps2epsi | 16:10.30 |
| [1]Roman | And then what are the PS commands to embedd an EPS in the PS code? | 16:10.33 |
| tor8 | Robin_Watts: right. magic function. not sure how you want to use it to improve AA though. | 16:11.18 |
| chrisl | [1]Roman: you should probably get a copy of the Postscript Language Ref Manual! | 16:11.36 |
| [1]Roman | I knew the RTFM would come some time :) Of course, I'll look there. | 16:12.35 |
| chrisl | [1]Roman: you can actually just "dump" the entire EPS into the PS at the appropriate place. You need to setup the current tranformation matrix and the clip path first. | 16:14.08 |
| kens | I suspect that for all practical purposes you can treat a single output page opf ps2write as an EPS file | 16:29.54 |
| | with the usual technique of redefining showpaghe to a null op and so on | 16:30.32 |
| Robin_Watts | tor8; OK, I've tweaked fz_copy_ft_bitmap to map the returned pixmap from freetype through the gamma table. | 16:45.31 |
| | (not gamma table, magic function) | 16:45.42 |
| | Results are crap for a = -1. | 16:45.57 |
| | And I still prefer the original with a=1 | 16:50.02 |
| | tor8: So, what was the verdict with the scan converter? Would you prefer a version with more comments? | 16:50.27 |
| tor8 | Robin_Watts: a few more comments wouldn't hurt, but I guessed correctly without too much guidance :) | 16:50.53 |
| Robin_Watts | I have a more commented version here. | 16:51.08 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=9bf73f2cd88abd305ebac405411cc3f260ff9da9 | 16:53.23 |
| | Morning mvrhel_laptop, ray_laptop. I hope you both had good thanksgivings. | 17:00.59 |
| mvrhel_laptop | Good morning Robin_Watts | 17:01.10 |
| Robin_Watts | Henrys is away today - he said todays meeting was optional. | 17:01.15 |
| mvrhel_laptop | ok. | 17:01.26 |
| kens | forgot that :-( | 17:01.53 |
| ray_laptop | Robin_Watts: thanks. It was a good family time | 17:02.10 |
| alexcher | Sumatra PDF files have many broken files that look like regressions in the log. | 17:03.33 |
| Robin_Watts | alexcher: Yes. It seems odd that in every ghostpdl run we get 'The following 350 files have started producing errors" | 17:04.49 |
| tor8 | Robin_Watts: LGTM. | 17:05.05 |
| Robin_Watts | tor8: Thanks. | 17:05.10 |
| chrisl | Robin_Watts: I've been getting that "The following.... have started producing errors" with PCL/PXL files for weeks, maybe months now | 17:05.48 |
| Robin_Watts | So maybe the cluster code has a problem... marcosw? | 17:06.09 |
| marcosw | Robin_Watts: the cluster code has a problem?!?! Doesn't seem likely. | 17:06.38 |
| chrisl | I guess so, I was going to ask marcosw about it at the staff meeting | 17:06.49 |
| Robin_Watts | marcosw: http://ghostscript.com/cgi-bin/clustermonitor.cgi?report=f27a0b8a47f0faadb6797132d6b9ef00a1823529&project=ghostpdl | 17:07.19 |
| alexcher | 2 files need passwords, 2 files are not PDF files and should be excluded from the run, some are real bugs, some files are broken beyond repair. | 17:07.34 |
| Robin_Watts | alexcher: We could just not include that directory in the ghostpdl runs. | 17:08.03 |
| marcosw | alexcher: you are referring to the newly added sumatra files? I was going to bring that up at the meeting... | 17:08.15 |
| alexcher | yes | 17:08.23 |
| Robin_Watts | but that wouldn't address chrisls point. | 17:08.27 |
| alexcher | Robin_Watts: At least a few files have demonstrated real problems in gs. | 17:09.27 |
| Robin_Watts | We get massive flack from zeniko if we break those files, so it's really good for us to have mupdf being tested on them. | 17:10.01 |
| | alexcher: But if we could stop the cluster reporting them as being new regressions each time, we wouldn't care about gs running on them, would we? | 17:10.34 |
| marcosw | the sumatra errors should not appear again, since they presumably will continue to fail and the cluster only reports changes. They appeared in the commit that Robin_Watts listed since that was the first cluster run after the sumatra files were added. | 17:11.02 |
| Robin_Watts | marcosw: Really? | 17:11.26 |
| | That commit was this morning. | 17:11.35 |
| | Surely there have been other commits since they were added. | 17:11.48 |
| chrisl | marcosw: but the problem is that the cluster seems to have been losing its record of existing errors. | 17:11.52 |
| marcosw | Robin_Watts: yup, the first ghostscript commit in a week. | 17:12.02 |
| Robin_Watts | well, you're all slackers then! :) | 17:12.23 |
| chrisl | So I've been getting a bunch of "started producing error" listings from PCL/PXL files that have always (and are supposed to) exit with an error | 17:12.53 |
| marcosw | Robin_Watts: those of us in the us have a partial excuse, we had a couple of days off last week :-) | 17:13.02 |
| | chrisl: can you give me an example of that? I'm not saying it's not happening, but the sumatra files are not a problem. | 17:13.24 |
| chrisl | marcosw: I did a clusterpush on Friday 16th that shows the problem - I can forward you the report mail, if that would help | 17:15.05 |
| marcosw | is it possible that there are pcl files that produce indeterministic errors? that would exhibit the symptoms that chrisl is seeing. | 17:15.18 |
| chrisl | Well, I ran them with various code vintages back to the 9.06 release, and they all exited with the same errors, so..... | 17:16.15 |
| marcosw | chrisl: I have it. Is the section you are referring to: "The following 286 regression file(s) have started producing errors"? | 17:16.15 |
| chrisl | Yes | 17:16.26 |
| | marcosw: I had ignored it because I was noticing it switching between my FAPI dev branch and master - I assumed it was related to that, but it seems not | 17:20.06 |
| marcosw | the previous clusterpush you ran used the lowres option, I wonder if that's the problemâ¦all the 286 "new" errors are at 600 dpi and so won't have been tested in the previous clusterpush run. | 17:20.23 |
| | notice that the second clustepush you can on the 16th produced reasonable results for new errors since the last clustepush. | 17:20.56 |
| | (i.e. no new errors). | 17:21.22 |
| chrisl | Yes, I ran several trying to find a "stable" state from which to actually test my changes | 17:22.21 |
| marcosw | I'm entering a bug to fix this (assuming my initial diagnoses is correct it should be easy to fix). | 17:22.36 |
| chrisl | marcosw: what I was going to ask you at the staff meeting was: should we have an explicit list of files we expect to error out (like the PXL ones)? | 17:23.53 |
| marcosw | chrisl: I think that's a good idea, we could add a list of such files to each repository directory (or a master list at the top the repository). | 17:24.55 |
| alexcher | marcosw: please enable alex_x6 again. I had old versions of the scripths running, and this is now fixed. | 17:25.08 |
| chrisl | marcosw: of course, it's down to you to implement it in the cluster code - I'm not going near that house of cards!! ;-) | 17:25.54 |
| marcosw | alexcher: done | 17:26.05 |
| Robin_Watts | alexcher: Last time it was stuck on 'updating files'... | 17:26.17 |
| marcosw | chrisl: of course. house of cards is being kind, house of loo paper is more accurate. | 17:26.41 |
| | (assuming loo paper is the word I'm looking for0. | 17:26.52 |
| ray_laptop | mvrhel_laptop: why does the gs_imager_state have devicergb_cs and devicecmyk_cs and not devicegray_cs (gx_concrete_space_CIE looks wrong for CIEA CIEBased) | 17:26.56 |
| Robin_Watts | gaffer tape and pipecleaners. | 17:26.59 |
| ray_laptop | Robin_Watts: is gaffer tape what you folks call duct tape ? | 17:27.43 |
| Robin_Watts | yeah. | 17:27.49 |
| marcosw | Robin_Watts: in my day we should have been lucky to have had gaffer tape and pipe cleaners, we lived in the middle of a lake... | 17:28.15 |
| mvrhel_laptop | ray_laptop: hmm. not sure what or where you are talking let me look | 17:28.18 |
| chrisl | Robin_Watts: gaffer tape is the strongest, most flexible material known to man - I'm not sure that's a good analogy for perl! | 17:29.01 |
| ray_laptop | mvrhel_laptop: I wanted a colorspace and was looking to use one and not have to create it (and destroy it) | 17:29.27 |
| Robin_Watts | chrisl: Gaffer tape works really well when you pull it off the roll and stick it on. Now go back and try and adjust it without starting again from scratch... | 17:29.38 |
| mvrhel_laptop | ray_laptop: interesting. I am not sure even if those are still used... | 17:29.48 |
| ray_laptop | chrisl: right, and like perl it easily gets all balled up | 17:29.54 |
| Robin_Watts | I think that's a perfect analogy for perl :) | 17:29.57 |
| mvrhel_laptop | only in gx_concrete_space_CIE | 17:30.15 |
| | and we handle the CIE spaces differently now | 17:30.29 |
| chrisl | ray_laptop, Robin_Watts: Okay, I'm convinced....... | 17:30.33 |
| ray_laptop | mvrhel_laptop: right, and that is wrong for CIEA correct ? | 17:30.44 |
| mvrhel_laptop | well the whole thing may be wrong | 17:30.56 |
| | let me look at CIEA | 17:31.00 |
| | oh | 17:31.21 |
| ray_laptop | mvrhel_laptop: or is this whole section just a vestige | 17:31.22 |
| mvrhel_laptop | I see | 17:31.22 |
| | yes | 17:31.24 |
| | ray_laptop: That is my feeling is that all of this could go away | 17:31.41 |
| | and certainly if if was something that should work CIEA case is wrong | 17:31.50 |
| | s/if if/if it/ | 17:32.04 |
| ray_laptop | mvrhel_laptop: OK. I was just looking around for a convenient devicegray_cs. | 17:32.37 |
| mvrhel_laptop | gs_cspace_new_DeviceGray(gs_memory_t *mem) | 17:32.53 |
| | ray_laptop: I will see if I can clean this stuff up | 17:33.24 |
| ray_laptop | mvrhel_laptop: yeah, and then I have to get rid of it at the right time (rc_decrement) | 17:33.25 |
| | mvrhel_laptop: I guess I'll just do it that way. | 17:33.48 |
| mvrhel_laptop | ray_laptop: how are you using the color space? | 17:33.54 |
| ray_laptop | I need it for an image (gs_image_t_init_adjust call) | 17:34.42 |
| | so I can rc_decrement that colorspace when I finish the image. Just thought I could be lazy :-) | 17:35.21 |
| mvrhel_laptop | right | 17:35.31 |
| Robin_Watts | tor8: Aha. The remaining slow document is calling fz_std_conv_pixmap and hammering the memoization case. | 17:35.59 |
| marcosw | the just completed cluster run correctly did not report any of the sumatra files that produce errors. the only issues with the sumatra files are some seg faults, for which I'll enter bugs. | 17:36.03 |
| mvrhel_laptop | ray_laptop: I am going to add a bug for me to clean this stuff up so I don't forget about it | 17:36.23 |
| ray_laptop | mvrhel_laptop: OK. thanks for the info. | 17:37.08 |
| alexcher | marcosw: 2 PDF files need passwords to run. The script should be extended to pick the passwords from disk or have them hardcoded in the script. | 17:39.05 |
| marcosw | alexcher: either of those options is messy. I'll add a bug to allow me time to think about it... | 17:39.49 |
| Robin_Watts | file.pdf and file.pdf.password ? | 17:40.12 |
| | OR rename the file to be file..PASSWORD..pdf ? | 17:40.46 |
| | Hmm. That would be a problem for passwords with non-latin chars. | 17:41.37 |
| marcosw | yeah, I think we need to store them in a file. | 17:41.58 |
| Robin_Watts | You can know that you need a password on the server, because you can spot the existence of a jobname.password file. | 17:42.26 |
| marcosw | and presumably use `cat file.pdf.password` to pass them to gs or mudraw. | 17:42.27 |
| Robin_Watts | yeah. | 17:42.37 |
| marcosw | Robin_Watts: yes, the change needs to happen in build.pl. | 17:43.04 |
| | the problem is with bmpcmp :-) | 17:43.17 |
| | though that might not be too complicated. | 17:43.35 |
| | as I said, I need to think about it. | 17:43.41 |
| Robin_Watts | why bmpcmp ? | 17:44.10 |
| | bmpcmp cares not for such menial things as passwords. | 17:44.29 |
| marcosw | clusterpush.pl bmpcmp has to process the file (twice!). | 17:44.53 |
| | while I'm at it I should fix http://bugs.ghostscript.com/show_bug.cgi?id=689423 | 17:45.03 |
| | though dog only knows how I can do that. | 17:45.19 |
| | without much gaffer tape, that is. | 17:45.39 |
| chrisl | marcosw: I'd have thought the DroidSansFallback substitution would be good enough for that, isn't it? | 17:47.04 |
| mvrhel_laptop | Robin_Watts: so is there anything that I can do now to get the nexus 10 ready? | 17:47.53 |
| | or do you want to go over it all tomorrow? | 17:48.05 |
| Robin_Watts | mvrhel_laptop: Install a filemanager | 17:48.06 |
| | ASTRO or ES File Manager | 17:48.14 |
| mvrhel_laptop | is one better than the other? | 17:48.27 |
| marcosw | chrisl: that would be fine with me, and it's not like the person who entered the bug will complain :-( | 17:48.32 |
| Robin_Watts | mvrhel_laptop: Not as far as I know. | 17:48.36 |
| | I have ES File Explorer on my phone. | 17:48.52 |
| mvrhel_laptop | ok. let me do that now | 17:48.56 |
| marcosw | so I guess the bug degenerates into "add some test files that request non-embedded CID fonts" | 17:49.01 |
| Robin_Watts | so presumably I picked that for a reason :) | 17:49.02 |
| chrisl | marcosw: well, he didn't even list "useful files" that are missing, so....... | 17:49.14 |
| mvrhel_laptop | the voice search on this thing is nice | 17:49.27 |
| marcosw | chrisl: not entirely correct, he suggested the file from bug 687970 as a useful test file. | 17:50.11 |
| chrisl | Well, my reading of the report was that there were several - but anyway, having the fallback isn't ideal, but does exercise a lot of the CIDFont stuff, and saves any worries about copyrighted materials etc | 17:52.22 |
| mvrhel_laptop | Robin_Watts: ok installed | 17:52.27 |
| | well going ahead with a system update now... | 17:54.06 |
| marcosw_ | sorry, ran out of free-wifi at Peet's; had to get another code | 17:54.48 |
| mvrhel_laptop | so the nexus 10 is way nicer than microsofts surface. not sure how it compares to the new ipad | 17:54.55 |
| Robin_Watts | mvrhel_laptop: Well, you could install the apk from: http://mupdf.com/forms as a test | 17:55.46 |
| | we'll get you an updated build tomorrow. | 17:55.56 |
| | and probably thursday. and friday etc :) | 17:56.06 |
| marcosw | alexcher: alex_x6 appears to be still stuck "Updating test files" | 17:56.12 |
| Robin_Watts | yup. That's what happened before. | 17:56.38 |
| alexcher | marcosw: Can you help me to debug it? | 17:57.07 |
| marcosw | sure. give me a sec to find the command you'll want to execute in a shell. | 17:57.34 |
| | in bash: | 17:58.54 |
| | export SVN_SSH="ssh -q -i $HOME/.ssh/cluster_key" | 17:59.00 |
| | cd cluster/tests_private | 17:59.04 |
| | svn cleanup | 17:59.07 |
| | svn update | 17:59.12 |
| | (modifying the directories as appropriate for your installation). | 17:59.29 |
| mvrhel_laptop | who is doing code.google.com/p/mupdf-android? | 17:59.37 |
| | The text description there has a few issues | 18:00.19 |
| | looks like something I would have typed on IRC | 18:00.26 |
| ray_laptop | mvrhel_laptop: I presume it is Lianwei Wang (the owner of mupdf-android). Oh they joys of having "helpers" from the open source community | 18:03.22 |
| mvrhel_laptop | :) | 18:03.52 |
| alexcher | marcosw: the script works. "At revision 3341." What user should run the script? | 18:04.34 |
| ray_laptop | mvrhel_laptop: he works at "Motorola Mobility" according to his g+ site at: https://plus.google.com/107333669786433984298/posts | 18:04.43 |
| marcosw | the same one that runs the clusterpull.sh script via cron. | 18:04.56 |
| mvrhel_laptop | ray_laptop: which is owned by google correct? | 18:05.12 |
| | by the way, the native pdf viewer on the nexus has some neat features | 18:05.32 |
| | one is that it has the option to render all the text white, and do black black ground fills | 18:05.56 |
| | black back ground | 18:06.03 |
| ray_laptop | mvrhel_laptop: I have no idea what "Motorola Mobility" is (haven't googled it). Someone (tor, Robin_Watts ?) should let him know that this is already happening | 18:06.14 |
| Robin_Watts | ray_laptop: He hasn't touched the project since sometime in 2011. | 18:06.43 |
| ray_laptop | mvrhel_laptop: why is white text on black better ??? | 18:06.44 |
| mvrhel_laptop | also it does text extraction and a reflow | 18:06.48 |
| | ray_laptop: reading at night | 18:06.55 |
| | it is easier on the eyes | 18:07.08 |
| | to me | 18:07.12 |
| Robin_Watts | mvrhel_laptop: You mean, like pressing 'i' in mupdf does? :) | 18:07.19 |
| marcosw | alexcher: is run.pl in the cluster directory up-to-date? The clusterpull.sh script should fetch a new copy from casper on every cluster run but as I recall there isn't any error checking on that step, so it would silently fail. Using an old run.pl would cause many other issues, so this isn't likely an issue. | 18:07.21 |
| mvrhel_laptop | how do I press i on the viewer app? | 18:07.34 |
| ray_laptop | mvrhel_laptop: reflow is nice. text extraction on phones/tablets a bit less so, but I guess if you can 'cut' and 'paste' it's handy | 18:07.38 |
| Robin_Watts | not on android, alas :) | 18:07.41 |
| mvrhel_laptop | Robin_Watts: :) | 18:07.49 |
| | Robin_Watts: what are some good forms to have on here? | 18:09.08 |
| alexcher | marcosw: it's up-to-date. | 18:10.28 |
| Robin_Watts | just looking/// | 18:11.07 |
| marcosw | can you look at the log file alex_x6 and see if there are any obvious errors near the end? it's called alex_x6.dbg | 18:11.26 |
| Robin_Watts | mvrhel_laptop: http://intranet.glidos.net/~paul/pdf-forms.zip | 18:12.25 |
| mvrhel_laptop | Robin_Watts: so comparing the native viewer and ours, I have to say that theirs seems a little faster when rescaling. They use a very low res scaled image during the active part of scaling and then it snaps quickly to the rendered output | 18:12.42 |
| Robin_Watts | mvrhel_laptop: Wait for tomorrows version. | 18:13.00 |
| mvrhel_laptop | mupdf seems to use the existing rendered output and then eventually renders | 18:13.11 |
| | Robin_Watts: ok | 18:13.14 |
| | this is a debug version to I think | 18:13.21 |
| | the one I downloaded | 18:13.27 |
| Robin_Watts | it's a release build in the native code. | 18:13.42 |
| | but signed as a debug one. | 18:13.50 |
| alexcher | Tue Nov 27 12:51:06 EST 2012: error with: cd /home/alexcher/cluster/tests_private/ ; export SVN_SSH="ssh -q -i $HOME/.ssh/cluster_key" ; svn cleanup ; svn update; a=1 count=0 | 18:14.43 |
| marcosw | alexcher: would be more helpful if the error message was in the log file :-) | 18:17.34 |
| | and these are the same commands you executed successfully via the command line⦠| 18:19.31 |
| | I'm going to re-enable alex_x6 for another test while logging ssh connections attempts on casper. | 18:21.32 |
| alexcher | marcosw: how can I check under what user the script runs. | 18:22.48 |
| marcosw | it will be whatever use has it in their cron file. other than su'ing to each user and running "crontab -l" I don't know | 18:24.07 |
| | unfortunatley the ssh connection logging only reports what ip address connects, so I can't differentiate between the connection attempts from your various cluster nodes. But in any case there aren't any errors in the logs. | 18:25.59 |
| | alexcher: I have to run. I'll add code to run.pl to log the error that the svn update command returns; that should give us the answer. I'll email when I've done that | 18:27.07 |
| alexcher | marcosw: what will happen if I just run clusterpul.sh ? | 18:27.27 |
| mvrhel_laptop | Robin_Watts: so when I open a new file from the file explorer, it does not render page 1 but shows the old file that I had opened | 18:28.47 |
| | not sure if this is a known isssue | 18:28.56 |
| | actually, it maintains the old pages | 18:29.19 |
| | they are never even rendered | 18:29.36 |
| Robin_Watts | eh? | 18:30.34 |
| mvrhel_laptop | Robin_Watts: so I was viewing a document with 10 pages | 18:31.01 |
| | then I selected a pdf file from the file explorere | 18:31.20 |
| | the system asks if I want to open with mupdf or the native viewr | 18:31.32 |
| | I chose mupdf | 18:31.41 |
| | the new document had 2 pages | 18:31.47 |
| | but all I see is page 1 and page 2 of my old document now | 18:31.57 |
| Robin_Watts | boggle. | 18:32.13 |
| | How did you get from mupdf to the file explorer? | 18:32.23 |
| mvrhel_laptop | no | 18:32.35 |
| | I am in the file explorer | 18:32.45 |
| | and tap a pdf file | 18:32.51 |
| | to open it | 18:32.54 |
| Robin_Watts | Right, and that's 10 pages. | 18:32.59 |
| mvrhel_laptop | no | 18:33.04 |
| Robin_Watts | How do you get back to the file explorer to open the next one with 2 pages ? | 18:33.15 |
| mvrhel_laptop | let me start over | 18:33.18 |
| Robin_Watts | Right. | 18:33.23 |
| mvrhel_laptop | I run mupdf | 18:33.25 |
| | it shows a file that I had downloaded | 18:33.36 |
| | I open it | 18:33.40 |
| | it has 10 pages | 18:33.47 |
| | and renders fine | 18:33.50 |
| Robin_Watts | OK, so you're mixing the launch methods, that may be why. | 18:33.53 |
| mvrhel_laptop | now I leave mupdf | 18:34.10 |
| Robin_Watts | (Clearly this should not be happening, I'm just trying to understand why it is). | 18:34.11 |
| | HOW do you leave mupdf? | 18:34.18 |
| mvrhel_laptop | uh by going to the tile viewer | 18:34.31 |
| | or another app | 18:34.35 |
| Robin_Watts | Ok. So you hit the 'home' button. | 18:34.45 |
| mvrhel_laptop | yes | 18:34.50 |
| | the same as one leaves any application | 18:34.57 |
| Robin_Watts | That leaves mupdf running in the background. | 18:35.00 |
| mvrhel_laptop | yes | 18:35.03 |
| | this is the same for any application | 18:35.09 |
| | on any tablet | 18:35.13 |
| Robin_Watts | If you hit the 'back' button, you'll go back from the mupdf view to the list of files. | 18:35.20 |
| | Then 'back' from there exits mupdf. | 18:35.31 |
| mvrhel_laptop | regardless | 18:35.32 |
| | if I go to the file explorer and click a pdf file | 18:35.50 |
| Robin_Watts | I'm wondering if the same thing happens if you've exited mupdf before starting a file from the file explorer. | 18:36.02 |
| mvrhel_laptop | and the system asks me if I want to view it in mupdf | 18:36.03 |
| | and I select it to do so | 18:36.12 |
| | it does not render the pages | 18:36.20 |
| Robin_Watts | I follow what you are doing, and agree that it is wrong. | 18:36.24 |
| mvrhel_laptop | ok | 18:36.29 |
| | what I am doing is not wrong | 18:36.41 |
| | the behavior of mupdf is wrong. | 18:36.53 |
| Robin_Watts | I follow what you are doing, and agree that what you are doing is not wrong. The behaviour of mupdf is wrong. | 18:37.03 |
| mvrhel_laptop | :) | 18:37.08 |
| Robin_Watts | Now, I'd like you to try something please... | 18:37.29 |
| | Run mupdf. Select the file that you have downloaded. | 18:37.41 |
| mvrhel_laptop | let me try ending the application and opening from the explorer | 18:37.42 |
| Robin_Watts | Leave mupdf by hitting back twice. Then start a file from the explorer. | 18:37.57 |
| mvrhel_laptop | that correctly rendered | 18:39.17 |
| Robin_Watts | ok, so at least we have a workaround. | 18:41.26 |
| | If you always start files from the explorer, you're fine. | 18:41.38 |
| | Now, I'll try and reproduce it here and see about fixing it. | 18:41.50 |
| mvrhel_laptop | Robin_Watts: before I forget. Should the fill in boxes in the file 2009_handbook_19_11_08_application_form.pdf work? | 18:44.58 |
| | I guess I should just try on my laptop here | 18:45.12 |
| | Robin_Watts: yes, starting from the explorer always seems to be fine | 18:45.27 |
| Robin_Watts | mvrhel_laptop: Checking with acrobat is what I'd do :) | 18:45.44 |
| mvrhel_laptop | yes | 18:45.51 |
| | checking now | 18:45.53 |
| Robin_Watts | fab. So I'll try and figure out what's going wrong. thanks. | 18:45.58 |
| mvrhel_laptop | ok. I hope you don't mind me beating on it a bit | 18:46.21 |
| Robin_Watts | mvrhel_laptop: Not at all! | 18:48.04 |
| | Everyone falls into a pattern of use with a piece of software, so the more people using it in different ways will reveal more bugs. | 18:48.32 |
| mvrhel_laptop | ok apparently they work it is just really really really slooooww.... | 18:48.46 |
| | acrobat is fine | 18:48.51 |
| | oh and then with rescale the check box entries disappeared :( | 18:50.52 |
| | oh but then they came back | 18:51.01 |
| Robin_Watts | When you rescale, we use a cached image. | 18:51.17 |
| | That cached image takes a while to regenerate. | 18:51.23 |
| mvrhel_laptop | ok | 18:51.30 |
| | there is def. something wrong with this file though | 18:51.48 |
| | Scott would go crazy | 18:52.20 |
| Robin_Watts | OK. Move that one quietly into another directory :) | 18:52.43 |
| mvrhel_laptop | yes. how come though the text form entries dont disappear on rescale but the check data does? | 18:53.29 |
| | hmmm | 18:53.50 |
| | actually with another file it does not dissapear | 18:54.00 |
| Robin_Watts | I suspect that that file is slow to render for some reason. | 18:54.13 |
| mvrhel_laptop | there is something about 2009_handbook_19_11_08_application_form.pdf | 18:54.13 |
| | ok. need to head out for a bit | 18:56.12 |
| Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=deac1b9b44977b9e8db758d01867bf8a3ca922ce | 18:57.47 |
| | mvrhel_laptop: http://ghostscript.com/~robin/MuPDF-debug.apk <- Faster more spiffy version. | 19:42.15 |
| marcosw | alexcher: the output of the svn commands updating the test files is now captured in the alex_x6.dbg file. Could you take a look and see if there are errors? | 20:21.07 |
| alexcher | svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. | 20:38.26 |
| | svn: Network connection closed unexpectedly | 20:38.27 |
| Robin_Watts | alexcher: Maybe the servers cached key is stale. | 20:40.07 |
| marcosw | Robin_Watts: good idea, but when alexcher ran the commands the cluster software is using from the command line the connection worked. | 20:43.43 |
| Robin_Watts | marcosw: Wrong user. | 20:43.52 |
| | ? | 20:43.54 |
| | ssh caches server keys per user, right? | 20:44.05 |
| marcosw | ssh does cache by user, but I thought we addressed the user issue already. | 20:45.00 |
| | alexcher: I'm running another test, without the -q option, per the error message recommendation :-) | 20:45.59 |
| alexcher | This works from the command line: ssh -i $HOME/.ssh/cluster_key casper.ghostscript.com | 20:46.18 |
| marcosw | alexcher: can you look at alex_x6.dbg and see if removing -q made the error more informative. | 20:48.44 |
| alexcher | Permission denied (publickey). | 20:51.21 |
| marcosw | which is the message you would be getting if the cluster_key file wasn't being used. but what would cause that to happen? | 20:56.44 |
| | it is stored in $HOME/.ssh/cluster_key, correct? | 20:57.14 |
| Robin_Watts | If $HOME wasn't defined... or .ssh wasn't readable... | 20:57.16 |
| | or the permissions on the key are too lax... | 20:57.38 |
| marcosw | Robin_Watts: all good ideas, but I just tried and there are different error messages for all of those cases (e.g. "Identity file ... not accessible: No such file or directory."). | 20:59.48 |
| alexcher | On the command ssh works without the -i option picking the default key. | 21:00.22 |
| marcosw | that brings up a good point: "ssh -i $HOME/.ssh/cluster_key casper.ghostscript.com", shouldn't work (and doesn't for me). | 21:01.34 |
| Robin_Watts | The command line has ssh-agent running in the background providing the key ? | 21:02.01 |
| marcosw | that's what I'm thinking... | 21:02.22 |
| alexcher | How can I check this? | 21:03.12 |
| marcosw | stick a couple of -v options on the ssh command you are running from the command line. | 21:04.18 |
| Robin_Watts | mvrhel_laptop: http://ghostscript.com/~robin/MuPDF-debug.apk <- Faster more spiffy version. | 21:07.54 |
| | I know what's wrong with the launching thing I think. | 21:08.04 |
| mvrhel_laptop | ok great | 21:08.10 |
| | chatting with scott now | 21:08.14 |
| Robin_Watts | It's a tedious but hopefully straightforward fix that I'll finish tomorrow. | 21:08.28 |
| marcosw | alexcher and Robin_Watts: the more I look into the problem with alex_x6 the more confused I become. The cluster_key has to be good, otherwise the cluster run wouldn't begin (the clusterpull.sh script uses the key when checking to see if there is a cluster job pending, among other things). | 21:14.22 |
| | I'm going to temporarily disable i7a and i7b, since all of the log messages are by ip address and so they are confusing things. | 21:15.19 |
| alexcher | marcosw: With -i option my key is still offered to the server, apparently under a different protocol. | 21:15.52 |
| marcosw | let's try to temporarily get rid of the other keys. | 21:18.09 |
| | cd $HOME | 21:18.14 |
| | mv .ssh .ssh.tmp | 21:18.17 |
| | mkdir .ssh | 21:18.20 |
| | chmod 700 .ssh | 21:18.27 |
| | cp -p .ssh.tmp/cluster_key .ssh/. | 21:18.34 |
| | and then try | 21:18.38 |
| | ssh -i .ssh/cluster_key regression@casper.ghostscript.com touch /home/regression/cluster/alex_x6.up | 21:19.29 |
| | you will get a message asking you to confirm that you want to connect, but that's because the .ssh/known_hosts files is now empty | 21:21.37 |
| alexcher | This works. | 21:22.08 |
| marcosw | can you try "ssh -i $HOME/.ssh/cluster_key casper.ghostscript.com" that should fail. | 21:22.38 |
| alexcher | It fails | 21:23.10 |
| marcosw | just to be thorough let's try: ssh -i $HOME/.ssh/cluster_key regression@casper.ghostscript.com | 21:23.38 |
| alexcher | You are not allowed to run '' | 21:24.17 |
| marcosw | what I was expecting. | 21:24.33 |
| | okay, now let's check the svn commands | 21:24.42 |
| | cd cluster/tests_private | 21:24.50 |
| | try: svn update (which should fail). | 21:25.19 |
| alexcher | it fails | 21:26.07 |
| marcosw | using the bash shell: | 21:26.18 |
| | export SVN_SSH="ssh -i $HOME/.ssh/cluster_key" | 21:26.23 |
| | and "svn update" | 21:26.30 |
| alexcher | svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. | 21:26.38 |
| | svn: Network connection closed unexpectedly | 21:26.39 |
| marcosw | right. | 21:26.58 |
| | i think I've figured it out, give me a sec... | 21:27.28 |
| | in the tests_private directory: grep ghostscript .svn/entries | 21:29.09 |
| alexcher | svn+ssh://svn.ghostscript.com/var/lib/svn-private/ghostpcl/trunk/tests_private | 21:31.26 |
| | svn+ssh://svn.ghostscript.com/var/lib/svn-private/ghostpcl | 21:31.28 |
| marcosw | and that's the problem. Mine are: | 21:31.43 |
| | svn+ssh://regression@svn.ghostscript.com/var/lib/svn-private/ghostpcl/trunk/tests_private | 21:31.44 |
| | svn+ssh://regression@svn.ghostscript.com/var/lib/svn-private/ghostpcl | 21:31.44 |
| | so Robin_Watts was right, the wrong user was being used to update the tests_private svn repository. I forgot that the user is part of the repository URL. | 21:32.29 |
| | unfortunately all of the entries files will have the same problem. the fastest way to fix this is to rsync over a tests_private from i7a://home/marcos/cluster, using the -c option so that the date/time of the files won't be used to decide if they need to be transferred. | 21:34.26 |
| | the easiest is to rm -fr tests_private and fetch another copy using this command: | 21:35.02 |
| | svn co svn+ssh://regression@svn.ghostscript.com/var/lib/svn-private/ghostpcl/trunk/tests_private | 21:35.04 |
| | after: export SVN_SSH="ssh -i $HOME/.ssh/cluster_key" | 21:35.42 |
| | okay. I'm going to re-enable i7a and i7b, don't forget to move .ssh.tmp back to .ssh | 21:36.45 |
| alexcher | done | 21:37.04 |
| marcosw | alex_x6 still thinks it's running a cluster job, remove $HOME/cluster/run.pid and $HOME/cluster/clusterpull.lock | 21:39.25 |
| alexcher | I took the easy way. it will take a while. | 21:40.25 |
| marcosw | that will take a while :-) talk with you later. | 21:41.41 |
| | Forward 1 day (to 2012/11/28)>>> | |
IRC Logs
