| <<<Back 1 day (to 2016/08/02) | 20160803 |
fredross-perry | sebras, robin - So now I am about 3/4 to having four inner classes inside StructuredText, TextBlock, TextLine, TextSpan, and TextChar. Each has a bbox and an array of the next thing down, except TextChar has its char (as an int). The JNI walks through the data and builds the whole thing up, under a single call to StructuredText.getBlocks(). Using default descriptors for everything. | 01:16.27 |
irctc239 | @robin watts : Hi | 09:11.16 |
irctc371 | Hello Everyone | 09:52.26 |
| My Self Hiren Patel | 09:52.55 |
| and i am .Net Developer | 09:53.05 |
Robin_Watts | Hi | 09:55.26 |
ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 09:55.26 |
Robin_Watts | We do not currently have wrappers for MuPDF in .net | 09:56.07 |
irctc371 | I am .Net developer and I got your Native Mupdf code but I need this functionality into .Net getting problem to build Jar or .Dll for .Net Any Suggestion? Thanks in Advance | 09:56.59 |
Robin_Watts | We are in the midst of projects to offer the standard MuPDF API in java (for desktop and android), and for javascript, but we have nothing planned for .net at the moment. | 09:57.21 |
irctc371 | https://github.com/asimmon/MuPDF-for-Xamarin-Android | 09:57.39 |
Robin_Watts | I am not hugely familiar with .net myself. | 09:57.43 |
irctc371 | asimmon create binding | 09:58.27 |
Robin_Watts | I don't see how that's a .net binding? | 09:58.43 |
irctc371 | and using that we can create .dll and can use in xamarin | 09:58.48 |
Robin_Watts | Ages ago, we wrote a simple viewer for Android that uses some ad-hoc JNI to work. | 09:59.39 |
| That viewer, although it works well, is not terribly easy for people to extend etc, because the JNI is tightly bound just to do the things that the viewer needs. | 10:00.19 |
| We are developing a replacement version that uses a much nicer version of the JNI, which will ultimately offer greater freedom for people to customise and tune the app. | 10:01.06 |
| That link look it's a hacked about version of that old app. | 10:01.42 |
| It says that it is "a port of the MuPDF Android library for Xamarin Android". | 10:02.02 |
| I don't see how that helps you on .net ? | 10:02.10 |
| Oh... You're targetting Android using .net ? | 10:02.37 |
irctc371 | in that binding one zip file there and it's contain classes .jar and resources using that we can build and getting .dll which is use in xamarin. | 10:03.28 |
| yes | 10:03.37 |
Robin_Watts | ok, so what is missing for you then ? | 10:04.05 |
irctc371 | i just build and compile the "viewer" project and get .aar and bundle and make zip and use in https://github.com/asimmon/MuPDF-for-Xamarin-Android | 10:07.46 |
| but getting error | 10:08.16 |
Robin_Watts | Right, so you're having problem with asimmon's work, rather than ours ? | 10:09.12 |
irctc371 | no no i just want .jar file of "viewer" project but i can't make .jar | 10:10.46 |
| "example" and "viewer" both project work perfectly | 10:11.50 |
| and build successfully | 10:12.06 |
Robin_Watts | viewer is the Android viewer. | 10:13.39 |
irctc371 | yes | 10:13.51 |
Robin_Watts | You mean you want a .jar, not a .apk? | 10:14.01 |
irctc371 | yes | 10:14.14 |
Robin_Watts | We have never done a release that builds a .jar | 10:14.28 |
| The current code from git will build a .jar with the new JNI/Java code in it, but not with the viewer code in it. | 10:15.57 |
| So it sounds like asimmon is relying on some make magic that we don't supply. | 10:16.22 |
| Under the terms of the AGPL he should be providing that, because it's part of the source code he's using. If he doesn't supply it, then he's in violation of the AGPL. | 10:16.53 |
| So I'd contact him. | 10:17.00 |
irctc239 | I think with use of your code asimmon just create .jar file and he convert that .jar file to .dll . It open I think | 10:18.14 |
Robin_Watts | irctc239: Right, but in order to create the .jar file he must have used a makefile, or an ant script or something. | 10:22.05 |
| Whether he wrote that himself, or he modified some of our code, that now becomes part of his source. | 10:22.37 |
| As such, he MUST supply that or he's in violation of the license, because people like you can't rebuild without it. | 10:23.04 |
irctc239 | That native code is already on Git and its open for all : https://github.com/asimmon/MuPDF-for-Android | 10:25.56 |
irctc371 | yes | 10:26.16 |
Robin_Watts | ok, so what's the problem? | 10:48.34 |
sebras | Robin_Watts: on sebras/wip, not sebras/master. I was confused. | 11:22.47 |
Robin_Watts | bah. Windows 10 upgrade has helpfully moved stuff so plink won't work. give me a mo. | 11:25.01 |
| ok, back in action, sorry. | 11:35.22 |
| horizontal, not horisontal. | 11:36.37 |
| Yes, looks good. | 11:36.41 |
| I wonder if we should have the flags setting separate from the device creation though. | 11:37.05 |
| as every time we add a new flag, it will change the API, and that's a bad thing. | 11:37.27 |
| Perhaps: fz_stext_device_expand_ligatures(dev, bool) or something ? | 11:37.59 |
| That way, it can default to doing exactly what it does now, but we still have control over it? | 11:38.16 |
| 2 possible alternatives to that. | 11:43.31 |
| 1) have an unsigned int flags word. then we don't have to change the API, we just add new bits. | 11:44.00 |
| This is frowned upon by tor, I believe. | 11:44.07 |
| 2) use more bits in the FZ_DEVICE_HINTS word. | 11:44.29 |
| No API changes at all. | 11:44.34 |
| I think the FZ_HINT way of working is my favourite. | 11:54.56 |
| For those interested, the windows 10 update seemed to go relatively painlessly (famous last words). | 11:57.31 |
| It does 'hide' programs from Program Files that it doesn't think will work in Windows.old/Program Files/, so my Program Files/bin/ directory where I keep all sorts of useful stuff got moved out. | 11:58.29 |
| I just had to move it back in again. | 11:58.33 |
| Likewise, some of my startup apps (like kageant and kitty --launcher) got moved out, but putting them back was similarly easy. | 11:59.34 |
| And now I can run linux stuff. | 11:59.45 |
sebras | Robin_Watts: hm... why are the intrepretations of each bit in device hints not per device type? | 11:59.56 |
Robin_Watts | sebras: Good question. | 12:00.18 |
sebras | Robin_Watts: if we do it that way they can be reused. | 12:00.34 |
Robin_Watts | "Because they haven't needed to be so far" ? | 12:00.35 |
| sebras: I would be tempted to define FZ_STEXT_LIGATURES and FZ_STEXT_WHITESPACE using new bits. | 12:01.37 |
sebras | right. == 32 and ==64. | 12:01.55 |
Robin_Watts | If we ever run short of bits we can reuse them. | 12:02.02 |
| yeah. | 12:02.03 |
sebras | I didn't know that device->hints existed. | 12:02.08 |
Robin_Watts | sebras: It's used so we can avoid expanding shadings when we're only doing text extraction etc. | 12:02.55 |
sebras | Robin_Watts: ok, so something like what is on sebras/wip now. | 12:53.18 |
Robin_Watts | I don't think you need the 2 unsigned ints in struct fz_stext_device_s now? | 12:54.21 |
| dev->super.hints && FZ_STEXT_LIGATURES | 12:54.34 |
| & not && ?> | 12:54.37 |
sebras | Robin_Watts: would it make sense to have fz_enable_device_hints take a comma-separated char * and parse each part in order to turn this into an internal flag? | 12:55.09 |
| i.e. similar to write options | 12:55.20 |
Robin_Watts | Hmm. I wonder if we should use FZ_STEXT_EXPAND_{LIGATURES,WHITESPACE} rather than FZ_STEXT_{LIGATURES,WHITESPACE} (my bad) | 12:56.04 |
| would be clearer about the sense of the switch. | 12:56.15 |
| having an fz_enable_device_hints equivalent that worked from a char * might be good, but we shouldn't change the existing call (IMAO) | 12:56.51 |
| Also, you have both bits set to 32 currently :) | 12:57.04 |
sebras | ?-P | 12:57.17 |
Robin_Watts | Hmm. fz_new_stext_page_from_display_list | 12:58.07 |
sebras | If we only provide a char *-based interface we shouldn't ever need to change the interface again (regardless of how many flags we choose to have internall or rename the flags or whatever) | 12:58.09 |
Robin_Watts | There is now no way to control those flags with fz_new_stext_page. | 12:59.17 |
| Yeah, I see the attraction of a text based option setting mechanism. | 12:59.42 |
| especially when doing the js integration. | 12:59.56 |
| D'Oh. I meant fz_new_stext_page_from_display_list, not fz_new_stext_page. | 13:00.26 |
sebras | Robin_Watts: I'm thinking that it may actually be a better general approach for flags in all interfaces unless they are called often. | 13:00.43 |
Robin_Watts | If we now have fz_new_stext_page_from_display_list take text flags, that would solve that problem too. | 13:00.49 |
sebras | Robin_Watts: true. | 13:01.09 |
Robin_Watts | sebras: Yes. I always wince when seeing char *s used for options, because of the overhead of string matching, but I suspect it's a good fit. | 13:01.21 |
sebras | Robin_Watts: basically char *options that it just forwards to fz_disable_hints() | 13:01.28 |
Robin_Watts | sebras: Urm... | 13:01.40 |
| our existing char * options matching stuff... | 13:01.56 |
| does it allow for option=0,option=1, etc? | 13:02.06 |
sebras | Robin_Watts: yeah, for the write options..? | 13:02.07 |
| Robin_Watts: there is some kind of key=value-thing in there. | 13:02.43 |
Robin_Watts | If so, then we should do disable/enable using that mechanism, rather than having 'disable' and 'enable' calls. | 13:02.44 |
| fz_set_hints(dev, char *flags) | 13:03.00 |
| and use "expand_ligatures=1", "expand_ligatures=0" etc. | 13:03.22 |
| the disable/enable things can stay as legacy versions using bits. | 13:03.56 |
sebras | Robin_Watts: yes, something like that. | 13:04.18 |
| Robin_Watts: I don't forsee that anyone would create devices many thousand times per second so string options in this case ought to be fine. | 13:04.37 |
Robin_Watts | I wish we had a tor to weigh in on this stuff. | 13:04.42 |
| sebras: Indeed. | 13:04.45 |
sebras | Robin_Watts: I'm sensing that tor8 wouldn't bother with making this configurable in the first place. :) | 13:05.32 |
| Robin_Watts: I'm happy to implement this as as proof-of-concept and keep it around on sebras/wip until he is back. | 13:06.38 |
Robin_Watts | ok. | 13:06.45 |
sebras | Robin_Watts: that means that fred has to live with the tabs when doing highlighting though. | 13:07.00 |
| or filter them out himself. | 13:07.05 |
Robin_Watts | sebras: For now. I don't think it's a showstopper for Fred. | 13:07.31 |
irctc484 | I'm adding a password to a pdf produced with libreoffice with "ghostscript -sDEVICE=pdfwrite -sOwnerPassword=test -sUserPassword=test -o testpass.pdf testnopass.pdf". If I do this gmail cannot open the document in Chrome, Firefox or Edge. If I download the document it will open with Okular or Adobe. If I add the password with Libreoffice then gmail can open it just fine. Any tips? | 13:53.20 |
| ...that was with ghostscript GPL Ghostscript 9.18 (2015-10-05) | 13:57.23 |
kens | There's really little we can say. If the file can be opened after downloading it then its clearly valid. Presumably therefre this is a GMail problem, perhaps you should take it up with Google | 13:57.53 |
| Note that you are not 'adding a password' you are creating a new PDF file, which may bear no relation ot the original PDF file other than in appearance, which is encrypted. | 13:58.38 |
| THe other thing that crosses my mind is that you are adding bot an owner and a user password. Perhaps if you use LibreOffice, it only adds an owner password | 13:59.55 |
irctc484 | Owner alone doesn't prevent open which is what I need. | 14:02.21 |
kens | Well there's really little I can say, especially without seeing the PDF file(s) | 14:03.03 |
irctc484 | I can send the file if it someone is willing to look at it. | 14:04.28 |
kens | I'd need both files in order to do a comparison. Bets bet is to put it on a public site like DropBox | 14:04.51 |
| s/it/them/ | 14:04.57 |
irctc484 | this fails to open in gmail - use password "test" http://www.filedropper.com/failsingmailusepasswordtest | 14:14.32 |
kens | And teh one which does open ? | 14:15.31 |
irctc484 | file without password - http://www.filedropper.com/nopass | 14:15.47 |
| file with password created in libreoffice which works in gmail http://www.filedropper.com/libreofficefilewithpasswordworksingmail | 14:18.59 |
kens | Ghostscript is using a version 1 40-bit key, the LibreOffice is using a version 2 128-bit key | 14:20.13 |
| THere's nothing wrong with what Ghostscript produces, looks like a limitation in GMail | 14:20.28 |
irctc484 | Hmmm... can Ghostscript do 128 bit key? | 14:22.12 |
kens | Try setting -dEncryptionR=3 | 14:22.19 |
| You probably need to se -dKeyLength=128 as well | 14:22.33 |
| THis is covered in the documentation | 14:23.05 |
irctc484 | using... ghostscript -sDEVICE=pdfwrite -dEncryptionR=3 -dKeyLength=128 -sOwnerPassword=test2 -sUserPassword=test -o testpass.pdf nopass.pdf ...still no luck | 14:27.25 |
kens | Guess you'll have to ask Google then | 14:27.50 |
irctc484 | Ok... thanks for trying! | 14:29.10 |
kens | I cna't see anything immediately obviously different between the construction of the LireOffice file and the Ghostscript file. THey are, of course, very differnt, as is to be expected | 14:29.36 |
| But both appear to be valid to me. | 14:29.42 |
irctc484 | Thanks again! | 14:30.17 |
kens | You're welcome | 14:30.23 |
sebras | irctc484: I just downloaded all of your files, and I'm using chromium 51.0.2704.79 on 32-bit debian and it can show all of your files fine (two require the password "test" of course) | 14:33.00 |
kens | But I think the problem was GMail not chromium.... | 14:33.23 |
| I have no clue what limitations GMail may labour under | 14:33.37 |
sebras | kens: oh, does gmail parse and render pdf-files itself? | 14:33.50 |
| kens: I had no idea. :) | 14:33.55 |
kens | I don't know either | 14:34.00 |
| There are significant differences between the files, for starters the Ghostscript version drops the pointless transparency | 14:34.27 |
irctc484 | I believe gmail is using it's own built-in renderer. | 14:34.36 |
kens | I notice the permissions are also differnet, you might want to try setting -dPermissions=-3080 | 14:43.54 |
irctc484 | -dPermissions=-3080 ...does not work | 14:49.36 |
kens | Beats me then, there is no significant structural difference between the files except for that and the fact that the pointless transparency has been dropped. Oh and so has hthe LaunchActio | 14:50.21 |
| None of those ought to make a difference, but to be honest its not really possible for me to guess what someone else's PDF consumer is objecting to, if it won't tell you | 14:50.48 |
irctc484 | Yeah this is a tough one... | 14:53.20 |
sebras | irctc484: how do you trigger google drive/docs/whatever to create a preview for you? | 14:56.20 |
irctc484 | the problem is in gmail and you just click on the attachment icon | 15:00.52 |
| sebras: I just tested and google drive exhibits the same problem. | 15:07.03 |
sebras | irctc484: I can reproduce your problem and there is nothing in the web console either. for the successful files they are rendered on the server and your browser only gets a .png-file. | 15:09.14 |
| irctc484: on google drive I couldn't even reproduce the issue. | 15:09.28 |
irctc484 | sebras: so on google drive you can open the ghostscript password protected pdf? | 15:14.09 |
HenryStiles | fwiw I can't open it in gmail or google drive | 15:14.34 |
kens | All I can reasonably say is that it does not appear to hbe a defective file | 15:22.16 |
sebras | irctc484: no I can't, I cannot even see a preview. I should have expressed myself better when writing that message, sorry to get your hopes up. :) | 15:23.53 |
HenryStiles | irctc484: have you poked around the chrome browser logs for an error message? I've never fooled with it but I see chrome writes stuff to .config/google-chrome in my home directory | 15:27.09 |
irctc484 | HenryStiles: I'll look but if this render is server side... | 15:28.21 |
sebras | HenryStiles: irctc484: I already did that and I cannot see anything in the browser logs. for the .pdf-files which do work the browser receives a .png-file with an image of that page in the pdf. | 15:31.21 |
kens | Its probably a silly question, but has anyone tried a non-enctypted file ? | 15:34.44 |
| One produced by Ghostscript I mean | 15:35.09 |
HenryStiles | use it all the time, looks like this a known problem acknowledged by gmail folks - see last entry here: https://productforums.google.com/forum/#!topic/gmail/mwVR9ydiP-A;context-place=topicsearchin/gmail/category$3Areading-and-receiving-messages | 15:36.11 |
| no idea why they let you encrypt stuff anyway, how are they going to spy on you if they allow that ;-) | 15:39.06 |
kens | Wel its not them letting you encrypt it, the PDF files are encrypted elsewhere and sent via GMail | 15:39.32 |
irctc484 | It'd be nice if we knew what Libreoffice was doing when creating the password protected pdf since that works with gmail. | 15:39.54 |
kens | 23 days to get the bug even confirmed and no sign of a fix, and its a regression. Makes our responses look good :-D | 15:40.20 |
HenryStiles | kens: right I should say they shouldn't let you decrypt and facillitate encrypted email | 15:42.49 |
kens | :-) | 15:43.02 |
| Presumably they just harvest the passwords for later use :-) | 15:43.16 |
HenryStiles | irctc484: maybe you should post your libre office findings to the the forum? | 15:46.19 |
irctc484 | HenryStiles: maybe the problem shows up in ghostscript derived applications? | 15:53.17 |
sebras | kens: I recognize this level of customer bug report feedback from bigger companies I've worked in. | 16:04.06 |
HenryStiles | irctc484: we are a big producer of pdf second only to adobe and microsoft, we might actually be in 2nd place ahead of MS so I hope there are lots of complaints | 16:07.22 |
| and google takes notice | 16:08.10 |
| Forward 1 day (to 2016/08/04)>>> | |