| | <<<Back 1 day (to 2017/03/09) | 20170310 |
| volodymyrkhmil | Hi! Does iOS version of MuPDF SDK has same functionality as Android? Seems I can't find some functions there. | 10:34.34 |
| kens | volodymyrkhmil : MuPDF (the core library) is the same across all plstforms. The demonstration applications differ. | 12:02.55 |
| volodymyrkhmil | Can't find there complete_signatures function | 12:08.10 |
| kens | I'm afraid I'm not a MuPDF develoer, but AIUI the code is the same across all platofrms. Only the application differs. One of the developers should be online in an hour or tow though | 12:19.04 |
| volodymyrkhmil | it would be great to have quick chat with him. We are writing huge PDF signing application and we've faced with some problems during our development. | 12:20.42 |
| kens | volodymyrkhmil : Before you go too far down taht road, can I just draw your attention to the licence ? You are aware that its licenced under the AGPL, which means you will need to licence your code the same way, or seek a commercial licence. | 12:24.39 |
| volodymyrkhmil | Yeh, I'm just a developer, all this licences are handled by customer. All I know that all our code seems to be open source, or something like this | 12:26.28 |
| | Or I may be wrong. We just need to sign it correctly because we already tried another payed SDKs and they didn't worked as we expected. | 12:28.03 |
| | So even commercial license is't problem, it's fine for us, we just need ti achieve some specific behaviour... | 12:28.51 |
| kens | I just wanted to be sure the licence wouldn't come as a surprise to you. | 12:30.16 |
| | I should probably also mention that the signature code is a work in progress, I'm not certain its completed yet. Again one of teh developers will have a better idea than me | 12:30.56 |
| volodymyrkhmil | I case of need can we extend it with some ours functionality? | 12:31.43 |
| | I mean on ours side - no need your involvement | 12:32.05 |
| kens | The code is open source, so you can certainly extend it. | 12:32.07 |
| volodymyrkhmil | That what we need exactly | 12:32.27 |
| kens | Of course since its actively being developed, you run the risk that you will need to rework your code with each release | 12:32.37 |
| volodymyrkhmil | We can use initial SDK version that will be stable for us. Please ping me when I talk with developer, it would really help me. | 12:45.04 |
| kens | I'll ask him to do so. Just so you are aware, we are all currently at a staff meeting in the US, so responses may be intermittent and delayed (breakfast time in about 2 hours for example) | 12:46.06 |
| volodymyrkhmil | of course^ no problem for me. If it will help solve me my problem, than of course | 12:47.11 |
| RobinWattsLenovo | volodymyrkhmil: The digital signature stuff relies on some functions in the OpenSSH library | 12:54.09 |
| | We've only ever actually put that into builds for android. | 12:54.42 |
| | So the ios example viewer project will indeed be missing functions. | 12:55.04 |
| | To get it working on ios probably requires a certain amount of work on our part - not a huge amount, but some. | 12:56.06 |
| | We are very busy at the moment, hence this is not something we'd do for a free user. | 12:56.28 |
| | (It's on our list, it's just not high in the priorities yet) | 12:56.50 |
| | So, I'm fairly sure we can't immediately help you without some sort of commitment towards you taking a commercial license. | 12:57.46 |
| | The best thing to do is probably to write an email describing exactly what you want to be able to do with the library (the more detail the better, certainly more than "we want digital signatures"), and to send it to scott.sackett@artifex.com, and to copy it to me (robin.watts@artifex.com). | 13:00.07 |
| | That way we can have a talk internally about how much work it'll be, and Scott can figure out a ballpack figure for a price. | 13:00.51 |
| | Then if that sounds reasonable to you, we can all make some headway. | 13:01.20 |
| | What we don't want to happen is for you (or us) to spend lots of time trying to get something working, only to find that it's too expensive for you, or something. | 13:02.25 |
| | Seem reasonable? | 13:02.30 |
| volodymyrkhmil | I've already done some work with OpenSSH on my own side and changed code a bit, issue appears with document saving. I'm not sure it needs your involvement. It would be great if someone could take a look and tell whether it need's update of yours code, or I'm missing something using your methods. If it needs you involvement than I can discuss it with my client and even conenct you together to discuss this. | 13:03.04 |
| | Right now I just need to know if I made mistake or if it's need to be added to yours functionality. Is it possible, or either way we need to discuss about pricing? | 13:04.40 |
| RobinWattsLenovo | volodymyrkhmil: The engineer responsible for the digital signature code is buried in high priority work at the moment. | 13:27.48 |
| | He's unlikely to be able to diverted from that for much in the short term. | 13:28.08 |
| | So, we absolutely need a clear statement from you of exactly what you want to do with the code before we can go any further. | 13:28.42 |
| | I'm sure that the first question my bosses will ask will be "is this a realistic prospect for a commercial license?" | 13:29.18 |
| | hence I think we need to at least understand what your business plan is, yes. | 13:29.55 |
| volodymyrkhmil | Let me that involve more Client, as I'm not as responsible for such suggestions. He will connect with you at email you sent me previously. | 13:32.41 |
| RobinWattsLenovo | cool. | 13:53.32 |
| PhilS_ | Hi guys, is a dev in here that deals with tiffsep1 device? | 14:03.04 |
| chrisl_x250 | PhilS_: Possibly not not right now. But this channel is logged, so if you have a question, ask it, it should be seen in the logs by someone that can help | 14:06.18 |
| kens | PhilS we're all in Texas at the moment | 14:06.38 |
| | Staff meeting | 14:06.46 |
| PhilS_ | understood. I sent a mesage or two to Ray and support and and irc message or two yesterday, figured you guys were indisposed :) | 14:07.24 |
| kens | PhilS_ : I did rply to your email, didn't you get it ? | 14:07.49 |
| PhilS_ | no ken, I did not. | 14:08.11 |
| kens | :-( That's a surprise. | 14:08.28 |
| | It came into support OK. Note that it came from my own email account, as I can't log into GMail at the moment | 14:08.51 |
| PhilS_ | when did you send? Perhaps our filters denied it | 14:09.06 |
| kens | It would have been last night | 14:09.13 |
| PhilS_ | yikes, no I did not recevie | 14:09.24 |
| kens | I didn't get a bounce message, but it maybe got flagged as spam | 14:09.31 |
| PhilS_ | perhaps resend to an alternate address: pjsyeah@comcast.net | 14:09.44 |
| chrisl_x250 | I can forward it, but all it said was "we're traveling, there'll probably be some delay" | 14:10.08 |
| kens | Well I didn't say anything except 'we're travelling to a staf meeting', so its not important | 14:10.19 |
| PhilS_ | oh.....nevermind then | 14:10.27 |
| kens | :-) Sorry you didn't get it though | 14:10.39 |
| PhilS_ | it happens | 14:10.43 |
| kens | I'll poke it quickly this morning | 14:11.07 |
| | The 1st part of the meeting won't affect me so I can keep an ear on it and do something constructive at the same time | 14:11.30 |
| PhilS_ | hows the Texas meeting going? I suppose you guys are ramping for next release (certainly amoung other things ;) ) | 14:11.51 |
| kens | The release is under way, already did a load of testing, fixed a couple of regressions that popped up, and a couple of errors that have always been there but never been noticed | 14:12.34 |
| | But we only flew in last night, so meeting is still an hour away :-) | 14:12.58 |
| chrisl_x250 | PhilS_: the next gs release is in progress, I just didn't want to rush the last bit, so I'm leaving for another week or so | 14:13.08 |
| PhilS_ | glad to hear it! I have beeing watching git like a madman | 14:13.29 |
| kens | I guess you'll have seen the sudden increase in commits then :-) | 14:13.47 |
| PhilS_ | right 48 hours until this morning! | 14:13.59 |
| kens | OK I've loacted your original email and got the files, so I'll run it and see what happens | 14:14.22 |
| PhilS_ | thx | 14:14.28 |
| | while i have you both, a couple more q's if i could: | 14:15.22 |
| | kens, was also wondering if you had any thoughts on per-object type halftoning? | 14:15.26 |
| kens | PhilS_ : I thought Ray sent you an email ? | 14:16.21 |
| chrisl_x250 | Robin sent the mail iirc | 14:16.38 |
| kens | Actually, Robin did I think | 14:16.39 |
| | echo :-) | 14:16.45 |
| PhilS_ | didnt; get that either.... | 14:16.50 |
| kens | Oh wow | 14:16.54 |
| | I don't have a copy of it here, I'll ask him to resend (unless chrisl has a copy available) | 14:17.19 |
| PhilS_ | when were these sent? I will have to go through our logs here and see what's going on..... | 14:17.59 |
| chrisl_x250 | We'll prod Robin about it | 14:18.09 |
| kens | Actually I lie, I do have a copy here | 14:18.09 |
| PhilS_ | please do a cc on all othis to pjsyeah@comcast.net if possible, until I can sort it | 14:18.22 |
| kens | Yup, no problem | 14:18.33 |
| PhilS_ | sorry guys, I didn;t realize there had been attempted responses going on...... | 14:18.56 |
| kens | Not a problem PhilS_ I'll get the email to you in a bit, need to go get some breakfast | 14:19.23 |
| | And I'll prod the halftone as well | 14:19.34 |
| PhilS_ | roger that. ill be in here all day | 14:19.44 |
| | thx again for the responses | 14:19.57 |
| kens | Not at all, glad you thought to come here and prod us directly | 14:20.44 |
| PhilS_ | i spent last night looking through 'all' of the irc logs looking for tiffsep1 discussions....lol....found a few! | 14:23.07 |
| chrisl_x250 | PhilS_: tiffsep and tiffsep1 are two of our more "interesting" devices! | 14:24.03 |
| | Anyway, breakfast, and then meeting. Back later! | 14:24.53 |
| PhilS_ | enjoy! | 14:25.19 |
| kens | PhilS_ : I can certainly see the seg fault you describe. Its in tiffsep1 itself, which (to my surprise) seems to be doing something with the threshold array itself. Looks like its running off teh end of the array to me. | 15:27.05 |
| PhilS_ | interesting kens | 15:28.25 |
| | I treied making it a simple Type3, same issue | 15:28.33 |
| | however, Type5, with nested Type1 (simple spot fucntion etc) for the colorants will work | 15:29.15 |
| kens | Well, its not really my area of expertise.... | 15:32.48 |
| | But bits=65025 doesn't look right to me :-) | 15:33.02 |
| PhilS_ | i am almost 100% certain the halftone array is valid, as I used it with other devices...also the hh_csto as supplied in lib also will bail with tiffsep1, so what you are saying certainly makes sense | 15:36.02 |
| | the array was generated using gen_threshold and thresh_remap | 15:36.24 |
| | I was thinking,maybe, the straight up tiffsep device with BitsPerComponent=1 would work, but it looks like that device just does straight up error diffusion, and possibly ignores the currenthalftone | 15:42.24 |
| kens | Sorry PhilS_ I was inside the debugger. | 15:45.58 |
| PhilS_ | np | 15:46.17 |
| kens | tiffsep1 seems to be the only device that meddles directly with the halftone, I'm not at all sure why.... | 15:46.21 |
| | I'm just trying to get my head around what all the members in the structure mean | 15:46.45 |
| | So I'm up at the interpreter end working out how all the values get set. | 15:47.00 |
| | Right at the moment, the numbers I se look likely to fall off the end of the array (I'm seeing an offset of > 13,000,000 which will fall off even if its measuing bits) | 15:47.36 |
| | I'll probably end up passing this to someone with more idea of this code area, but I may as well do something constructive | 15:48.14 |
| PhilS_ | do you know who was the original author? | 15:49.54 |
| kens | Sorry, I'm afraid not | 15:50.37 |
| | It will have been some considerable time ago | 15:50.45 |
| | It appears to be code to generate a threshold array from an internal 'order' structure | 15:51.45 |
| | I'm somewhat puzzled as to why tiffsep1 needs to do this when other 1-bit devcies do not | 15:52.07 |
| PhilS_ | where are you seeing that in the code? | 15:52.59 |
| kens | Whih ? | 15:53.12 |
| | Sorry which bit ? | 15:53.18 |
| PhilS_ | internal 'order' structure | 15:53.40 |
| kens | Oh right, that's in threshold_from_order() called from sep1_ht_order_to_threshold | 15:54.22 |
| | the tiff device seems to be holding its own threshold arrays. I presume its doing the screening itself (!) | 15:55.40 |
| chrisl_x250 | Does tiffsep1 do a composite preview? | 15:57.02 |
| kens | Err, no idea :-) | 15:57.20 |
| | let me try | 15:57.28 |
| | Apparently that's a no, I only get the 4 plates | 15:58.24 |
| PhilS_ | no it doesn;t | 15:58.29 |
| | OutputFile command line parameter will not be created (it is opened, but deleted prior to finishing each page). | 15:58.37 |
| chrisl_x250 | I just figured that was one possible reason for it to do its own halftoning | 15:59.41 |
| kens | FWIW the 'bits' parameter is correct, its the number of bits in the x direction * the number in the y direction | 15:59.52 |
| | 255*255 = 65025 | 16:00.03 |
| PhilS_ | right | 16:00.08 |
| kens | It seems that tiffsep1 is getting composite (presumably CMYK) data, and applying the screen itself. | 16:01.16 |
| | Which is why it generates the threshold arrays from the 'order' | 16:01.33 |
| | I'm inclined to think that its the fact that its a type 3 (threshold array) instead of a type 1 (PS spot function) that causes this. Somehow the type 3 one just isn't working | 16:02.55 |
| PhilS_ | yea, type1 works ok... | 16:03.34 |
| kens | PhilS_ : do you have the type 1 example available ? | 16:04.13 |
| PhilS_ | yes, they are part of a type5 parent. | 16:04.36 |
| | hold | 16:04.45 |
| kens | Can you send me that one as well ? I can look at the code when that's running and try to figure out what part of teh type 3 is wrong | 16:05.10 |
| PhilS_ | will do, give me a few mins. what e-mail addy shall i send to? | 16:05.52 |
| kens | my artifex one is fine, GMail forwards it for me | 16:06.06 |
| | Email is a bit slow on the hotel free WiFi, but it gets there eventually.... | 16:06.24 |
| PhilS_ | lol! yes, hotel-wifi........eesh! | 16:06.48 |
| kens | It doesn't help that we have 15 people all using it simultaneously from the same room ;-) | 16:07.49 |
| PhilS_ | :) | 16:08.20 |
| | sent | 16:10.45 |
| kens | PhilS_ : looks like Robin has sent you an email about object halftoning, can you confirm if you got it ? | 16:11.16 |
| PhilS_ | yes, I recvd. (thanks Robin)! | 16:11.29 |
| kens | Great, thanks | 16:11.38 |
| PhilS_ | I understand the challenge(s) described with it. | 16:11.56 |
| | I will review more | 16:12.01 |
| kens | twiddles fingers while hoping email client will eventually notice new mail..... | 16:12.12 |
| PhilS_ | heh, if it doesn't *want* to cooperate, I can put it someplace else | 16:14.22 |
| kens | Its OK its finally here | 16:15.12 |
| | Just very slow..... | 16:15.21 |
| PhilS_ | roger that | 16:15.27 |
| kens | OK so the 'offset' is more sane looking there | 16:18.02 |
| PhilS_ | smaller i would assume | 16:18.18 |
| kens | There's some weird stuff here, row_kk turns out to -65536 | 16:18.58 |
| PhilS_ | ick | 16:19.41 |
| kens | Ah no, its OK it hadn't been initialised yet | 16:19.48 |
| | breakpoint in a less than ideal place | 16:20.03 |
| | PhilS_ : 8 looks OK to me, the width and height values of the threshold are small. Porbably I'm using low resolution or soemthing | 16:20.57 |
| PhilS_ | use -r600 | 16:21.25 |
| kens | It does confirm what I thought which is that bits[j].offset is *way* too big | 16:21.32 |
| | PhilS_ : it crashes anyway :-) | 16:21.41 |
| PhilS_ | you crash with the type5??? | 16:22.07 |
| kens | No, the type 5 with type 3 dicts I mean | 16:22.26 |
| PhilS_ | oic....yes | 16:22.39 |
| kens | FWIW the type 5 with type 1 dicts at 600 dpi has an offset of 32 | 16:22.43 |
| | Fundamentally the offset of > 13,000,000 is fairly clearly wrong | 16:23.14 |
| | So I need to look at where that is being set up I think | 16:23.26 |
| PhilS_ | thresh = (byte *)gs_malloc(memory, d_order->width * d_order->full_height, 1, "tiffsep1_threshold_array"); ?? | 16:27.08 |
| kens | Hmm I don't think that's where the offset I'm looking at is set | 16:27.53 |
| | Its in the corder member structure | 16:28.08 |
| PhilS_ | dorder or corder? | 16:28.49 |
| kens | corder I think | 16:29.34 |
| | looks like its in gsht.c somewhere | 16:29.52 |
| PhilS_ | im in there | 16:30.52 |
| kens | Well I can see where the bit_data gets allocated, but that's not where the offset gets set :-( | 16:31.44 |
| | Hmmm maybe gx_ht_construct_threshold_order | 16:32.13 |
| | I think I've confused myself.... | 16:33.16 |
| | No, I'm right. The code here looks horribly wrong. We seem to be writing threshold samples in one place, and reading back gx_ht_bit structures in another in another | 16:35.33 |
| | PhilS_ : if you look in gxhtbit.c, construct_ht_order_short() there's a loop which fills in 'bits' where bits = order->bit_data. | 16:38.54 |
| | So that looks to me like its filling in threshold values. | 16:39.10 |
| | Whereas in threshold_from_order() we cast d_order->bit_data to gx_ht_bit *bits | 16:39.58 |
| | And thentreat this as trcuture members | 16:40.15 |
| | So I could be looking at two different things, but it would explain why the data I'm looking at (eg the offset) is not a sane value | 16:40.52 |
| | This is not going to be a quick fix PhilS_ | 16:42.59 |
| PhilS_ | ya, i figured something is zigging instead of zagging. I believe this has been *around* for quite some time. If memory serves, i tried this also way back in the 8.x chains some years ago :( | 16:44.04 |
| kens | Well it looks to me like its never worked | 16:45.23 |
| | Though as I say, this isn't really my area | 16:45.34 |
| | I'll chat to everyone here and see who is going to own this one, then get a bug opened | 16:46.24 |
| | I'll even try and remember to send you an eamil with the bug number :-D | 16:47.13 |
| PhilS_ | it is possible it never did, however i cannot recall exactly when the 1st time was I ever gave it a type3 to chew on | 16:47.19 |
| | sounds good Ken. sorry for the hassle.. | 16:48.17 |
| kens | Not a problem, this *ougrk and it clearly doesn'tht* to | 16:49.05 |
| | Bah stupid keyboard | 16:49.14 |
| | '*ought* to work and clearly doesn't' | 16:49.27 |
| PhilS_ | i do see the loop you refer to in construct_ht_order_short() | 16:49.35 |
| | and i see the cast as well | 16:50.07 |
| kens | Yeah I think there's some kind of invalid assumption about the data format there | 16:51.16 |
| PhilS_ | i am somewhat surprised that someone else in the world hadn't run across it! | 16:51.32 |
| kens | Me too, I guess nobody uses type 3 threshold arrays... | 16:51.57 |
| | Its 'possible' (but unlikely) that this works with other 1-bit devices. | 16:52.19 |
| chrisl_x250 | Also, very few folks are using the tiff devices, compared to the other devices | 16:52.20 |
| kens | It may be that only the tiffsep1 device is using this method of generating threshold arrays, possibly the graphics library knows that these already *are* thresholds and just uses them directly | 16:53.10 |
| PhilS_ | tiff devices are awesome though! ;) | 16:53.11 |
| | other tiff devices seem to use it OK if i'm thinking properly. | 16:54.44 |
| kens | If they are 1-bit devices they aren't using this piece of code | 16:55.19 |
| | Presumably they just use the graphics library to do the rendering (and therefore the screening) | 16:55.37 |
| PhilS_ | i can say that tiffpack works with it, so ya | 16:57.21 |
| kens | Like I said, this isn't really my field. So I guess this might have changed at some point, the graphics library was updated (because it wold be obvious that was needed) but nobody realised that tiffsep1 would be affected | 16:58.58 |
| | In which case, it may be easier to fix than I first thought. I should try a 1-bit device and see what it does | 16:59.53 |
| | OK I see the tiff devices are owned by Ray and Henry so I'll ask them about this when we get a pause in the meeting. | 17:00.43 |
| PhilS_ | and it seems that tiff24nc works ok...although that doesn't do the separations | 17:01.44 |
| kens | Or 1-bit output, therefore no screening | 17:02.00 |
| PhilS_ | right | 17:04.10 |
| kens | I think I may have to start paying real attention to the meeting now.... | 17:12.54 |
| PhilS_ | you probably should.....;) | 17:16.02 |
| | or at least give the impression that you are. | 17:16.36 |
| | kidding of course...thanks for diving in ken, much appreciated | 17:18.42 |
| bencc | when converting pdf to svg with mupdf it converts fonts to path | 17:42.42 |
| | is it possible to leave fonts as fonts? | 17:42.52 |
| chrisl_x250 | No | 17:46.02 |
| tor8 | bencc: yes, if you use the 'text=text' device option | 18:24.22 |
| | mutool convert -O text=text -o out%d.svg input.pdf | 18:24.46 |
| | but beware that the fonts will not match up if the system doesn't have the original font | 18:25.35 |
| | so the document will look different. | 18:25.48 |
| PhilS_ | so what did you guys have for lunch? | 18:51.46 |
| kens | Hi PhilS_ just got back from 'Pollo Loco'.... | 19:15.15 |
| | Its just over the road, and its quick, so.... | 19:15.36 |
| PhilS_ | I believe, I had the best Thai food in the planet today over here in MI, so thats why I ask. | 19:17.20 |
| kens | :-( | 19:17.32 |
| | Would rather have had Thai | 19:17.40 |
| PhilS_ | who wouldn't ?? ;) | 19:17.58 |
| kens | barbecue tonight apparently | 19:18.19 |
| PhilS_ | ahh better than Pollo....and while in Rome....TX BBQ is insanely tasty | 19:22.14 |
| bencc | tor8: with ghostscript or mupdf? | 20:15.01 |
| tor8 | bencc: mupdf. | 20:15.28 |
| bencc | great. trying | 20:15.33 |
| tor8 | you'll need the latest git code though | 20:15.41 |
| | the feature is very new | 20:15.47 |
| bencc | "cannot create document: unknown output document format: svg" | 20:16.20 |
| | ok. you are fast :) | 20:16.29 |
| | I'll try to compile from git | 20:16.35 |
| | I compiled 1.10a | 20:16.39 |
| | are there instructions how to build mupdf from git? | 20:20.27 |
| | I only see instructions for android | 20:20.32 |
| tor8 | where are you looking? mupdf.com | 20:33.26 |
| bencc | tor8: yes | 20:43.50 |
| tor8 | linux or windows? | 20:44.13 |
| bencc | linux - ubuntu 16.04 | 20:44.20 |
| tor8 | for windows, open 'platform/win32/mupdf.sln' | 20:44.28 |
| | for linux, just run 'make' | 20:44.33 |
| bencc | ok | 20:44.37 |
| | trying | 20:44.40 |
| | tor8: works great. thanks | 20:56.31 |
| kens | PjSYeah : in case my email doesn't reach you, your bug is here: | 22:52.13 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=697661 | 22:52.13 |
| | Forward 1 day (to 2017/03/11)>>> | |
Log of #ghostscript at irc.freenode.net.