| | <<<Back 1 day (to 2016/01/12) | 20160113 |
| Robin_Watts | tor8@ ping | 10:55.09 |
| tor8 | Robin_Watts: morning | 10:55.15 |
| Robin_Watts | Are you un-js'd yet ? | 10:55.26 |
| tor8 | I saw the gigantic const commit! | 10:55.33 |
| | more or less, I got the typed arrays working | 10:55.39 |
| | which helped me iron out a few more details in the mujs api | 10:55.50 |
| kens | chrisl ping | 10:56.56 |
| Robin_Watts | tor8: How did you feel about the const commit? Have you looked at it properly yet? | 10:57.36 |
| chrisl | kens: pong | 10:57.44 |
| kens | I just got a weird cluster build warning, it said there were 'parallel make issues' | 10:58.01 |
| | http://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?log=make&machine=kilometers&report=ken | 10:58.08 |
| | I can't actually see anything wrong there, but I have no idea what to look for, which doesn't help | 10:59.11 |
| chrisl | I see the problem. It shouldn't take long to fix | 10:59.46 |
| kens | Oh, OK | 10:59.55 |
| | Sadly I don';t thnk that's the cause of my (astonishing) 2000 PDF interpreter problems :-( | 11:01.03 |
| | I have ot go out briefly, I'll check the logs when I get back | 11:01.34 |
| tor8 | Robin_Watts: I'm divided | 11:06.09 |
| Robin_Watts | I think I'm pretty happy with it. | 11:08.12 |
| | There is 1 thing that's not ideal. | 11:08.34 |
| | fz_keep_xxxx now takes a const fz_xxxx * and returns a non const fz_xxxx | 11:09.03 |
| | so you can effectively cast away const by keeping, which is nasty. | 11:09.35 |
| | but the alternative is to have fz_keep_const_xxx as well. | 11:09.45 |
| tor8 | yeah, same problem that libc has with strtod | 11:10.03 |
| Robin_Watts | and doing this work has shown up 1 potential issue. | 11:10.10 |
| tor8 | strtod(const char *p, char **endp) | 11:10.24 |
| | endp will point to p, and lose the const | 11:10.35 |
| Robin_Watts | tor8: right. | 11:10.42 |
| | I think I'm prepared to live with that. | 11:10.52 |
| tor8 | I think that's an unavoidable side effect of const in c being all wonky | 11:10.57 |
| Robin_Watts | On the whole I think it's an improvement. | 11:11.00 |
| | basically 'const fz_xxxx' means "you can keep it around, but you can't make changes to it", which seems a reasonably intuitive result. | 11:11.26 |
| tor8 | yes, that part I do like | 11:11.35 |
| | the extra typing due to more keywords, I can live with | 11:11.47 |
| | and clients who don't really care, unless they're implementing the device interface won't really need to worry | 11:12.47 |
| | since they create non-const structs and pass them around | 11:12.57 |
| | so what was your potential issue? | 11:13.13 |
| Robin_Watts | The minor problem I spotted - the displaylist device is passed const fz_texts. It assumes that if it keeps the fz_text, it can then stash a pointer to it in the list and the caller won't alter the fz_text. | 11:13.16 |
| | So by making a call into the device interface, you effectively lose the ability to further change the thing you pass. | 11:13.45 |
| tor8 | yes, I think that's part of the device interface contract | 11:13.54 |
| Robin_Watts | Well, if we're happy with that, then I can see no real downsides. | 11:14.12 |
| tor8 | which is why I sort of suggested adding fz_freeze_path/text calls | 11:14.16 |
| | to make it very explicit and guard against stupidity errors | 11:14.28 |
| Robin_Watts | We already have fz_shrink_path or something I think. | 11:14.47 |
| tor8 | then you can remove your fz_trim_path magic call in fz_keep_path | 11:14.48 |
| Robin_Watts | Your memory for names is better than mine :) | 11:15.01 |
| tor8 | Okay, then I think you can consider me convinced of constifying the whole mupdf code base. | 11:18.20 |
| Robin_Watts | Ok, so I'll rebase the const one up and push that. | 11:19.14 |
| | I reckon the jni commits are ready to go in too (at least as as first cut) | 11:19.32 |
| | (not the app changes, obviously) | 11:19.39 |
| tor8 | yeah, I should take the jni commits and bash them into shape to work for desktop java too | 11:19.50 |
| | but that can happen on master, I reckno | 11:19.56 |
| Robin_Watts | and I'll squash them all before committing, but it's probably easier for you to read in the current form. | 11:20.07 |
| | yeah, if we can figure out a way to have a platform/java version, that'd be great. | 11:20.32 |
| tor8 | the 'regularise' commit looks good | 11:20.38 |
| Robin_Watts | but I can't see how to do that without using unifdef | 11:21.00 |
| tor8 | unifdef? | 11:21.13 |
| Robin_Watts | unifdef is akin to the cpp. It just processes ifdefs out of source trees. | 11:21.42 |
| tor8 | you mean to ifdef preprocess java sources? | 11:21.50 |
| Robin_Watts | We use it in SOT. | 11:21.54 |
| | yes. | 11:21.56 |
| tor8 | hm. I think it should be possible, by keeping android things in classes we don't compile on desktop | 11:22.22 |
| Robin_Watts | tor8: the problem is that java builds are sensitive to paths. | 11:23.07 |
| | perhaps we can build a mupdf_jni.jar out of the independent stuff, and then include that as required. | 11:23.47 |
| tor8 | as a separate step in the android builds? | 11:24.44 |
| | not sure how android java builds work under the hood | 11:24.53 |
| | does it take class files in a jar and dexify them at the 'upload' step? | 11:25.05 |
| Robin_Watts | I'm gonna say yes (I think so) | 11:25.18 |
| | I believe it's capable of combining jars. | 11:25.28 |
| tor8 | do we really want the package name to be com.artifex.mupdf.fitz? | 11:26.09 |
| Robin_Watts | com.artifex.mupdf is taken already. | 11:27.17 |
| tor8 | is that taken for just apps or also libraries? | 11:27.30 |
| Robin_Watts | (at least on google play) | 11:27.32 |
| | Possibly just for apps. | 11:27.42 |
| | but do you want to take the risk that it'll bite us later? | 11:28.15 |
| tor8 | I hate google. | 11:28.32 |
| Robin_Watts | I was thinking that we might end up using com.artifex.mupdf.{pdf,xps} etc at some point. | 11:28.38 |
| | so it wasn't too unnatural. | 11:28.56 |
| tor8 | fair enough then | 11:29.03 |
| | at least it keeps the core library in its own package | 11:29.17 |
| | any app and UI stuff we add on top of that would go in something like com.artifex.mupdf.android | 11:29.45 |
| Robin_Watts | yeah. | 11:31.56 |
| tor8 | Robin_Watts: actually, could you push the new jni stuff to a branch on golden, or would the const rebase be bothersome? | 11:32.54 |
| | I figure if we're going to shift files and directories around to make it build on both desktop and android it might be better suited to a branch | 11:33.26 |
| Robin_Watts | tor8: will push to a branch, sure. | 11:35.12 |
| | I hope I can pull the const stuff through it. | 11:35.21 |
| | tor8: OK, so 2 commits on robin/master | 12:37.12 |
| | One is the const one. | 12:37.15 |
| | The other is a fix to add the fz_pool files to the visual studio solution. | 12:37.30 |
| tor8 | Robin_Watts: LGTM | 12:38.16 |
| Robin_Watts | just waiting for a cluster test to run, then I'll push. | 12:38.29 |
| | I'll squash the other JNI ones, and make a jni branch. | 12:38.47 |
| | Ok, the others are squashed to robin/jni | 13:32.43 |
| tor8 | Robin_Watts: fz_keep_path does not take a const fz_path... | 14:02.54 |
| Robin_Watts | fixing | 14:04.22 |
| | Fixed version on robin/master | 14:08.40 |
| tor8 | Robin_Watts: have you compiled your jni branch with warnings turned on? | 14:10.21 |
| Robin_Watts | on MSVC. | 14:10.34 |
| tor8 | I'm fixing up them as I go, trying to compile for desktop java | 14:10.37 |
| Robin_Watts | sorry, no, ignore that. | 14:10.56 |
| | I've built the JNI branch on android using ndk-build. | 14:11.11 |
| | I dunno what that does for warnings... | 14:11.20 |
| tor8 | nothing, I think | 14:12.05 |
| | I got dozens of invalid casts (the const change), unused variables, use of uninitialized variables, etc | 14:12.34 |
| Robin_Watts | let me try modifying the files. | 14:12.41 |
| tor8 | Robin_Watts: don't, I'm in the middle of fixing them up | 14:13.43 |
| | I'll put a commit up in a couple of minutes | 14:13.48 |
| Robin_Watts | tor8: cool, thanks. | 14:13.53 |
| tor8 | I've almost got it building warning free here now | 14:13.54 |
| Robin_Watts | grabs lunch then. | 14:13.58 |
| tor8 | Robin_Watts: initialization problems with desktop java, the statics and class loading order are acting up :( | 15:27.13 |
| mvrhel_laptop | tor8: so I have the case of create -o output.pdf -i Im0:image.jpg -i Im1:image1.jpg -i Im2:image.jpg contents.txt working. image.jpg is detected as being present in the hash table (and is hence in the document), so the occurrences of Im2 in the contents use the ref object from the hash table | 15:33.11 |
| | tor8: I was trying to figure out how are we comparing fonts? | 15:33.29 |
| | or how should we | 15:33.40 |
| | do I do an md5 on the fontfile2 contents? | 15:33.53 |
| Robin_Watts | tor8: At what level? | 15:33.57 |
| | (answer mvrhel first, I'll wait) | 15:34.07 |
| mvrhel_laptop | sorry to jump in | 15:34.16 |
| Robin_Watts | no worries. | 15:34.27 |
| mvrhel_laptop | I see you guys have been bus | 15:34.29 |
| | busy | 15:34.32 |
| | I have to run to a Dr. appt this morning (like in 5 minutes). tor8: so if you can leave me any thoughts about the font compare that would be great. I am going to get going on the CID identity font output next | 15:39.51 |
| kens | chrisl I'm going to go ahead and book flights with Virgin | 15:45.21 |
| chrisl | Oh, right, forgot about that......] | 15:46.03 |
| Robin_Watts | oh, I should talk to Paul about that. | 15:46.15 |
| kens | I'm selecting the Thursday 3rd 12:20 departure (arrives 15:20 local) and the Sunday 6th 17:00 departure (arrives Monday at 11:30) | 15:48.22 |
| chrisl | VS041 and VS020 | 15:48.50 |
| kens | 041 yes, not sure about the other | 15:49.26 |
| | ah yes 020 | 15:49.52 |
| | £580.35 | 15:50.04 |
| Robin_Watts | Flying back on saturday is possible. | 15:53.57 |
| kens | <sigh> Looks like I'm going to have to talk to my credit card provider. | 15:54.11 |
| | Robin_Watts : saturday night stay for cheap ticket ? | 15:54.22 |
| chrisl | Returning Saturday == 1,400.35 ukp | 15:54.56 |
| kens | isn't paying :-) | 15:55.10 |
| Robin_Watts | kens: Paul and I are flying Wed. Wed -> Sat = 715. Wed -> Sun = 584 | 15:55.20 |
| kens | Intriguingly cheap | 15:55.34 |
| Robin_Watts | how much does miles pay per night at the hotel? I'll bet it's not much shy of 130 quid. | 15:55.41 |
| kens | No idea | 15:55.48 |
| Robin_Watts | especially when you take food etc into consideration. | 15:55.52 |
| kens | I don't really want to fly Wednesday though | 15:56.09 |
| Robin_Watts | kens: No, for you it's no good. | 15:56.19 |
| | but for us, it's interesting. | 15:56.28 |
| | means I have a crap sunday rather than a crap monday, but... | 15:56.43 |
| chrisl | Okay, flights booked | 16:11.32 |
| kens | I'm having cre3dit card trouble.... | 16:12.29 |
| | I thnk I'm going to have to cal them, the 'verified by Visa' step just hangs | 16:12.47 |
| chrisl | Mines Mastercard but it takes over 30 seconds to work | 16:13.26 |
| tor8 | mvrhel_laptop: I'm not sure, with reusing fonts there's also the whole issue with pre-existing encodings etc | 16:13.31 |
| | so just comparing the font data may not be sufficient | 16:13.42 |
| kens | chrisl, I'm waiting minuntes and nothing happens | 16:13.44 |
| tor8 | Robin_Watts: I suspect desktop java and android java differ in how/when JNI_OnLoad is called | 16:14.05 |
| chrisl | And also the VA site keeps "encountering a problem, please try again later......" | 16:14.13 |
| tor8 | I'm getting unresolved link error for nativeDeviceGray | 16:14.19 |
| kens | chrisl not seen that one yet.... | 16:14.37 |
| tor8 | I suspect different implementations will load the native symbols in different orders | 16:14.38 |
| | I'll try making an explicit initNative() call to do the OnLoad find_fids and context setup stuff | 16:15.00 |
| Robin_Watts | tor8: Yeah, the android stuff was a pain. | 16:16.04 |
| | JNI_Onload runs, and finding method ids for ColorSpace causes the statics in the ColorSpace stuff to run. | 16:16.47 |
| | so they run (including doing 'get_context') before OnLoad has returned. | 16:17.11 |
| kens | well apparently there's nothing wrong with my card, they're checking with Visa.... | 16:20.14 |
| | Apparently its just the web sites :-( | 16:21.58 |
| tor8 | Robin_Watts: yeah. and I suspect desktop java hasn't loaded the native symbols from the DLL into a symbol table before JNI_OnLoad | 16:26.54 |
| | anyway, solved that. now I get crashes which seem to be related to the pthreads stuff. | 16:27.16 |
| | I just commented out all the pthread stuff (and use only base_context) and things are running | 16:27.29 |
| Robin_Watts | cool. | 16:33.04 |
| tor8 | Robin_Watts: ah, pthread_key_create() is never called | 16:34.30 |
| Robin_Watts | really? | 16:34.49 |
| tor8 | yup. | 16:34.59 |
| Robin_Watts | did I drop that in a refactor or something? | 16:35.00 |
| tor8 | sounds not entirely unlikely | 16:35.12 |
| Robin_Watts | balls. | 16:36.09 |
| tor8 | Robin_Watts: fixes and enough to run desktop java on tor/jni | 16:36.19 |
| | has dropped the android classes completely | 16:36.26 |
| | will reinstate them as separate classes, maybe in a separate package? | 16:36.48 |
| | unless they're functions that you don't need right now, in which we can wait | 16:37.04 |
| | in which case we can wait | 16:37.14 |
| Robin_Watts | cdevice_nativeresource_fid shouldn't be android specific. | 16:37.41 |
| tor8 | ah, sorry! | 16:37.54 |
| | that got lost while looking for the linking errors | 16:38.01 |
| Robin_Watts | Is the use of Context_initNative still required? | 16:38.23 |
| | we can't do stuff from JNI_OnLoad ? | 16:38.30 |
| tor8 | hm, no... something's still off with that nativeResource fid | 16:38.42 |
| | Failed to get field for com/artifex/mupdf/fitz/CDevice nativeResource Ljava.lang.Object; | 16:38.51 |
| | Exception in thread "main" java.lang.NoSuchFieldError: nativeResource | 16:38.51 |
| | it appears we can't, I get unresolved link errors from the colorspace class | 16:39.28 |
| Robin_Watts | tor8: Rather than dropping the android specifics, can we have the makefile copy from platform/android to platform/java and delete some files before building? | 16:40.25 |
| tor8 | and just dropping the loadLibrary in Context wasn't enough ... nobody references the Context class so it never got loaded | 16:40.27 |
| | Robin_Watts: I'll figure something out | 16:40.36 |
| | I'll filter the list of files to compile (or put the android bitmap thing in another package) | 16:40.55 |
| | and make a subclass AndroidImage | 16:41.15 |
| | then I just won't compile those on desktop java | 16:41.26 |
| Robin_Watts | Possibly neatest is to copy all the files except the android/awt ones ones into platform/java/generic | 16:41.30 |
| | and have a makefile there that builds a fitz.jar | 16:41.50 |
| | then platform/android can have the android specifics, and I can import fitz.jar into the build. | 16:42.11 |
| | (somehow) | 16:42.18 |
| tor8 | I was thinking of building a mupdf_java.jar and mupdf_java.so in platform/java | 16:42.32 |
| Robin_Watts | and platform/java/windows can have the windows specifics in and can import fitz.jar. | 16:43.00 |
| | and platform/java/x11 can have the unix specifics etc. | 16:43.25 |
| tor8 | I don't think we'll need any windows/linux specific stuff in the native code nor in the com.artifex.mupdf.fitz packages at all | 16:43.50 |
| | access to an int[] for bitmap samples is pretty much platform independent | 16:44.11 |
| | and I certainly don't want to go digging into the Motif and win32 guts of AWT | 16:44.32 |
| Robin_Watts | tor8: Until people want to be able to use some obscure stream variant. | 16:44.41 |
| | or to be able to access some image type or other. | 16:45.04 |
| tor8 | stream variants can be wrapped in java | 16:45.53 |
| | but it wouldn't hurt to leave space for doing it eventually | 16:46.55 |
| | so split mupdf_native.c into mupdf_generic.c mupdf_android.c (and eventually mupdf_desktop.c) in platform/java | 16:47.52 |
| | and have platform specific classes | 16:48.13 |
| Robin_Watts | mupdf_native.c being split is less urgent. | 16:48.15 |
| tor8 | sound reasonable? | 16:48.15 |
| Robin_Watts | but having platform specific classes (possibly just generic and android for now) seems good. | 16:48.37 |
| tor8 | it would be helpful not to have to make a header for it, and keep it all in one place, yes | 16:48.44 |
| | Document.java should probably call Context.init() in a static block | 16:49.29 |
| Robin_Watts | seems reasonable. | 16:49.58 |
| NTQ | Hi. Can please someone confirm this bug? http://bugs.ghostscript.com/show_bug.cgi?id=696500 | 16:51.08 |
| kens | I see you've raised it yes | 16:51.24 |
| tor8 | Robin_Watts: aha! "Ljava.lang.Object;" -> "Ljava/lang/Object;" | 16:53.13 |
| Robin_Watts | Ah. | 16:53.30 |
| marcosw | NTQ: is only a little blue :-) | 16:56.54 |
| NTQ | marcosw: And that's the problem. | 16:58.52 |
| kens | Viewing on screen seems unlikely to match the result when printed on paper, if the ICC profile i (eg) a CMYK profile. But its Michael that has to decide. | 16:59.55 |
| NTQ | kens: So it might get better if I try sRGB? | 17:00.52 |
| kens | Well that depsnds what you mean by 'better' but yes. | 17:01.10 |
| | NB you can't get away from the page being rendered in PDF/A-1 because it does not support transparency, PDF/A-2 does. | 17:01.48 |
| NTQ | kens: Rendering is not the problem. It's okay. The only problem is that blue background. | 17:02.24 |
| kens | Well you are preparing the rendered data to be printed on FOGRA coated paper (according to your report) so I would not be surprised to find that it does not look the same on an RGB monitor | 17:03.08 |
| NTQ | I will test sRGB tomorrow and let you guys know if it helps and if it is okay to use this color scheme. | 17:03.08 |
| kens | I'm not saying there isn't a bug, but its out of my field rather. Michael needs to decide whether the output is correct (even thogh it may not be what you actually want....) | 17:03.55 |
| NTQ | I do not know much about ICC color schemes, but our designer said I should use this. | 17:04.09 |
| kens | What do you intend to do with the final PDF file ? | 17:04.26 |
| | If the answer is anything other than 'print it on FOGRA 39 coated media' then its the wrong thing to use | 17:05.02 |
| | I suspect anyway | 17:05.16 |
| NTQ | It will be uploaded to a public server where people can download these protocols. | 17:05.38 |
| kens | So you have no idea waht the final printed medium will be (if any) | 17:05.56 |
| NTQ | yes | 17:06.02 |
| kens | In which case I would defintiely not select a specific media like that | 17:06.08 |
| NTQ | Good to know. | 17:06.29 |
| kens | Why insist on PDF/A-1 anyway ? | 17:06.31 |
| | PDF/A is for archiving | 17:06.47 |
| | PDF/X is for eXchange | 17:06.55 |
| NTQ | It's the requirement of our costumer. | 17:07.05 |
| kens | Ah 'I've heard of ths so I'm going to mandate it'..... | 17:07.19 |
| | Pointy-Haired Boss Syndrome | 17:07.29 |
| NTQ | :) | 17:07.42 |
| marcosw | NTQ: I just tried with the srgb.icc profile we supply and a suitably modified command line and PDFA_def.ps file and pages 2 and 3 are not blue. So it may well be an issue with the icc profile you are using. That being said I'll let our color expert look at the issue. | 17:08.59 |
| kens | I suspect it may be 'not wrong' more 'not what was expected' | 17:09.20 |
| NTQ | Thank you. | 17:09.39 |
| kens | Possibly it would look correct when printed on that medium, but like I said, it needs a colour specialist's input | 17:09.54 |
| NTQ | And I will clarify the requirements on our side. | 17:10.04 |
| M-cbehling | We ran into a pdf that doesn't render properly using mutool. You should be able to download a copy of it here: https://drive.google.com/file/d/0B6Rwq168n0MXRzVFZVBmQUZvY2M/view | 22:34.52 |
| | using mutool draw -o output-%d.png <file> | 22:35.25 |
| | compiled at repository commit 15ce2165cc01dabc5a670407e00a0b704da0ee2f | 22:36.22 |
| | Forward 1 day (to 2016/01/14)>>> | |
IRC Logs