| <<<Back 1 day (to 2015/10/11) | 20151012 |
diemex | Hey, would it (theoretically) be possible to turn a pdf into android graphics objects like lines text etc to render from java? | 08:49.53 |
kens | In theory, yes | 08:50.05 |
| THe graphcs model determiens how granular such objects can be | 08:50.24 |
diemex | That would be pretty cool to modify pdf pages, to just modify the graphics objects | 08:51.47 |
kens | You wouldn't be modifying the PDF pages, you would be modifying the android graphcis objects | 08:52.14 |
diemex | and then export that to pdf later | 08:52.27 |
kens | Yes, but its not the same PDF< you aren't 'modifying' the PDF | 08:52.40 |
diemex | yeah true | 08:52.50 |
kens | I know its a bit obseessive, but I get ths a lot from people runnign files through pdfwrite who insist they are 'modyfing' or 'compressing' or 'optimising'; their files, when they certainly are not. | 08:53.24 |
| The problem in all these cases is that unless the graphcs model you are converting to is at least as rich as the source model, objects will have to be transformed. The transformation risks losing 'soemthing' | 08:54.21 |
| Transparency in PDF is a major stumbling block in ths regard | 08:54.53 |
diemex | What kind of transparency? | 08:55.35 |
kens | Pretty much any kind | 08:55.43 |
Robin_Watts | diemex: PDF transparency is amazingly complex. | 08:55.52 |
| diemex: You might want to consider using MuPDF for this. | 08:56.11 |
kens | s/amazingly/stupidly mind-bogglingy./ | 08:56.12 |
Robin_Watts | MuPDF breaks all it's input files down to a series of 'device' calls. | 08:56.32 |
| For things like 'fill text', 'fill path' etc. | 08:56.50 |
| Many of those will map sanely onto java calls. | 08:57.08 |
| I started on some JNI code at once to map them to/from the 'Canvas' class. | 08:57.26 |
diemex | And how did that pan out? | 08:57.45 |
Robin_Watts | Depending on your exact environment, you might be able to work with a mupdf lib under a JNI wrapper. | 08:58.03 |
| diemex: I ran out of time, but the code may be around somewhere. | 08:58.15 |
diemex | Well I would like to use mupdf with multicore rendering in android. | 08:58.30 |
Robin_Watts | Right. MuPDF sounds like a better bet than gs in that environment. | 08:58.57 |
diemex | the new beta gradle plugin aparently supports ndk/jni along side java | 08:58.58 |
Robin_Watts | apparently, yes. | 08:59.23 |
diemex | But I really want multicore rendering. I want it to be as fast as just possible | 09:00.13 |
Robin_Watts | MuPDF supports that. | 09:00.39 |
Robin_Watts | runs to station. bbs. | 09:02.40 |
diemex | In MuPdfCore there are methods like drawPage() but how do I multicore render from java | 09:05.13 |
| Do I have to add multicore jni bindings? Looking at the C-Code I'm having a hard time understanding it | 09:05.46 |
Robin_Watts | diemex: If you don't speak C, you will be in trouble. | 09:54.29 |
| MuPDF has a C level API that you'd need to work with. | 09:54.38 |
| You'd have to expose that into java using JNI, which requires you to understand C well enough. | 09:55.01 |
diemex | Yeah that is the issue | 09:56.33 |
| What ide do you use for C? | 09:57.29 |
Robin_Watts | Visual Studio. Or Emacs. | 10:04.24 |
diemex | Okay, before I spent time on this lets make sure MuPdf has everything I need. 1. I need to multicore render pages 2. display table of contents 3. extract/search for text 4. add annotations over the pdf 5. insert pages | 10:09.09 |
| 6 delete pages | 10:09.30 |
Robin_Watts | 1,2,3 yes. | 10:42.10 |
| 4 for certain types of annotation, yes. | 10:42.20 |
| 5,6 depends on what you mean. | 10:42.31 |
diemex | well I'm trying to build a pdf app which enables writing. I need to be able to add a blank page into the pdf to write on | 10:44.04 |
| so the annotations i need to add are handwriting mainly | 10:45.50 |
| vector graphics | 10:45.54 |
Robin_Watts | diemex: If you're not a C programmer, forget it. | 10:50.25 |
diemex | well I'm not going to write it in C. I'm writing it in kotlin/java. I just need something to do the pdf stuff for me | 10:56.37 |
Robin_Watts | diemex: Right. To do that with MuPDF you will need to write code to interface with MuPDF. Which requires you writing in C. | 10:57.51 |
| You may also need to extend MuPDF a bit, again which will require C skills. | 10:58.09 |
diemex | Yeah so it is probably just better to use something else | 10:58.39 |
| Or I just use mupdf for rendering. For multicore rendering I just need to add the bindings right? | 11:04.35 |
kens | lunches, I'll try out the plibm device afterwards | 11:05.46 |
printline | hi, what are ENV.cc and prefix in this file? https://github.com/Homebrew/homebrew-x11/blob/master/mupdf.rb | 11:07.01 |
| Iâm trying to compile it by hand on OS X | 11:07.18 |
| it works fine when brew does it, but it fails at openssl, OpenGL and X11 includes/libs | 11:07.46 |
| Iâve tried adding them via XFLAGS and XLIBS, and by editing the Makefile but that doesnât work | 11:08.13 |
Robin_Watts | printline: You'd need to take that up with the homebrew packagers. | 11:08.46 |
| If you want to use *our* sources, then we are better placed to help. | 11:09.09 |
printline | Robin_Watts: it is you sources, as it seems: url " | 11:09.46 |
| http://mupdf.com/downloads/mupdf-1.7a-source.tar.gz | 11:09.48 |
Robin_Watts | printline: Right, so what's the homebrew URL above about? | 11:10.15 |
printline | I was wondering what the CC= and prefix= arguments could be that make it run | 11:10.42 |
| (presumably) | 11:10.53 |
Robin_Watts | printline: Just run 'make' ? | 11:11.23 |
printline | Robin_Watts: that fails at openssl, OpenGL and X11 paths | 11:12.07 |
| source/pdf/pdf-pkcs7.c:5:10: fatal error: 'openssl/err.h' file not found | 11:12.13 |
| which can be corrected with this argument for make: XCFLAGS='-I/usr/local/opt/openssl/include' | 11:12.45 |
| but it will fail later at missing OpenGL symbols: LINK build/debug/mupdf-gl | 11:13.28 |
| Undefined symbols for architecture x86_64: | 11:13.31 |
| "_glXCreateNewContext", referenced from: | 11:13.34 |
| _createLegacyContext in libglfw.a(glx_context.o) | 11:13.36 |
| oh, but perhaps this is from the newest version from the git reposity? | 11:13.56 |
| anyway, Iâm basically wondering what magic brew does to make it work | 11:14.12 |
Robin_Watts | printline: IF you're using the latest version from the git repo, then you'll need the opengl stuff too. | 11:14.36 |
| Did you git submodule update --init ? | 11:14.43 |
printline | you are right that I should better ask on #Homebrew, but I thought perhaps someone would know how to fix that | 11:14.44 |
| yes | 11:14.57 |
Robin_Watts | bear with me. | 11:16.44 |
tor8 | Robin_Watts: mupdf-gl needs work to build on macosx without x11. good news is, it should be possible. the Makethird section for GLFW needs an ifdef macosx part with the macosx files in it. | 11:17.08 |
Robin_Watts | printline: OK, so there's your answer. We are preparing the new release of MuPDF at the moment, and that's involved some changes. Give it a while to settle down. | 11:17.54 |
printline | Robin_Watts: I saw that the common way to include opengl in os x is -framework OpenGL, instead of -lGL | 11:18.54 |
| (not 100% sure though, but it seemed that it wasnât that way in either makefiles) | 11:19.21 |
Robin_Watts | If you: git checkout 1.7a && git submodule update --init | 11:19.29 |
| You will backtrack to the last release, and that should be easier to build currently. | 11:19.48 |
| printline: tor8 is the OpenGL guy, not me. | 11:20.07 |
| Trying to set this new PC up. | 11:29.41 |
| When I hit ctrl-c in msys bash, the shell exits. | 11:29.53 |
| That's going to get old fast. | 11:29.59 |
| Hmm. Seems to only happen in ConsoleZ. | 11:30.40 |
| AH, known problem with the latest git-bash :( | 11:34.33 |
tor8 | Robin_Watts: eh, that sounds awful | 11:44.03 |
Robin_Watts | It's pretty dire. I may have to downgrade my git install. | 11:45.18 |
| Ok, I may have a workaround. | 11:48.19 |
| My graphics card has 3 display port slots, 1 DVI port and 1 HDMI port. | 12:09.35 |
| am I reasonable in thinking that it must cope with 3 monitors ? | 12:09.45 |
kens | Maybe it has one spare in case you break one :-) | 12:10.02 |
Robin_Watts | ooh, 4 displays. I think that's probably overkill though. | 12:11.28 |
kens | Robin_Watts : the plibm device seems to be badly broken, and has been for some time. | 12:20.17 |
printline | Robin_Watts: I did a checkout of 1.7, but it still fails to find openssl | 12:20.52 |
| Robin_Watts: if I just run 'make' | 12:21.01 |
Robin_Watts | make HAVE_OPENSSL=false | 12:21.12 |
| make HAVE_OPENSSL=no sorry | 12:21.24 |
printline | Robin_Watts: still the same error: source/pdf/pdf-pkcs7.c:5:10: fatal error: 'openssl/err.h' file not found | 12:23.51 |
kens | Did a make clean first ? | 12:24.09 |
printline | Robin_Watts: it works by the way, if I add the path manually to XFLAGS="-L/..." | 12:24.13 |
| kens: yes | 12:24.18 |
| XCFLAGS | 12:24.35 |
| i.e. this brings me pretty far: make XCFLAGS='-I/usr/local/opt/openssl/include -I/opt/X11/include' XLIBS='-L/opt/X11/lib' | 12:24.48 |
Robin_Watts | printline: Then you're sorted. | 12:24.50 |
printline | Robin_Watts: ah, it works indeed :) | 12:25.59 |
kens | Hmm, we seem to have an invalid assumption in gdev_mem_open_scan_lines (or possibly an inappropriate use), if mdev->memory is NULL and mdev->line_pointers_memory is NULL then we seem to assume mdev->base is to be used. But in ths case that is NULL too (and we don't check) | 12:26.37 |
printline | Robin_Watts: is this a problem with the makefile or should I add these paths to an environment variable or some of the like? | 12:26.39 |
| anyway, Iâm working on a slight modification to mupdf so that it outputs the current page when it receives a SIGINFO syscall. | 12:28.48 |
| but Iâm not sure whether SIGINFO is available on all platforms | 12:29.02 |
Robin_Watts | printline: There is, I believe, an osx section in Makerules. | 12:29.36 |
printline | (also not sure whether the devs would consider this to be a useful feature at all) | 12:29.45 |
Robin_Watts | If you think this is a generic problem (as opposed to something non standard on your mac os x machine) then feel free to open a bug at bugs.ghostscript.com and add it there. | 12:30.21 |
tor8 | Robin_Watts: printline: 'brew' is not standard macosx though. we should build without that. | 12:30.56 |
printline | Robin_Watts: the surprising fact is that brew compiles is just nicely, though | 12:31.06 |
| they are doing something about these include paths, but I donât know what | 12:31.19 |
tor8 | OpenSSL is a problem though, since it looks like Apple has removed it in newer versions of OSX | 12:31.26 |
Robin_Watts | printline: brew imports all sorts of crap INTO your machine. | 12:31.39 |
| It's entirely possible that brew is importing OpenSSL, and that's what's causing the problem. | 12:32.00 |
printline | Robin_Watts: what are your thougths on the SIGINFO feature? | 12:34.45 |
Robin_Watts | printline: I'm sure someone has already done that with SIGHUP. | 12:35.16 |
| oh, sorry, OUTPUTS the page. | 12:35.28 |
| Urm... as long as it's portable, we'd consider it for inclusion. | 12:35.43 |
kens | Robin_Watts : all the planar devices seem to segment fault if we *don't* use a clist. I can (and will) introduce some protection against that, but the devices still won't work. | 12:36.50 |
Robin_Watts | kens: urgh. They used to work. | 12:39.39 |
kens | THey still do, as long as you have a clist | 12:39.51 |
Robin_Watts | They used to work without a clist. | 12:40.00 |
kens | Defintely don't now | 12:40.10 |
| The plibm device has been broken since 9.12 | 12:40.23 |
Robin_Watts | (or maybe they used to force the use of a clist? Maybe that was something else) | 12:40.30 |
kens | But seg faults on 9.16 and above | 12:40.33 |
Robin_Watts | I have less than no time at the moment :( | 12:40.59 |
kens | I know, sorry | 12:41.08 |
| THs isn't really my area of expertise. I plan to put a check in that prevents the seg fault and aborts GS instead, and then probably open a new (low priority) bug report for t | 12:41.51 |
printline | Robin_Watts: ok, I'll post a patch if I get the SIGINFO thing working | 12:46.49 |
chrisl | Oh, nice.... gdevplib.c uses global variables...... | 12:53.52 |
kens | hadn't noticed | 12:54.26 |
chrisl | plib definitely expects to be a clist device | 12:55.20 |
Robin_Watts | TESTING_WITH_NO_BAND_DONOR ? | 12:55.49 |
kens | Well, if MaxBitmap is big enough, its not a clist device | 12:56.04 |
chrisl | It stands for "PLanar Interlaced Banded" device | 12:56.26 |
kens | Then it should set teh Banding mode to BandAlways | 12:56.48 |
| Not BandAuto | 12:56.56 |
Robin_Watts | kens: Yes, it should. | 12:57.08 |
kens | I'll look at that in a minute | 12:57.19 |
| I've already put a guard into the code that causes the crash due to an assumption, its useful to have that anyway | 12:57.43 |
printline | Robin_Watts: am I doing this correctly kill -SIGHUP pid? | 13:35.37 |
| doesnât seem to update for me | 13:35.45 |
Robin_Watts | printline: sebras or tor8 are better people to ask than me. | 13:37.08 |
printline | using mupdf-x11 by the way | 13:37.37 |
sebras | printline: I think that should work, yes. | 13:51.44 |
| printline: but I haven't tested this recently myself. | 13:51.57 |
printline | sebras: ah, the pid changes when switching C-z/fg? | 13:58.21 |
| sorry, pretty much linux noob :), ok advanced noob | 13:58.38 |
| awesome it works | 14:03.07 |
sebras | printline: that's what I like to hear. :) | 14:05.59 |
kens | D'oh!! make debug....... | 14:10.31 |
| Hmm still seg faults though I wonder why | 14:12.25 |
Robin_Watts | Have lost vision. Taken migraine pills. going for lie down. | 14:49.12 |
mvrhel_laptop | Robin_Watts: darn. hope you feel better soon | 15:28.47 |
kens | Goodnight folks | 16:12.43 |
marcosw | chrisl: you probably know this: how can utf-8 filenames be passed to the windows DLL? | 17:16.44 |
chrisl | marcosw: AIUI, the API takes UTF-8 strings | 17:17.30 |
marcosw | okay, must be my code :-) | 17:19.01 |
chrisl | marcosw: Oh, actually, possibly you have to convert the UTF-8 to wchar - I can't remember where that happens in the API | 17:20.19 |
marcosw | I was just looking at gp_wutf8.c and wondering out utf-8 vs wchar | 17:21.19 |
chrisl | At some point, we convert the encoding from wchar to UTF-8, but I can't remember if that's before or after the call into the DLL API | 17:22.11 |
| marcosw: if you look in dwmainc.c, around line 629 - it looks like you have tell GS to expect UTF-8.... | 17:28.50 |
marcosw | chrisl: thx | 17:35.58 |
chrisl | marcosw: did it work? | 17:36.12 |
marcosw | sorry, was distracted by breakfast. testing it now. | 17:42.14 |
| yup, all good. thanks for much. | 17:51.59 |
chrisl | NP - relieved it worked! | 17:52.09 |
marcosw | I am having a weird issue with wchar_to_utf8() not being found. As a test I just included it in the .c file, but it must be in the .dll. | 17:54.20 |
| or is GS_NO_UTF8 true by default? but if that were the case I | 17:55.40 |
chrisl | wchar_to_utf8() not visible outside the DLL | 17:56.05 |
| Why do you want wchar_to_utf8() anyway? I thought you wanted to pass in UTF-8? | 17:57.04 |
marcosw | i'm starting with wchar as passed to wmain() | 17:57.51 |
| do we have a DLL entry point that accepts wchar? | 17:58.20 |
chrisl | Sort of | 17:58.27 |
| Oh, you can probably call gsapi_run_fileW() | 18:00.21 |
| marcosw: Or, I *think* you can set the encoding to "GS_ARG_ENCODING_LOCAL" do the same as you did with "GS_ARG_ENCODING_UTF8" - but I ain't sure about that | 18:02.44 |
| Got to go....... | 18:03.39 |
marcosw | I'm going to recommend that the customeruse wchar_to_utf8() before calling gsapi_init_with_args(). I'm presuming gsapi_init_with_args() is what they are currently using so this will be an easy change. | 18:03.49 |
| have a good day | 18:03.54 |
Robin_Watts | marcosw: They should call gs_set_arg_encoding to set it to utf8 | 18:19.51 |
| then call gs_init_with_args with utf8 data. | 18:20.02 |
Robin_Watts | returns to bed :) | 18:20.08 |
mvrhel_laptop | marcosw: so does the mupdf project have a clusterpush.pl or equivalent like gs does? | 18:51.54 |
| I dont' see anything in the project | 18:52.13 |
rayjj | seriously? The DroidSansFallback font doesn't contain a ¥ glyph ??? Does it at least contain a $ ;-) | 18:52.27 |
mvrhel_laptop | I had something here that I wanted to test | 18:52.28 |
Robin_Watts | mvrhel_laptop: The same. | 18:52.30 |
mvrhel_laptop | oh hi Robin_Watts | 18:52.41 |
Robin_Watts | Run clusterpush.pl and it spots that it's mupdf and tests that. | 18:52.42 |
mvrhel_laptop | oh ok | 18:52.52 |
| Robin_Watts: also, with a new clean checkout | 18:53.10 |
| the build fails for me | 18:53.13 |
rayjj | http://bugs.ghostscript.com/show_bug.cgi?id=696267#c2 | 18:53.15 |
mvrhel_laptop | due to the GL stuff | 18:53.16 |
Robin_Watts | git submodule update ? | 18:53.38 |
mvrhel_laptop | i did that | 18:54.14 |
| hmm | 18:54.32 |
| hold on | 18:54.34 |
Robin_Watts | git submodule update --init maybe, cos there is a new one I hope. | 18:54.54 |
| If that doesn't work, complain to the viking :) | 18:55.09 |
mvrhel_laptop | if he was here I would.... | 18:55.28 |
| I did do the --init | 18:55.44 |
| I wonder how it got through the cluster though with this | 18:56.12 |
| Robin_Watts: anyway, there is a fix on my repos | 18:56.25 |
| that deals with list box widgets | 18:56.43 |
| this fixes some issues that we were having | 18:56.56 |
| Robin_Watts: if you can have a look sometime that would be great | 18:57.09 |
Robin_Watts | Urm... You've not pushed it. | 18:57.30 |
mvrhel_laptop | hmm | 18:57.35 |
| oh you are right | 18:57.42 |
| sorry | 18:57.44 |
| hold on | 18:57.45 |
| ok should be there now | 18:58.32 |
| sorry about that | 18:58.34 |
Robin_Watts | lgtm. | 19:01.36 |
mvrhel_laptop | oh good. ok when the build is fixed, I will push it then | 19:02.23 |
| thanks Robin_Watts . Hope you are feeling better | 19:02.33 |
| Forward 1 day (to 2015/10/13)>>> | |