| | <<<Back 1 day (to 2016/06/06) | 20160607 |
| tor8 | nono_ (for the logs): Sounds like you may be running the ndk for 64-bit targets when compiling for a 32-bit target. It's got bugs that sound similar to what you're seeing. | 08:31.43 |
| remi__ | hi since this morning i can't compile mupdf for android. i have this error No rule to make target `jni/../../../../source/pdf/js/pdf-js.c', needed by `obj/local/arm64-v8a/objs/mupdfcore/__/__/__/__/source/pdf/js/pdf-js.o' | 08:44.48 |
| tor8 | remi__: just delete the two lines in platform/android/viewer/jni/Core.mk that reference pdf-js.c | 08:45.44 |
| remi__ | ok thank you | 08:46.33 |
| kens | RROR | 08:52.24 |
| tor8 | kens: red ring of revenge? | 08:53.19 |
| kens | No sorry. The window came to the front and grabbed the keyboard focus when it reconnected. That was the tail end of -dPDFSTOPONERROR | 08:54.00 |
| tor8 | kens: aha! that is really annoying when it happens... | 08:54.30 |
| kens | Annoying two ways, because then GS didn't do what I expected either :-( | 08:54.48 |
| | I hate it when I take debug printing statements out of PostScript because it is all working, and it immediately stops working..... | 08:56.20 |
| | Bad day Robin ? | 11:07.11 |
| Robin_Watts | my broadband seems to think so. | 11:10.21 |
| | well, it's not my broadband, it's my freenode connection. | 11:10.34 |
| | Can I port MuPDF to one of these... https://sciencescope.uk/product/bbc-microbit/ | 11:18.52 |
| kens | Can't see why not | 11:19.20 |
| Robin_Watts | kens: Limited output opportunities :) | 11:19.37 |
| kens | Do they have a C compiler for it ? | 11:19.39 |
| Robin_Watts | That's what I was wondering... | 11:19.46 |
| kens | anyway, output isn't all that MuPDF can do | 11:20.59 |
| Robin_Watts | 16k ram,256k flash :) | 11:24.16 |
| kens | kind of limiting | 11:24.28 |
| Robin_Watts | tor8: 2 commits on robin/master, if you get a mo, please. | 11:25.47 |
| tor8 | Robin_Watts: I can't say I understand the subarea image calculations, but I'll let it go with an LGTM | 11:32.03 |
| | Robin_Watts: a handful of commits on tor/master as well | 11:32.14 |
| Robin_Watts | tor8: Ta. | 11:40.46 |
| sebras | Robin_Watts: may I interest you in a review of the commit on sebras/luratech-jbig2? | 11:43.07 |
| | Robin_Watts: I reclustered on top of master just now and it looks fine apart from the jbig2 images that luratech itself has issues with (reported and assigned to henrys). | 11:44.11 |
| tor8 | sebras: Makefile has a typo, LURATACH_LIBS (though that variable is never set to anything useful) | 11:50.30 |
| | sebras: a comment to the second endif to note that it belongs to LURATECH might be helpful | 11:51.07 |
| sebras | tor8: easily fixable. I'll also rewrite the commit message of course. | 11:52.15 |
| | tor8: btw, there is another difference and that is that if there is an error jbig2dec leaves a white box whereas luratech leaves a black box on the page. | 11:54.07 |
| | not sure why. | 11:54.10 |
| tor8 | sebras: you're not forgetting to 'invert' the bits on errors in one of the two? | 11:54.45 |
| | sebras: i.e. BlackIs1 | 11:55.12 |
| sebras | tor8: I don't think do. then it would look weird even for normal jbig2 images, right? | 11:55.28 |
| tor8 | sebras: I mean in the case when you catch the exception | 11:55.40 |
| | or error | 11:55.42 |
| | that you might be missing that inversion in the catch handler | 11:56.01 |
| | otherwise it might just be the libraries handling errors in images differently | 11:56.45 |
| Robin_Watts | tor8: I'd be tempted to just make fz_new_draw_device always take an fz_draw_options pointer, and have NULL mean 'default'. | 11:57.55 |
| | Also, I'd make fz_parse_draw_options always return the same fz_draw_options * as you pass it. | 11:58.18 |
| | That way you can do: dev = fz_new_draw_device(ctx, fz_parse_draw_options(ctx, &opts, string), ....); | 11:58.47 |
| sebras | tor8: well the filter does decode to a buffer and then invert before putting it in the fitlers output buffer in next(). but in the error case that buffer is never touched. | 12:00.12 |
| Robin_Watts | MuDraw has some cleverer w/h/res handling. | 12:00.13 |
| tor8 | Robin_Watts: one thing that would be nice would be if we can stash the transform somewhere in the draw device, so we don't need to pass it back and forth with out parameters | 12:00.25 |
| Robin_Watts | In that you can specify a max w/h, and how to fix it. | 12:00.38 |
| sebras | tor8: seems counter intuitive to actually write the buffer and not being able to pass a decent return value. | 12:00.39 |
| Robin_Watts | tor8: which transform? | 12:00.44 |
| tor8 | Robin_Watts: I'd rather add max-width, max-height parameters than be clever :) | 12:00.58 |
| Robin_Watts | tor8: My point is that there are various use cases. | 12:01.16 |
| tor8 | Robin_Watts: the transform that comes out to set the draw matrix | 12:01.18 |
| | fz_begin_page returns a device *and* a transform for the draw calls to use | 12:01.40 |
| | the transform that is created to map the user space to the pixmap. it would be nice to have that embedded in the draw device and invisible to the user | 12:02.16 |
| Robin_Watts | There is "ignore resolution and render for this maximum width", "ignore resolution and render for this maximum height", "ignore resolution and preserve aspect, and render as large as possible so as to fit into maximum w/height", | 12:02.42 |
| | etc. | 12:02.45 |
| tor8 | it can't do respect resolution but clamp to this maximum size | 12:03.32 |
| Robin_Watts | tor8: mudraw can't? | 12:03.50 |
| tor8 | the clever mudraw handling only has three cases: respect resolution, pick smallest (of those specified) to fit width/height while preserving aspect ratio, and fit exact w/h | 12:04.35 |
| Robin_Watts | The important thing is that is can ignore or respect aspect ratio. | 12:04.39 |
| tor8 | the code in parse_draw_options does not handle forcing it ignore the aspect ratio | 12:05.06 |
| Robin_Watts | tor8: Right. It would be nice to be able to do as many cases as we can (certainly the common ones that mudraw can do) in the new style. | 12:05.11 |
| tor8 | Robin_Watts: agreed. adding a 'fit' option to force the sizes would be a good addition. | 12:05.35 |
| sebras | sebras/luratech-jbig2 now has a nice commit message and the comments addressed. | 12:06.00 |
| tor8 | also max-width, max-height to clamp the sizes if the resolution makes the size too large, but otherwise respect resolution | 12:06.06 |
| Robin_Watts | Yeah. | 12:06.13 |
| tor8 | I feel adding more options rather than being clever with what is set/unset would be more helpful in the long run | 12:06.29 |
| Robin_Watts | tor8: Yes. | 12:06.38 |
| tor8 | but I think I will want to see if I can remove the need for a matrix out-parameter for draw devices | 12:06.58 |
| Robin_Watts | possibly "aspect" rather than "fit" ? | 12:07.04 |
| tor8 | Robin_Watts: ignore-aspect perhaps? | 12:07.23 |
| Robin_Watts | to say "should I preserve aspect ratio when fitting to max/min?" | 12:07.29 |
| | Sure. | 12:07.44 |
| tor8 | or aspect and do the inverse by default | 12:07.46 |
| | possibly have asymmetric x and y resolutions | 12:08.09 |
| Robin_Watts | Yes, for subpixel rendering you need that. | 12:08.25 |
| tor8 | and maybe an automatic 'rotate to portrait/landscape' | 12:08.31 |
| Robin_Watts | So... fz_begin_page is part of the document_writer interface, and it returns the transform to use at the top level of the 'run' calls. | 12:09.06 |
| tor8 | Robin_Watts: yeah... a mild annoyance for C, but extremely annoying for JS and JNI bindings. | 12:09.32 |
| Robin_Watts | I can't see a nice way to bundle that into the device. | 12:09.39 |
| | Unless we have a device "pageMatrix" field, which the device doesn't actually use itself. | 12:10.45 |
| | It's just there for callers to use ? | 12:10.55 |
| | We could have a 'set' call where you'd feed it the bbox for a page, and it'd set the matrix to a sane value? | 12:12.35 |
| tor8 | Robin_Watts: well, we could stash one in the draw device struct, and concatenate it with the incoming ctm before using | 12:21.27 |
| | I don't see a need for any device other than the draw device to have a 'device space matrix' | 12:22.02 |
| Robin_Watts | tor8: Right, that's what I'd be against. | 12:22.07 |
| | I'm unhappy with the idea of the draw device having special 'hidden' state. | 12:22.47 |
| tor8 | right now, the api requires you to query for the device space matrix and concatenate that with your own graphics matrixes | 12:23.05 |
| Robin_Watts | The same arguments should work with a draw device, as with any other device. | 12:23.24 |
| tor8 | when all a user really wants to care about are the graphics object to user space matrices | 12:23.29 |
| | not being able to start with the identity matrix to draw to a page is irksome | 12:23.54 |
| Robin_Watts | To have to say "oh, this is a draw device, I've got to use different values" would appear to undermine the whole point of the device interface. | 12:24.04 |
| tor8 | Robin_Watts: well, that's what we have *now* | 12:24.17 |
| | my point is that we shouldn't need to know or care whether it's a draw device or display list device | 12:24.37 |
| Robin_Watts | I'm absolutely in agreement with that statement. | 12:24.51 |
| | I'm not yet in agreement with your claim that that's what we have. | 12:25.03 |
| tor8 | now you need to know it's a draw device, set up a start transform to fit the pixmap, and use that rather than an identity matrix | 12:25.05 |
| | when drawing to a display list, or doing text extraction, etc, you always start with the identity matrix | 12:25.31 |
| | in mudraw, all fz_run_page calls *except* the one drawing to a draw device take &fz_identity as the argument | 12:26.55 |
| Robin_Watts | Looking at mudraw, I see the same ctm calculations being used for SVG and draw devices. | 12:27.05 |
| tor8 | and I have no idea why it's doing that for SVG... | 12:27.36 |
| | I guess it's scaling the SVG output depending on the resolution? that seems wrong :) | 12:28.09 |
| Robin_Watts | That does seem odd. | 12:30.59 |
| | OK, go for it, and see how it shakes out, I guess. You might be right. | 12:31.22 |
| | All your commits lgtm, modulo the comments I've made above. | 12:32.12 |
| | sebras: I assume that tor8's review of your commits is enough? | 12:33.16 |
| tor8 | Robin_Watts: returning the options sounds like a good idea. | 12:33.21 |
| | Robin_Watts: sebras: I have not looked at the core of the decoding functions | 12:33.36 |
| | fiddling with the aspect/max-width/min-width stuff can be done later | 12:33.48 |
| | Robin_Watts: I'll fiddle with the draw device options when I get back next week, so we can hold off pushing that commit | 12:35.03 |
| rayjj | I saw mention of the bbc bit above, but it's quite a bit pricier than the C.H.I.P. computer -- I joined the kickstarter and mine has shipped (finally). Specs here: http://postscapes.com/9-single-board-computer-chip | 14:17.41 |
| | 1Ghz processor are 512 MB of RAM and 4 GB of flash storage, Wi-Fi and Bluetooth connectivity, standard and micro USB ports, and a composite AV jack that can output video and audio. I also got the HDMI module for it | 14:19.12 |
| | When I get it I plan on porting our stuff to it. I'll get to check out chrisl's cross compile :-) | 14:20.43 |
| Robin_Watts | nice. | 14:21.21 |
| jogux | rayjj: crikey. that seems implausibly cheap! | 14:28.13 |
| | tor8: the iOS builds are failing with 'ld: unknown option: --gc-sections'. Apparently the equivalent is '-dead_strip' so I guess we need to use that for Mac & iOS builds. and -ffunction-sections / -fdata-sections is not supported with -fembed-bitcode apparently. :( | 15:33.25 |
| | fredross-perry: There's some iOS code improvements on my mupdf repo if you fancy looking sometime | 16:13.44 |
| fredross-perry | I will look | 16:14.14 |
| | jogux: should we prevent building on XCode<4.4 as a result of your updates then? | 17:03.54 |
| jogux | fred: so instancetype vs id. Let's start with 'instancetype'. That is all to do with subclassing really. If I have a class Foo and a method - fooWithBlah, I would normally make it return a 'Foo *'. Except that's wrong when you subclass foo to a new class called 'bar', the method should then return a Bar *, not a Foo *. So previously your only choice was to return id instead (id being the equivalent of a 'void *' in C, works as any kind of object). | 17:06.39 |
| | fred: so now you can return "instancetype" which means "I return an object that is of the type that my class is", and subclassing now works properly | 17:07.08 |
| | actually in some/most cases the compiler treats an (id)init as returning instancetype anyway, but it's better to be explicit. | 17:07.43 |
| fredross-perry | Clever. | 17:07.44 |
| jogux | we don't really need to worry about xcode less than 4.4 for likely a few reasons, but a good one it is predates iOS 6.1 and iOS 6.1 is the minimum we support. | 17:08.56 |
| fredross-perry | all right then. | 17:09.14 |
| psmlbhor | hello. I am getting an error /limitcheck in -file- Operand stack: | 17:26.29 |
| | 5100 6600 8 --nostringval-- . Can someone tell me what is it ? | 17:26.29 |
| Robin_Watts | psmlbhor: That's a sign that your postscript has gone wrong. | 17:28.26 |
| | You're the gsoc coder, right? | 17:28.35 |
| psmlbhor | yes | 17:28.38 |
| fredross-perry | jogux: works for me. But I did need to hack around the build issues that you mentioned earlier. | 17:28.46 |
| Robin_Watts | Why don't you give us a rundown of exactly what you're doing? | 17:28.53 |
| fredross-perry | but, also getting: ld: warning: option -s is obsolete and being ignored | 17:29.49 |
| psmlbhor | Robin_Watts, I an writing a filter to convert raster file to PS file. The filter currently works fine with color model black and bit depth 1 but fails on bit depth greater than one | 17:29.59 |
| Robin_Watts | psmlbhor: And you're not writing that by simply calling mupdf? | 17:30.48 |
| | You're doing the raster file handling/decoding/rendering/conversion to PDF all by yourself? | 17:31.17 |
| psmlbhor | Robin_Watts, Wow I didn't knew that I can do such a thing. I am doing it all by myself | 17:31.46 |
| Robin_Watts | psmlbhor: I have tried to point this out in the past. | 17:32.06 |
| | mutool draw -o out.ps in.jpg will convert jpeg to a postscript file with an embedded image. | 17:32.56 |
| psmlbhor | I thought MuPDF contains the implementation details to carry out the task | 17:32.58 |
| | does it work with PWG raster files also? | 17:33.20 |
| Robin_Watts | It will produce pwg, yes. | 17:33.29 |
| | and pcl. | 17:33.31 |
| psmlbhor | I mean PWG raster files as input | 17:34.12 |
| Robin_Watts | It does not read PWG files currently, but could easily be made to. | 17:37.11 |
| | That would seem a reasonable way to go to me. | 17:37.39 |
| | Adding PWG reading code would be easy. | 17:40.51 |
| psmlbhor | ok. I will discuss it with my mentor. Also, what is the reason of the /limitcheck error? | 17:41.20 |
| Robin_Watts | psmlbhor: It's a particular syntax error in your postscript. | 17:41.40 |
| | I can't comment more without seeing the postscript file (and even then, my postscript isn't that good) | 17:42.00 |
| | Ah, right. | 17:42.45 |
| | Limitcheck errors are generally given because your postscript is using 'too many' of something. | 17:43.19 |
| | I'd suspect you're recursing somewhere or you've got more nesting than is reasonable or something. | 17:43.52 |
| psmlbhor | Oh! the ascii representation of an RGB raster file is too big to handle I think. | 17:44.37 |
| | the file size is about 128 MB with 99% being the image ascii values. This must be causing the error | 17:45.13 |
| Robin_Watts | psmlbhor: Could be. | 17:49.24 |
| | but I don't think large streams are themselves a problem. | 17:49.51 |
| psmlbhor | yes, large streams are creating problems | 17:51.53 |
| | Robin_Watts, thank you for your help | 17:55.34 |
| Robin_Watts | psmlbhor: No worries. If you want to pursue the angle of doing more if it using mupdf then do hang around here and ask qestions. | 17:56.15 |
| | questions. | 17:56.20 |
| psmlbhor | Robin_Watts, yes sure. Thanks | 17:56.33 |
| Robin_Watts | First off, I'd have a play to see if what "mutool draw -o out.ps in.jpg" etc gives you is suitable. | 17:57.24 |
| | The -c {mono,grey,rgb,cmyk} flags should help too. | 17:57.56 |
| psmlbhor | Even I will try it now | 17:58.24 |
| rayjj | mvrhel_laptop: I finally ran the image decode tests with older (7.0) Distiller. Let me know if you want anything else | 20:12.43 |
| | Lab_Test_B.ps seems to be different to what Ghostscript generates -- has colors with gs, but is all black with Acrobat 7 | 20:13.48 |
| mvrhel_laptop | rayjj: can you send me the pdf files it generates? | 20:34.57 |
| | oh you already did | 20:35.14 |
| | thanks rayjj | 20:35.18 |
| rayjj | np | 20:35.22 |
| | (you saved me typing "I did" ;-) ) | 20:35.38 |
| mvrhel_laptop | rayjj: so the question is. what becomes our target | 20:35.51 |
| | since adobe has changed | 20:35.56 |
| rayjj | I think following the spec is the way to go. But is this a customer bug? | 20:36.16 |
| mvrhel_laptop | No it was a user bug. The actual bug was a different problem. But in working on it, I saw this issue | 20:36.43 |
| rayjj | after all, we probably have as many users as Adobe does (for PS) :-) | 20:37.05 |
| mvrhel_laptop | rayjj: OK. I may add a comment in the code where this stuff is handled so that I remember what the issue is | 20:37.23 |
| | I am sure down the road we might run into it again | 20:37.34 |
| rayjj | mvrhel_laptop: and there or in the bug report (referenced in your comment) mention that Adobe does it differently depending on what version of their stuff is used | 20:38.12 |
| mvrhel_laptop | rayjj: good point | 20:38.21 |
| rayjj | I'm just sorry that I can't run CPSI at the moment | 20:38.28 |
| mvrhel_laptop | that really should be our target if you get it back up and running | 20:38.43 |
| rayjj | I need to sit down with tools and see if the old XP system is actually fried -- maybe I can have my son swap out the P/S from another older unit that has the same type P/S | 20:39.48 |
| | good thing I don't throw all these old computers away (minimalists would have) | 20:40.26 |
| | I am thinking of getting rid of my tube tester ;-) | 20:41.16 |
| mvrhel_laptop | rayjj: yes. I have not gotten rid of any electronic equipment.... | 20:41.46 |
| rayjj | and maybe even my Tektronix 515A o'scope | 20:41.57 |
| mvrhel_laptop | do you have a digital scope? | 20:42.20 |
| rayjj | mvrhel_laptop: I have a USB scope (dual channel) for the PC | 20:42.45 |
| mvrhel_laptop | ok | 20:42.53 |
| rayjj | but it is not good for modern digital stuff -- those are much too pricey | 20:43.15 |
| | Forward 1 day (to 2016/06/08)>>> | |
IRC Logs