| | <<<Back 1 day (to 2013/04/25) | 2013/04/26 |
| cryptopsy | what's a nice tool to convert pdf to html, including images that may be interspersed in the document? | 05:48.47 |
| kens | Grr, gmail is messing up *again*, now I'm getting a certificate error from it | 07:19.23 |
| chrisl | I think it should be just a update certificate | 07:24.39 |
| kens | Well I woudl expect that, but it worked first thing, 10 minuntes later it doesn't.... | 07:25.16 |
| | I'm not in a hurry to change anything in Eudora and break it again, since last time it turned out to be Google. | 07:25.43 |
| chrisl | kens: I'm planning to change how gdev_prn_open_printer_seekable() works, which might have an impact on your gdevpsu.c changes | 07:26.11 |
| kens | I saw in the logs, I doubt it will change what I've done | 07:26.29 |
| chrisl | Well, the difference is that it will now return an error if it can't open a seekable file | 07:26.51 |
| kens | I saw. pdfwrite/ps2write will probably need to ifnore the error. | 07:27.14 |
| | ignore* | 07:27.19 |
| | But then we need to know later if we are dealing with a seekable file. | 07:27.32 |
| chrisl | That's what I wanted to ask: is it better to keep the file object open, and return the error, and let the device decide whether to ignore the error, or close the file, and let the device device whether to retry with a non-seekable file? | 07:28.31 |
| kens | chrisl I think its better to keep it open and return an error. A device might be able to cope with either, but prefer seekable | 07:29.02 |
| chrisl | kens: okay, so the only thing there is that the device should ensure that the FILE * is null before the call to gdev_prn_open_printer_seekable() so it can know whether the file object was actually opened | 07:32.23 |
| kens | I guess that makes sense | 07:32.38 |
| | I suspect this really onl;y affects pdfwrite at the moment | 07:32.57 |
| chrisl | Yeh, all the other cases *need* a seekable file, or they won't work | 07:33.24 |
| | kens: my mail client just asked me if it could update the SSL certificate for gmail, so it looks like they might really have changed it | 07:39.21 |
| kens | OK in that case I'll go through the pain..... | 07:39.34 |
| chrisl | Doesn't it update automatically if you allow it? | 07:40.13 |
| kens | Hmm, don't think so, I'm just modifyiong the certificate manager now | 07:40.33 |
| | Yes that fixed it | 07:41.14 |
| chrisl | Claws and TBird just ask if it's safe to import the new key, and if you allow it, the rest is automatic | 07:42.10 |
| kens | Eudora is pretty old | 07:42.23 |
| chrisl | It is several years since I used it...... | 07:43.10 |
| Robin_Watts | cryptopsy: MuPDF is almost there. | 09:06.43 |
| | Morning tor8. | 09:06.47 |
| cryptopsy | Robin_Watts: what? | 09:06.59 |
| tor8 | for pdf to html | 09:07.09 |
| | morning robin | 09:07.11 |
| cryptopsy | tor8: you mean there's an experimental branch i can try right now? | 09:07.26 |
| | is djvu worse than pdf ? | 09:07.34 |
| tor8 | mudraw with the right number of t's in the -t flag will give you html | 09:07.46 |
| | robin's been working on improving that output | 09:07.57 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=summary | 09:08.03 |
| | That includes image output too (very naive, but...) | 09:08.18 |
| cryptopsy | Robin_Watts: you want me to try some files? | 09:08.21 |
| Robin_Watts | and with luck (depending on tor8's reviewing times) it might hit the main repo soon. | 09:08.34 |
| tor8 | djvu is a multi-page *image* format (with ocr:d text info) | 09:08.41 |
| cryptopsy | Robin_Watts: what's the git clone url so i can run some tests for you? | 09:09.32 |
| Robin_Watts | cryptopsy: Do you have a standard git clone of mupdf? | 09:10.30 |
| cryptopsy | yes | 09:10.47 |
| | do i need to clone twice if i want the changes to remain separate from the rest of the source? | 09:11.29 |
| Robin_Watts | If so, just add a new remote with /home/git/user/robin/mupdf.git on the end | 09:11.30 |
| | Then you can pull from my master into a branch on yours. | 09:11.42 |
| cryptopsy | i don't know how to use this git feature | 09:11.56 |
| | git://git.ghostscript.com/user/robin/mupdf.git | 09:12.22 |
| tor8 | git remote add robin git://....what you pasted above... | 09:12.39 |
| cryptopsy | fatal: Not a git repository (or any of the parent directories): .git | 09:13.37 |
| | i suppose i have to run it from ./mupdf/ ? | 09:14.08 |
| Robin_Watts | yes. | 09:14.42 |
| cryptopsy | now what? | 09:14.48 |
| Robin_Watts | git pull robin master:robinmaster | 09:15.11 |
| | That will pull in my master branch as a new "robinmaster" branch on your repo. | 09:15.27 |
| cryptopsy | how does git keep track of this; does it copy the main mupdf files twice and then add your files to the copy? | 09:15.48 |
| Robin_Watts | cryptopsy: Git keeps copies of the different versions of the files, yes. | 09:16.47 |
| | and any given working state contains just one copy of each file. | 09:16.59 |
| cryptopsy | how do i start converting pdf to html once it's compiled? | 09:18.21 |
| | mudraw? | 09:18.53 |
| Robin_Watts | mudraw -tt | 09:27.03 |
| cryptopsy | would you like to see the output? | 09:29.15 |
| | http://ompldr.org/vaTg2bw/llvm.pdf | 09:31.05 |
| | http://ompldr.org/vaTg2cA/test.html | 09:31.07 |
| | some field did not get interpreted (void ...) | 09:31.39 |
| | how to get images? | 09:31.46 |
| Robin_Watts | cryptopsy: Images should be included automatically. If they are not, I'd think that you didn't change to robinmaster before building. | 09:34.42 |
| cryptopsy | i did this command before compiling git pull robin master:robinmaster | 09:35.12 |
| Robin_Watts | cryptopsy: Right. That pulls from roibin master into a new local branch "robinmaster" | 09:35.41 |
| | but you need to "git checkout robinmaster" to make that the active branch. | 09:35.58 |
| cryptopsy | can i just git clone git://git.ghostscript.com/user/robin/mupdf.git | 09:37.04 |
| | in that case? | 09:37.07 |
| Robin_Watts | cryptopsy: You can. | 09:37.17 |
| cryptopsy | i git'ed that and compiled and ran again, and no images | 09:39.10 |
| Robin_Watts | Ah . The images there are line art, not bitmaps. | 09:44.26 |
| | We don't do line art yet. | 09:44.29 |
| | sorry. | 09:44.36 |
| cryptopsy | is that also comming soon? | 09:44.50 |
| Robin_Watts | I won't promise soon. | 09:44.59 |
| cryptopsy | 1 month? | 09:45.14 |
| Robin_Watts | I certainly won't promise that soon. | 09:45.28 |
| cryptopsy | what are line art images? | 09:45.36 |
| Robin_Watts | vector images, as opposed to bitmaps. | 09:45.59 |
| cryptopsy | thanks | 09:46.35 |
| | I have very many pdfs, do you want me to make tests for you? | 09:47.11 |
| Robin_Watts | cryptopsy: At the moment it's very dumb - we know it needs lots more work. | 09:48.00 |
| | I'd hate for you to put in time testing it only for me to say "yeah, we know that's broken". | 09:48.33 |
| cryptopsy | i can just convert the images to bitmap before using mudraw right? | 09:48.42 |
| Robin_Watts | can you? | 09:50.54 |
| cryptopsy | i don't know how hard it is to do that, not familair with pdf | 09:51.08 |
| Robin_Watts | I wouldn't know how to do it in general. You might be able to depending on where the pdf is coming from. | 09:51.41 |
| tor8 | Robin_Watts: doing mesh plotting with floats definitely solves the missing pixels. now I just need to figure out all the bugs or maybe make the edge finding logic more robust | 09:58.02 |
| | but it definitely looks like it will solve the issue | 09:58.19 |
| | (or at least make it 100x better) | 09:59.05 |
| dpc | I have a question regarding MuPDF integration to my existing android application. I have followed all the steps and I can able to install the compiled MuPDF on emulator. Its working great. But the problem here is, I am unable to figure out on how to integrate MuPDF in my sample android application | 10:09.53 |
| | can someone please guide me on this | 10:10.16 |
| | thanks in advance | 10:10.19 |
| Robin_Watts | tor8: fab. | 10:10.33 |
| | dpc: hi | 10:10.44 |
| dpc | hi robin | 10:10.51 |
| Robin_Watts | If you have specific problems, we can try to help. | 10:11.11 |
| dpc | I am unable to figure out on how to integrate MuPDF in my sample app | 10:11.12 |
| | after getting the actual MuPDF application working on emulator. What all files like libraries I need to take and place it in my application? | 10:12.00 |
| Robin_Watts | dpc: All the files in mupdf are required for mupdf to work :) | 10:12.30 |
| dpc | I want to launch MuPDF from my sample activity by passing pdf content path. How can I do it? | 10:13.21 |
| Robin_Watts | The mupdf sources break down into android and non-android ones. | 10:13.31 |
| dpc | ok | 10:13.40 |
| | i see there is android folder inside mupdf sources | 10:13.55 |
| Robin_Watts | The non-android ones are built together with android/jni/mupdf.c into libmupdf.so | 10:13.56 |
| dpc | ok | 10:14.05 |
| Robin_Watts | All the other files in the android directory are the java sources. | 10:14.12 |
| dpc | thats right | 10:14.18 |
| Robin_Watts | The public API for the mupdf library is a C level interface. | 10:14.42 |
| | as such android/jni/mupdf.c exposes a small subset of that API to the java - specifically just enough to do what we need to in our example android viewer. | 10:15.23 |
| | If you want to use more features than our viewer does, you will need to expand mupdf.c | 10:15.39 |
| | If on the other hand, you are happy with the features of the viewer, and you just want to drive it as is, you can probably get away with working at the java level and ignore the C entirely. | 10:16.09 |
| dpc | are you referring android folder inside mupdf sources as "example android viewer"? | 10:16.13 |
| Robin_Watts | Yes. | 10:16.24 |
| dpc | Ok, so from my SampleActivity.java, how can I launch MuPDFACtivty? | 10:17.12 |
| Robin_Watts | You wouldn't. | 10:17.44 |
| dpc | I know its through Intent but what all should i need to place in my sample app | 10:17.45 |
| Robin_Watts | AIUI, you use Intent to open files with other apps. | 10:18.31 |
| | To open a file within the same app, you wouldn't use Intent (or at least you wouldn't have to use Intent), you'd just call direct. | 10:19.10 |
| | MuPDFActivity implements an Android Activity. So, presumably, would SampleActivity.java | 10:19.42 |
| dpc | So, please tell me, if i have button in my sample app and on clicking this button i want to launch a pdf file using MuPDF | 10:20.14 |
| | yes my sampleactivity is extends from android Activity | 10:20.31 |
| Robin_Watts | actually, ignore what I just said about Activities. | 10:20.36 |
| | If you look in android/src/com/artifex/mupdfdemo/ChoosePDFActivity.java you should see what you need. | 10:20.59 |
| | That class displays a list of files on the memory card, lets you pick one, and then calls out to MuPDFActivity to actually display one. | 10:21.28 |
| | It seems to me that what you want to do should be in there somewhere. | 10:21.43 |
| dpc | thats right robin | 10:22.19 |
| Robin_Watts | and in fact, I'm wrong. | 10:22.20 |
| | That does use Intent. | 10:22.27 |
| | so my apologies. | 10:22.30 |
| dpc | yeap | 10:22.34 |
| | Intent intent = new Intent(this,MuPDFActivity.class); intent.setAction(Intent.ACTION_VIEW); intent.setData(uri); startActivity(intent); | 10:22.35 |
| | like this | 10:22.39 |
| Robin_Watts | So that sounds like what you need. | 10:22.48 |
| dpc | inorder to work this perfectly, do i had to install MuPDF on the phone?? | 10:23.10 |
| Robin_Watts | If you include MuPDFActivity.class (and all the other classes, and the lib etc) as part of your app, then no, it can all be as one. | 10:23.53 |
| dpc | yeah here is my problem Robin | 10:24.12 |
| | what all classes and what all libs | 10:24.19 |
| | to include in my app | 10:24.23 |
| | please help me at this point | 10:24.30 |
| Robin_Watts | all the classes and libmupdf.so | 10:24.33 |
| dpc | all the classes in the sense "*.java" files, right? | 10:25.06 |
| Robin_Watts | actually, all the classes except for ChoosePDFActivity.class, I would guess. | 10:25.10 |
| | dpc: You've built normal mupdf, right? | 10:25.21 |
| dpc | yes, i built it | 10:25.30 |
| Robin_Watts | Right, so every .java file will correspond to at least one .class file that's been built in the tree somewhere, and is included in the final mupdf.apk | 10:26.00 |
| | Either you need to move the mupdf sources over into you app and get them built at the same time... | 10:26.21 |
| | or you need to copy the final classes across from the tree/apk and include them. | 10:26.45 |
| | honestly, I have no idea which is simpler. | 10:27.18 |
| | I'd personally go for the first, I think. | 10:27.23 |
| dpc | ok......and when i built ChoosePDF app then it generated two libmupdf.so files, one under /libs/armeabi and another under /libs/armeabi-v7a which one should i need to use in my sample app? | 10:27.36 |
| Robin_Watts | dpc: Some phones are based on arm-v7 chips. | 10:28.04 |
| | some older ones are based on earlier versions. | 10:28.11 |
| | For the older ones you will need armeabi. | 10:28.19 |
| | armeabi will work on the later ones too (I believe), but it will be slower as FP is done in software. | 10:28.38 |
| dpc | ok, for safety i will also create such folders under my libs folder and place both | 10:28.40 |
| Robin_Watts | right. | 10:28.45 |
| dpc | do i need to also copy gdb.setup and gdbserver files? | 10:29.13 |
| Robin_Watts | What app are you developing, if I may ask? | 10:29.16 |
| | dpc: Those are created as part of the build process by android. | 10:29.28 |
| | s/android/the android sdk/ | 10:29.46 |
| dpc | idea is to pass a pdf file to my app and try to read pdf from within my app | 10:29.50 |
| | so i came across about MuPDF | 10:29.58 |
| Robin_Watts | right, but is this app for distribution at any point ? | 10:30.20 |
| dpc | i have also read the two types of licensing | 10:30.38 |
| | depends on our requirement , we will definitely approach Artifex | 10:30.55 |
| Robin_Watts | Ok, just wanted to make sure you'd seen that before you spent hours working on something :) | 10:31.13 |
| dpc | till then i wanted to see whether pdf reading is possible or not | 10:31.16 |
| | ok | 10:31.33 |
| | so after placing all the required sources (.java) files and libmupdf.so files in my sample app. the normal build from eclipse is fine to make my app working, right? | 10:33.13 |
| Robin_Watts | No idea. I don't use eclipse. | 10:33.58 |
| dpc | ok.. I will try and if something goes bad then i will come here again | 10:34.21 |
| Robin_Watts | but paulgardiner does, so certainly eclipse is capable of building it. | 10:34.28 |
| dpc | many many thanks robin | 10:34.35 |
| Robin_Watts | best of luck! | 10:34.37 |
| dpc | thank u | 10:34.45 |
| | have a great day | 10:34.49 |
| Robin_Watts | "Chrome has auto-updated with bettar spell chek!" hehe | 10:46.03 |
| Robin_Watts | is easily amused. | 10:47.15 |
| chrisl | Robin_Watts: does it also have a grimmer chalker? | 10:47.19 |
| Robin_Watts | :) | 10:47.34 |
| | Google Chrome: Allo Allo edition. | 10:47.58 |
| chrisl | :-) | 10:48.25 |
| paulgardiner | No mvrhel today? | 10:50.05 |
| Robin_Watts | paulgardiner: Not this early :) | 10:50.31 |
| paulgardiner | Ah of course. Silly m | 10:50.42 |
| | me even | 10:50.46 |
| Robin_Watts | you get used to it. When we had Masaki working with us, the sun never set on Artifex :) | 10:52.46 |
| paulgardiner | Looking at his proposal, it is actually very similar to what the customer is doing, with the proposed separate project taking the place of the customer's x.dll | 10:53.32 |
| Robin_Watts | paulgardiner: Depending on how much 'extra' the customer wants to put into x.dll | 10:54.14 |
| | if x.dll is intended to be a simple thin wrapper, then yes, you're absolutely right, the two are the same. | 10:54.45 |
| paulgardiner | Yes, but it presumably it has exactly the same use of linking so solving one solves the other | 10:55.00 |
| Robin_Watts | you'd hope so, yes. | 10:55.45 |
| paulgardiner | I'm wondering if Michael was proposing gs.dll being a win32 dll and linking via the .lib file. | 10:56.47 |
| | Reading Raed's latest reply I'm less sure what x.dll is. It may be something he created just to test calling gs in that environment. He says the app is *empty*. | 10:59.42 |
| | What's the simplest interaction I could make with gs to confirm successful calling? | 11:02.56 |
| kens | 'showpage' ? | 11:03.25 |
| | produces an empty page of output | 11:03.51 |
| Robin_Watts | kens: no, i think paul means calling a dll. | 11:03.56 |
| | calling the gswin32 dll | 11:04.06 |
| kens | yes, so feed it 'showpage' as a piece of PostScript | 11:04.24 |
| | If that works, its working | 11:04.39 |
| | other than that you;d be relying on error returns | 11:04.48 |
| Robin_Watts | paulgardiner: see gs/doc/API.htm | 11:04.57 |
| paulgardiner | No setup needed before doing that? | 11:05.01 |
| kens | paulgardiner : yes, lots | 11:05.12 |
| Robin_Watts | paulgardiner: So you need to link to the dll, call gsapi_new_instance etc. The docs are in the file I just pointed you at. | 11:05.46 |
| paulgardiner | I was hoping there might be some utility functions not attached to the main code that I could just call without init. | 11:05.48 |
| Robin_Watts | paulgardiner: gsapi_revision ? | 11:06.22 |
| paulgardiner | Sounds good. | 11:06.32 |
| Robin_Watts | psi/dwdll.c loads the dll and gets the function pointers. | 11:08.25 |
| paulgardiner | Eek! Does it do so using APIs that are available to Windows Store apps? | 11:15.23 |
| Robin_Watts | paulgardiner: gs has a publicly defined api for people to call it programattically. | 11:17.24 |
| | That is defined in the iapi.h header. | 11:17.35 |
| | The DLL exposes that interface. | 11:17.43 |
| | If you build a lib, then the expectation is that you'll be calling that same interface (although you may well see all the other functions too - don't think we ever hide stuff). | 11:18.20 |
| paulgardiner | Confused! You said dwdll.c *loads* the dll. | 11:18.45 |
| Robin_Watts | So, presumably, if mvrhel (or you, or whoever) wanted to do a winrt wrapper, it would be that same interface you'd expose. | 11:19.00 |
| | dwdll.c is a .c file that implements load_dll and unload_dll | 11:19.33 |
| | I believe it's used as part of gswin32c.exe (and gswin32.exe) our standard ghostscript exes on win32. | 11:20.02 |
| | Those take the form of small exes, which use the dll. | 11:20.13 |
| paulgardiner | Ok, not anything that would be used in winrt | 11:20.26 |
| Robin_Watts | no, not currently. | 11:20.34 |
| | but I mentioned the code in the hopes it might save you having to look up how to load a dll etc ( certainly I don't carry such information in my head). | 11:21.02 |
| paulgardiner | Oh ok I understand. I don't think we have those same mechanims to load dlls available in WinRT, at least Raed looks to be claiming so. | 11:25.12 |
| Robin_Watts | paulgardiner: Ah, fair enough. | 11:25.39 |
| | tor8: ping | 11:25.44 |
| | paulgardiner: It's a long time since I did this, so my memory is crapper even than usual, but my tests on metro were to see if I could call the standard gswin32 from the metro side. | 11:26.59 |
| | and that would have done the dll loading using that very code. | 11:27.09 |
| | so either I'm misremembering, or Raed is wrong, or it was dropping back to the desktop and I wasn't spotting it. | 11:27.31 |
| paulgardiner | Oh right. Interesting | 11:29.26 |
| tor8 | Robin_Watts: yes? | 11:33.25 |
| Robin_Watts | tor8: Fix for transitions on my repo. | 11:33.57 |
| tor8 | Robin_Watts: cool. that one looks like it ought to work :) | 11:35.29 |
| | Robin_Watts: let me just check the rest on your branch | 11:35.36 |
| | ow. seeing you use printf for put32 hurts :) | 11:37.20 |
| | but considering how little it's used that's okay | 11:37.50 |
| | s/fz_text_device_images/fz_set_device_hints/ maybe? | 11:38.45 |
| Robin_Watts | ah, yes, nice. | 11:39.06 |
| tor8 | make it a bit more general | 11:39.20 |
| | and good catch on the device list not respecting hints | 11:39.32 |
| | fz_new_output_buffer could maybe be called fz_new_output_with_buffer ? | 11:41.34 |
| Robin_Watts | on phone, sorry. | 11:42.03 |
| tor8 | s/fabs/fabsf/ | 11:42.59 |
| Robin_Watts | tor8: back, sorry. | 11:54.59 |
| | Yes, I will attempt to generalise fz_text_device_images. I wasn't entirely happy with it. | 11:55.29 |
| | Are we happy to have a single 'fz_device_set_hints' function that works for all device types? | 11:55.52 |
| | I guess we are, as the hints are in all devices. | 11:56.10 |
| tor8 | yes. | 11:56.57 |
| Robin_Watts | fz_new_output_buffer has been in the code for ages - I just added the header for it. | 11:57.12 |
| tor8 | maybe a enable/disable hint pair of functions instead, to override the default hints a device sets | 11:57.13 |
| | Robin_Watts: I know, I just thought it looked like it could use a rename now | 11:57.31 |
| Robin_Watts | and if we change fz_new_output_buffer we should also change fz_new_output_file | 11:57.37 |
| | fz_new_output_to_buffer ? | 11:57.44 |
| tor8 | yes | 11:57.44 |
| Robin_Watts | to, rather than with ? | 11:57.49 |
| tor8 | _to_buffer or _with_buffer, no strong preference | 11:57.57 |
| | lots of functions already have _with_ | 11:58.05 |
| | new_pixmap_with_data etc | 11:58.11 |
| Robin_Watts | hmm. trying to figure out why I like new_pixmap_with_data, but new_output_to_buffer | 11:58.55 |
| | I'll do with for consistency. | 11:59.33 |
| | So issues to address: | 12:00.00 |
| | 1) fabsf | 12:00.04 |
| | 2) hint set/unset functions | 12:00.13 |
| | 3) rename fz_new_output_buffer etc. | 12:00.25 |
| | anything else? | 12:00.41 |
| tor8 | I have not reviewed the multi-threaded segv | 12:01.16 |
| Robin_Watts | ok. That's actually not that bad. | 12:01.37 |
| tor8 | fix 1, 2 and 3 and I am happy with the other patches up to but not including limit mesh patch | 12:01.45 |
| | it said multi-threaded and I'm supposed to be focusing on the mesh rendering! :) | 12:02.04 |
| Robin_Watts | right. limit mesh patch isn't to go in yet. | 12:02.08 |
| | tor8: right, but the customer is waiting for that one :) | 12:02.19 |
| tor8 | get paul or sebras to look at it! :) | 12:02.34 |
| Robin_Watts | (indeed the limit mesh patch thing may never go in) | 12:02.38 |
| | tor8: ok :) | 12:02.50 |
| | I'm being called for lunch. I'll fix/push etc afterwards. Thanks. | 12:03.09 |
| tor8 | and next meeting, we should bring up CSP-ifying the multi-threaded architecture so all this lock dancing can be simplified | 12:04.15 |
| Robin_Watts | tor8: I'm not sure I see how CSP can help us. | 12:07.13 |
| | We can write a CSP spec for what we're doing, and thus prove it correct. | 12:07.27 |
| | but CSP doesn't magically allow us to simplify the code, AIUI. | 12:08.08 |
| | Certainly it doesn't remove the need for locking etc. | 12:08.19 |
| | sebras, paulgardiner: IF either of you could cast your eye over http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=fb661ffd2e9433305a4cbfb916b47eed16c71a55 I'd be grateful. | 12:19.23 |
| tor8 | Robin_Watts: it'd help if the only mechanisms we use are channels and processes, and we'd put the store on its own thread (real or coroutine-based) and never share any mutable data between processes | 12:25.24 |
| Robin_Watts | tor8: Having the store in it's own process with a channel to talk to it is equivalent to having the store protected by its own lock. | 12:27.06 |
| sebras | Robin_Watts: I'll have a look at it tonight. | 12:27.27 |
| tor8 | Robin_Watts: exactly, but it's easier to express and understand in the code IM(A)O | 12:27.29 |
| Robin_Watts | Right, but it has the same lock ordering problems (or equivalent deadlock states if you prefer) as the current solution does. | 12:28.15 |
| tor8 | yes, not saying it's a magic silver bullet. but it should make it easier to think about. | 12:29.01 |
| | and it would let us do automatic multi-threading from a single-threaded user API as well, I would imagine | 12:29.30 |
| | and if you don't want multi-threading (and to detect definite deadlocks) just run them on coroutines instead of real threads | 12:30.09 |
| Robin_Watts | tor8: fabsf: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=675ffc82cc3305038d0823089f6094cfef86cbe1 | 13:34.20 |
| tor8 | Robin_Watts: *nod* | 13:34.33 |
| Robin_Watts | hint enable disable: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=f900105749889d6af78e9721e42210afb246c2cf | 13:34.39 |
| sebras | /whois fabsf | 13:34.49 |
| Robin_Watts | renaming: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=0f57a46e0fdb2a57b79fecfb4ba8252099902c83 | 13:35.08 |
| tor8 | so you went with _with_ after all? | 13:35.51 |
| Robin_Watts | consistency wins. | 13:36.00 |
| tor8 | question is, fz_enable_device_hint or fz_device_enabe_hint | 13:36.10 |
| Robin_Watts | I can't come up with a strong argument to back up my gut feeling for prefering 'to' to 'with', so I went with with. | 13:36.37 |
| | Ah. The former is probably more consistent with the scheme we use in mupdf (that I don't like). | 13:37.16 |
| | so I should change to fz_enable_device_hints | 13:37.35 |
| | hint or hints? | 13:37.49 |
| tor8 | I'd go with singular | 13:38.05 |
| Robin_Watts | We can supply the OR of multiple hints at once, hence hints would be my vote. | 13:38.07 |
| tor8 | but since it's a mask, what you said | 13:38.17 |
| | so I'd consider it a wash | 13:38.22 |
| Robin_Watts | ok. I'll change that again. | 13:38.35 |
| tor8 | plural makes it more obvious that it's a bit mask | 13:38.43 |
| | otoh, singular allows us to change the representation should the need arise | 13:39.04 |
| | in case we run out of bits for hints in the hint mask down the line (not very likely, IOW) | 13:39.20 |
| Robin_Watts | I'll do it as hints, and document it as a mask. If we need to change it in future, we can implement a _hint version | 13:41.59 |
| | and remove _hints and that way no one can accidently have code that carries over the wrong meaning. | 13:42.20 |
| tor8 | sounds good | 13:42.32 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=c06007db0978041d6b60125929d0ca412f36e18e | 13:45.04 |
| | All pushed then. (paulgardiner reviewed the multithreaded one for me) | 13:50.36 |
| | So, we have a potential customer for mupdf that has the android app set up doing automatic page turns to give a continuous rolling display. | 13:51.18 |
| | and they are complaining that we have a memory leak. | 13:51.31 |
| | so I'm going to have a look at that next. | 13:51.38 |
| chrisl | kens: ping | 14:24.51 |
| kens | pong 2 secs | 14:25.00 |
| chrisl | kens: do pdfwrite/ps2write always use gdev_vector_open_file_options() for the main output file? | 14:25.52 |
| kens | I have absolutely no idea ;-) | 14:26.11 |
| chrisl | Okay - it's just it tries to open the file seekable, and if that fails, it tries again non-seekable, in which case I should close the FILE * object before returning the error code | 14:27.28 |
| kens | OK seems reasonable to em | 14:27.56 |
| chrisl | I guess I'll give it a try, and see if it goes bang :-) | 14:28.16 |
| kens | THe answer is 'yes' though | 14:28.21 |
| | via 3 levels of #define indirection..... | 14:28.35 |
| chrisl | Naturally ;-) I'm glad I checked..... | 14:28.53 |
| tor8 | Robin_Watts: two patches on tor/master. the formatting one should be good to go, the other one is not finished yet but if you could give it a spin and see if it solves the shading issues well enough to polish up and optimise. | 15:21.00 |
| | the edges of highly tesselated shadings are definitely improved with the patch, so I think it's worthwhile whether it fixes all the missing pixels or not | 15:22.00 |
| | I can still get the occasional white pixel but it's a lot rarer now | 15:22.11 |
| Robin_Watts | tor8: Will do. | 15:24.11 |
| tor8 | something I found a bit odd that I discovered doing this, the mesh data has the float color values premultiplied by 255... | 15:25.25 |
| Robin_Watts | All the vertex stuff? Yes. | 15:31.17 |
| | That means that the *255 only has to happen at once at the top of the subdivision code, rather than on every final triangle? | 15:32.53 |
| | but that's a tiny win given the float -> int conversion that happens there. | 15:33.07 |
| tor8 | yeah. it'd make more sense to have it normalized for eventual high level output devices that get hold of the mesh data. | 15:33.32 |
| Robin_Watts | formatting patch looks fine. | 15:34.07 |
| tor8 | and converting the float to fixed point can trivially embed that *255 constant factor once we turn that floating point scan converter into fixed point | 15:34.13 |
| | thanks! | 15:34.33 |
| | I gotta go, dinner calls. | 15:34.37 |
| Robin_Watts | tor8: The scan converter seems sane too. I'm in the middle of trying to debug a customer thing, so I won't try it immediately though. | 15:39.26 |
| kens | goodnight folks | 16:11.59 |
| ray_laptop | mvrhel_laptop: Can you please handle customer 801's question #26 ? | 16:19.46 |
| mvrhel_laptop | ray_laptop: reading it now. Do they not set there device's capabilities someplace? | 16:22.59 |
| | s/there/their/ | 16:23.06 |
| | I would think they would need to do that and not have the default settings (e.g. like tiffsep) | 16:23.45 |
| ray_laptop | mvrhel_laptop: I thought that the problem was probably that they didn't set their device properly and just used our default max_components | 16:26.09 |
| mvrhel_laptop | right that is what I mean | 16:27.02 |
| ray_laptop | mvrhel_laptop: but I am not familiar with which, of the myriad, macros were best to set up their kind of device | 16:27.04 |
| mvrhel_laptop | and I am.... ;) | 16:27.44 |
| ray_laptop | mvrhel_laptop: I also don't know what might be required as far as SeparationNames or SeparationOrder may be needed to let them tell the interpreter what the name of the Spot color is | 16:28.59 |
| | mvrhel_laptop: well, you've mucked about with DeviceN type devices more than I | 16:29.30 |
| mvrhel_laptop | ray_laptop: I know. I will dig into this | 16:29.59 |
| ray_laptop | mvrhel_laptop: I'm not sure that they mentioned that their device had spot color support previously. Did you know this ? | 16:30.26 |
| mvrhel_laptop | ray_laptop: no this is news to me | 16:30.40 |
| ray_laptop | I was thinking about throwing the BGPrint stuff to them, but since I still have some psdcmyk diffs I can't :-( | 16:32.08 |
| | Robin_Watts: my last bmpcmp had a lot of psdcmyk pages where it said "bmpcmp: Page 1: Can't compare images (w=2479,2479) (h=3300,3300) (s=12396,9916) (bpp=40,32) (cmyk=1,1)!" | 16:41.39 |
| Robin_Watts | right. | 16:41.53 |
| | That's because the number of bits per pixel has changed from 40 to 32. | 16:42.09 |
| ray_laptop | but when I run on my machine I get the identical files | 16:42.29 |
| Robin_Watts | Look in the logs, find the exact command line and try that ? | 16:43.07 |
| | identical files how? | 16:43.15 |
| | visually? | 16:43.20 |
| | or to 'diff' ? | 16:43.28 |
| ray_laptop | Robin_Watts: identical as in size and compared with 'cmp' | 16:44.22 |
| Robin_Watts | well, the cluster must be having a different experience to you then. | 16:45.18 |
| mvrhel_laptop | are you sure the bpp are the same? | 16:51.29 |
| Robin_Watts | bmpcmp is reporting 5 components, rather than 4 (cos bmpcmp uses 8 bits per pixel, always). | 16:52.16 |
| | psdcmyk packs things planarly, right ? | 16:52.41 |
| ray_laptop | mvrhel_laptop: Robin_Watts: the file I am running is the first one on the bmpcmp list tests/Ghent_V3.0/051_Font_report.pdf.psdcmyk.300.1 | 16:53.16 |
| | let me look how many components I am seeing on my machine... | 16:53.45 |
| | I'm getting 5 channels (byte 14 == 5) which means I get 40 bits | 16:56.32 |
| | plus my file size is consistent with 5 planes of 2479x3300. I guess I have to try on peeves. Thanks | 16:58.07 |
| Robin_Watts | ray_laptop: You've confirmed that the old version was giving you 5 planes too ? | 17:08.25 |
| ray_laptop | Robin_Watts: I was only looking at the first page because the bmpcmp reported Page 1 through page 4. Turns out there were 5 pages and page 1 _is_ 5 planes on both, but pages 2 thru 4 are only 32 bit without BGPrint | 17:09.28 |
| Robin_Watts | Ah. | 17:09.48 |
| ray_laptop | and with BGPrint=true pages 2 through 4 are 40 bit | 17:10.06 |
| | OK. now I can work on it. (I didn't know that Page 1 meant the second page) | 17:10.33 |
| Robin_Watts | oh, urm, does it? :( | 17:11.36 |
| mvrhel_laptop | My son just read a book about Fibonacci that had a chapter 0 | 17:13.42 |
| | bbiab | 17:13.52 |
| ray_laptop | ahh... I think I see it. The 'psd_print_page' function frees the separation names and sets the num_separations to 0 after printing a page in the 'psdd_print_page'. In BGPrint mode, that doesn't get done on the foreground device at all | 17:24.46 |
| | just read paulgardiner's email on the Win 8 issues. Yuck! There have to be suitable functions for our gp_monitor, gp_semaphore and gp_*_thread. Might be easiest to use a different gp module instead of gp_wsync.c | 17:42.44 |
| Robin_Watts | ray_laptop: Do we have a gp_nosync.c or something? | 17:43.28 |
| | something to get us up and running without NumRenderThreads working for now ? | 17:43.44 |
| ray_laptop | and we might need that for the file functions as well (an alternate for gp_mswin.c) | 17:43.49 |
| | Robin_Watts: yes, there is a gp_nsync.c | 17:44.10 |
| Robin_Watts | ray_laptop: Yes. Talking to paulgardiner earlier, he was saying that Windows 8 might be funny about syncronous file handling. | 17:44.42 |
| | certainly they seem to want apps never to block on file handling, but whether that means they don't support sync file handling, or they just frown upon it's use is unclear (to me at least) | 17:45.33 |
| ray_laptop | Robin_Watts: well, the RTL _has_ to block on file I/O, right. how would 'fread' work otherwise ? | 17:46.46 |
| paulgardiner | ray_laptop: I think we may be lucky with the functions I singled out. InitializeCriticalSectionEx exists according to documentation. | 17:46.50 |
| | So I expect CreateSemaphoreEx and WaitForSingleObjectEx do too. | 17:47.36 |
| ray_laptop | paulgardiner: OK. We can either have conditional compile in gp_wsync.c or just add a gp_w8sync.c | 17:47.45 |
| Robin_Watts | ray_laptop: Right. That was my argument. But then arguments of the form "Surely not even Microsoft could do XXXX" do not historically have a great success rate. | 17:47.45 |
| ray_laptop | Robin_Watts: what do yo do -- just see how many bytes fread returns and loop until you get enough ??? | 17:48.27 |
| | Surely not even Microsoft could want you to do that ??? (maybe Intel to sell more CPU's) | 17:49.09 |
| | ;-) | 17:49.23 |
| Robin_Watts | ray_laptop: 99.9% of uses of fread assume that either it will read all of it, or we hit the end of file. So yes, it would seem utterly mad for ms to break that. but this is ms. | 17:49.39 |
| paulgardiner | It may well be that they merely frown upon its use. | 17:50.57 |
| ray_laptop | I'm surprised MS hasn't decided to go back to their roots and go to a loop that cycles through all the tasks | 17:51.23 |
| | this pre-emptive task switching is some idea that really doesn't belong in MS since it really belongs in unix ;-) | 17:52.23 |
| Robin_Watts | Multi-tasking ("Time sharing") predates unix. | 17:55.22 |
| ray_laptop | I think I see what's up with the cups device, too. cups_print_pages bumps a cups->page element, so of course the foreground cups device never learns about it. | 17:55.50 |
| Robin_Watts | Was invented by Christopher Strachey (first Professor of Computing at the PRG) | 17:56.00 |
| ray_laptop | yeah, but if Bill Gates didn't think it was a good idea in Windows 1, it must be evil. | 17:57.53 |
| | so devices that change private device structure values after printing a page won't work in BGPrint mode without modification :-( | 18:07.10 |
| | I guess this means we need to know which devices are capable of BG printing, and only do it for them. And default all devices that we haven't specifically reviewed as OK to 'cannotBGPrint' | 18:09.31 |
| | since so many devices are safe, I hate to have to add a spec_op to all of them. Robin_Watts (et al.) does this sound like we can do it with a prn_device struct element ? | 18:11.45 |
| Robin_Watts | Either way should work, I guess. | 18:17.42 |
| ray_laptop | hmm... Since the BGPrint is actually done in the device's 'output_page' (which defaults to gdev_prin_output_page) we can probably just hook that to a _with_BGPrint version for devices that can handle it. | 18:30.57 |
| | and devices (like cups) that want special handling can have their own output_page that calls gdev_prn_bg_print_output_page and does any special handling before or after. How's that sound | 18:32.27 |
| | ? | 18:32.44 |
| | names a little long, so maybe gdev_prn_bg_output_page | 18:34.41 |
| | hi, henrys | 18:40.03 |
| henrys | ray_laptop:I'm at your stomping grounds in st louis. | 18:40.31 |
| ray_laptop | henrys: where in St. Louis -- if it's downtown I didn't get there too much | 18:41.07 |
| henrys | I'm at the first robotics championship where the st louis rams play. | 18:41.46 |
| ray_laptop | I grew up in North county, pretty near the river (we used to walk down to the river and play on the banks) | 18:41.48 |
| henrys | edward jones dome. | 18:42.02 |
| ray_laptop | henrys: Busch Stadium is right downtown | 18:42.14 |
| | they probably renamed it since | 18:42.28 |
| | if it's where they used to play its in view of the Arch | 18:42.51 |
| | but maybe they built a new dome (Busch stadium didn't have a dome) | 18:43.45 |
| henrys | the old cardinals stadium is still here, drove right by it, not far from where I am. | 18:44.25 |
| ray_laptop | henrys: yeah -- I just pulled up a sat map on google. It's a new dome, then | 18:45.48 |
| | still not far from the Arch | 18:46.14 |
| henrys | my nephew's team is not ranked 23 out of 100 in his division, this is really something it's like a sporting event. | 18:46.23 |
| ray_laptop | henrys: I bet. So this is nationals ? | 18:46.40 |
| henrys | s/not/now | 18:46.44 |
| | worlds | 18:46.54 |
| ray_laptop | coolio | 18:47.02 |
| | what age group ? high school ? college ? | 18:47.39 |
| Robin_Watts | hold on, this is the US "worlds", right? Do you actually invite other nations to play? :) | 18:48.12 |
| ray_laptop | Robin_Watts: you mean like baseball's "world series" ? | 18:48.34 |
| henrys | there are other countries here for sure | 18:48.38 |
| Robin_Watts | ray_laptop: precisely :) | 18:48.42 |
| henrys | oh right ha ha | 18:48.49 |
| Robin_Watts | henrys: Take pictures! | 18:49.09 |
| ray_laptop | well St. Louis is the center, right ? (of the world ;-) ) | 18:49.37 |
| henrys | Robin_Watts: will do | 18:49.49 |
| | right half the world is west of st louis other half east | 18:50.15 |
| Robin_Watts | ray_laptop: I think, technically speaking, it depends on the projection you use. | 18:50.16 |
| ray_laptop | henrys: lots of teams over from Asia ? | 18:50.18 |
| henrys | lots from israel turkey and germany based on waving flags but that may not be the best indicator | 18:51.22 |
| ray_laptop | henrys: what age group ? high school ? college ? | 18:53.00 |
| | i.e. which division is your nephew in ? | 18:53.54 |
| henrys | my nephew is high school - live feed here science.ksc.nasa.gov/robotics/ for windows | 18:54.00 |
| | he's in newton | 18:54.10 |
| ray_laptop | henrys: apparently there is also a 'Vex Robotics High School World Championship that just happened here in Anaheim (April 17-20) | 18:56.30 |
| | so you are at the FTC World Championship | 18:57.06 |
| henrys | yes but there is other stuff for elementary and middle school also. | 18:57.34 |
| Robin_Watts | All I'm seeing is Xerox adverts. | 18:58.10 |
| ray_laptop | henrys: I see "Edison" division and "Franklin" division on the web site | 18:58.12 |
| | at http://www.usfirst.org/roboticsprograms/ftc/FTCWorldChampionship | 18:58.25 |
| Robin_Watts | I can hear the cantina music from star wars in the background. | 18:58.32 |
| | http://science.ksc.nasa.gov/robotics/ | 18:58.46 |
| henrys | I think you have to sit through some commercials first | 18:59.45 |
| ray_laptop | Robin_Watts: yeah, I just found that. Streaming site, and they mention "newton" | 19:00.03 |
| henrys | I'm watching live from here | 19:00.06 |
| Robin_Watts | I think you get adverts between bouts. | 19:00.20 |
| ray_laptop | I didn't get any commercials | 19:00.32 |
| henrys | my nephew's team robot is 68 | 19:01.20 |
| | they play again in an hour | 19:01.29 |
| ray_laptop | OK, now I got the BAE ad | 19:03.27 |
| | I'll tune back in so I can cheer him on :-) | 19:04.04 |
| henrys | ray_laptop:I wish my school had a program like this for my kids. These kids are *really* excited about this. | 19:04.31 |
| ray_laptop | both middle schools have robotics clubs and the high school competes. My son may want to join it. If so, I'll volunteer as an advisor since I've know most of the basics (electronics, servo control, image analysis) | 19:06.34 |
| | the accuracy of those frisbee shooters is incredible | 19:10.51 |
| henrys | 68 is very fast and a very good shooter but other teams have gotten the hang of defending against him, we were ranked 13 yesterday and sunk 10 places today. | 19:14.00 |
| | I'm definitely in geek land though. I could probably interview a few kids while I'm here. | 19:18.10 |
| ray_laptop | mvrhel_laptop: did you check out the robotics contest video? | 19:18.16 |
| | mvrhel_laptop: BTW, I found out what's up with the psdcmyk -- the print_page is where the separations get reset, but I wasn't doing that for the foreground device | 19:19.12 |
| henrys | got to go back to the arena area bbiaw | 19:19.36 |
| Robin_Watts | ray_laptop: Should we separate print_page into 2? | 19:19.59 |
| ray_laptop | so if the device returns a devn_params pointer, I can do that before the foreground return | 19:20.06 |
| | Robin_Watts: no, I think just exporting the gdev_prn_bg_output_page suffices. A device can hook the proc, do A before, call the standard function, then do B after it returns. | 19:21.18 |
| Robin_Watts | ray_laptop: I don't entirely follow that. | 19:21.52 |
| | oh, I follow, I think. | 19:22.57 |
| mvrhel_laptop | oh henrys is at the robot contest | 19:23.05 |
| ray_laptop | Robin_Watts: if a device has some action A that needs to be done before the standard output_page, and similarly action B after the standard output_page | 19:23.06 |
| Robin_Watts | I was thinking of something a bit different, which may be silly. | 19:23.29 |
| ray_laptop | so, for example, the cups device would increment the cups->page value there as its action B | 19:24.00 |
| Robin_Watts | ray_laptop: Right. I was thinking that we might have one entry point which conceptually could be split into 2 things; things to do in the foreground, and things to do in the background. | 19:25.03 |
| | and we could use the presence of the 'split' functions to mean "can safely bgprint". | 19:25.38 |
| ray_laptop | the 'tiff_output_page' really should be re-done to do the 'open_positionable' before, then just call the standard if gp_seekable returns true, rather than duplicate all the code | 19:25.58 |
| | as I mentioned before, duplicated code really irks me. | 19:27.44 |
| | you fix one instance, not realizing that there are other places that do the same thing, so leave places unfixed. | 19:28.29 |
| Robin_Watts | ray_laptop: Yeah. Part of the mupdf multithreaded store fix I did earlier involved pulling some duplicated code together, so it got tidied as a side effect. | 19:29.22 |
| ray_laptop | Robin_Watts: nice! | 19:29.55 |
| | well, I better get back to work... | 19:30.25 |
| | and finish all this BGPrint cleanup. | 19:30.39 |
| Robin_Watts | The android mupdf stuff does indeed leak like a leaky thing. | 19:32.47 |
| mvrhel_laptop | off to get a new battery for one of the cars. | 20:33.40 |
| | bbiaw | 20:33.41 |
| sebras | Robin_Watts: hm... there is still a SUBDIV in fz_process_mesh_type[67]()... | 20:57.31 |
| | Robin_Watts: I thought your idea was to make the subdivisions happen in device space so you would know how far to subdivide..? | 20:58.06 |
| Robin_Watts | sebras: The changes that I did to the mesh stuff was to make the subdivision happen at render time. | 23:14.29 |
| | Previously we subdivided and stored a list of triangles, which was huuuuge. | 23:14.49 |
| | As a next step we can think about varying the degree of subdivision at render time now. | 23:15.19 |
| | I have a commit that tries to do that in my repo. | 23:15.28 |
| | BUT... it works by deciding the subdivision level based on each patch, rather than the size of the mesh as a whole. | 23:15.54 |
| | which can introduce gaps. | 23:16.03 |
| | so we're not sure if we can use it yet. We'll know more when Tor8's reworks get finished. | 23:16.32 |
| | Forward 1 day (to 2013/04/27)>>> | |
IRC Logs