| | <<<Back 1 day (to 2014/07/29) | 2014/07/30 |
| newone | ? | 07:40.55 |
| kens | :-P | 07:41.05 |
| newone | will have a look at http://www.ghostscript.com] | 07:42.12 |
| | going to leave ... | 07:45.41 |
| sebras | pulls kens' tongue since it still sticks out. | 09:04.11 |
| kens | :-) | 09:04.22 |
| sebras | hey! where did it go? ;) | 09:04.34 |
| | has newone been here before? | 09:04.43 |
| kens | Not that I know of | 09:04.49 |
| tor8 | marcosw: robin would know | 10:48.04 |
| kens | pstack | 12:11.47 |
| GerryB | Can anyone on the artifex side tell me if the change I submitted for gdevatx.c made it to the code base? | 13:12.44 |
| chrisl | GerryB: can you point us to where you submitted the change? | 13:13.29 |
| GerryB | I sent the modified file to Miles originally last December, and more recently a couple of weeks ago | 13:14.29 |
| kens | Miles is probably not the best place :-) | 13:14.41 |
| GerryB | It wes to add a device variant | 13:14.47 |
| | I did not know any better | 13:14.58 |
| kens | Miles is our CEO, not a developer | 13:15.04 |
| | Bets bet is to open a bug report as an enhancement | 13:15.16 |
| GerryB | Ok I try to figure out how to do that | 13:16.01 |
| kens | When you attach the patch you will ge thte opportunity to get our contributor licence agreement (don;t know if you've already fone this), we'll need a signed copy of that | 13:16.02 |
| | s/fone/done/ | 13:16.15 |
| GerryB | That I did send to miles | 13:16.22 |
| kens | OK tehn all we need is convincing its a good idea :-) | 13:16.39 |
| GerryB | I did not change any algorithms. We have kept compatibility through 3 generations of printers since we had Peter add that file for us. | 13:18.31 |
| | But the latest iteration had a new mechanical design which allows us to remove the margins. A customer wanter to print wider, hence the proposed dedice addition. | 13:19.54 |
| chrisl | So, presumably this will be another "atxXX" device? | 13:20.06 |
| kens | Without looking at your patch, I'm not clear what you're asking for, but like I said, go ahead and let us see it. Offhand I can't think of a reason why we'd have a problem | 13:20.17 |
| GerryB | Actually, the ATX is obsolete. The current nomenclature is ITK, so I added that device definition as itk24 or itk24i. | 13:22.26 |
| kens | So should we remove the ATX device, or are there still people using it ? | 13:22.48 |
| GerryB | But as I say, we have kept binary compatibily with the rendering algorithm. | 13:23.25 |
| | I would leave it, at existing customers are usingthe atx device, and might beat on me if they have to change things. | 13:24.22 |
| kens | :-) More likely beat on us I guess..... As long as its still being used, there's a good reason to keep it | 13:24.47 |
| chrisl | GerryB: Given that you are adding support for your printers to the device added for your benefit, I don't foresee any problems putting the patch in | 13:25.07 |
| kens | agrees | 13:25.18 |
| GerryB | Thanks. Got a meeting. I will submit it when I get time to . Thanks! | 13:25.51 |
| chrisl | Why do people have this idea that submitting a bug report is so time consuming? | 13:27.07 |
| kens | I have no idea :-) | 13:27.17 |
| | Making some slow progress, I have the charproc capture done, and I can emit the text, attach the charproc to the font. THe only thing that isn't working at the moment is that the CharProc doesn't get written to the PDF file :-( | 13:28.03 |
| chrisl | Minor detail! | 13:28.25 |
| kens | And Todd has come up with another ps2write file that doens't print to a specific (different to the HP) printer | 13:28.37 |
| | stackunderflow on sub this time O.O | 13:28.50 |
| chrisl | FFS, we *cannot* be getting that wrong! | 13:29.11 |
| kens | The error page reports the operand stack is empty..... | 13:29.32 |
| | Of course the exact same fikle work on the HP 4000. | 13:29.42 |
| chrisl | Well, surely that's evidence that it's HP's fault, and not ours? | 13:30.04 |
| kens | It *could* be taking some different path through the ps2write labyrinth of course. NB the HP works, the other priner doesn't | 13:30.19 |
| chrisl | Oh, I thought you meant they were both HPs | 13:30.41 |
| kens | No, the 1st problem fails on HP works on other pritners, the 2nd one works on HP fails on 'something else' | 13:31.07 |
| chrisl | What's the something else? | 13:31.20 |
| kens | let me see if he said | 13:31.28 |
| | Oh it is an HP | 13:32.10 |
| chrisl | <sigh> | 13:32.18 |
| kens | HP color laserjet 375nw | 13:32.19 |
| | So it works on one HP printer, but not another one..... | 13:32.32 |
| chrisl | I'd more than surprised if we were really leaving an empty stack and calling sub, but you never know | 13:34.22 |
| kens | Nothing much surprises me when it comes to ps2write/pdfwrite | 13:34.48 |
| chrisl | True.... *but* I stand by the fact that, for all the issues we've investigated, we've yet to find one where the ps2write output was *actually* wrong | 13:36.11 |
| kens | And I suspect that will still be true for this one too. | 13:36.30 |
| | Did I mentiopn that I have hacked ps2write so that the debug output goes to the printed page ? | 13:36.50 |
| | iuts the only way I cna get back channel data out.... | 13:37.10 |
| chrisl | That makes sense.... painful, and wasteful, but, no choices | 13:38.01 |
| kens | Yeah, I need to do some more with tit too, to check that it doesn't zoom off the top of the page, but its better than nothign | 13:38.29 |
| | FWIW when I run the file here, the current VM mode *and* the allocation mode of currentfile are both global | 13:39.04 |
| chrisl | Okay, I didn't expect that, but that's good | 13:39.33 |
| kens | Maybe... Its possible the HP doesn't like applying filter to a global VM object | 13:39.54 |
| chrisl | Well, that would be bonkers - still, I'd assumed the VM mode would be local, and particularly currentfile would be global, so consistent is good | 13:41.14 |
| kens | Yeah. Also FWIW hte PCL file that has been sent to Marcos works fine in current code, it has a familiar feel, I htink Henry fixed something ion the PCL interpreter | 13:41.59 |
| chrisl | The one from the German people? | 13:42.25 |
| kens | Yes that one | 13:42.31 |
| | I don't have a 9.14 PCL interpreter to check the release with though | 13:42.44 |
| chrisl | I'm not exactly sure why Marcos didn't direct them to bugzilla..... | 13:43.00 |
| kens | I would have, certainly :-) | 13:43.11 |
| | Just remembered I need to mail Joann | 13:44.19 |
| kens2 | ping mattchz | 13:56.53 |
| mattchz | hi kens | 13:57.08 |
| | +2 | 13:57.10 |
| kens2 | :-) What version of NDK are you using to build MuPDF on Android matt ? | 13:57.25 |
| mattchz | let me check. | 13:57.42 |
| | 9d â on osx | 13:57.57 |
| kens2 | Are you able to try 10 without breaking everything ? | 13:58.21 |
| mattchz | I can give it a try. | 13:58.30 |
| | is it out? | 13:58.36 |
| kens2 | Well people claim they are using it on this bug thread: | 13:58.54 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=695381 | 13:58.54 |
| | And it doesn't work | 13:58.59 |
| | getting an error on sdtrtof | 13:59.10 |
| | strtof* | 13:59.15 |
| | Not being an Android developer I haven't a clue of course | 13:59.34 |
| mattchz | let me try. If 10 isnât working, we should probably fix it. | 13:59.42 |
| | downloading now. | 13:59.59 |
| kens2 | THat was what I was thinking yes, this is at least the 2nd bug report, and there have been people here querying it | 14:00.06 |
| henrys | kens2, chrisl : miles just told him he canât use PCL and marcosw is helping him ;-) | 14:00.11 |
| kens2 | Who can't use PCL ? The German guy ? | 14:00.28 |
| henrys | kens2: yea | 14:00.34 |
| kens2 | Oh, well it seems to work OK with the master code :-) | 14:00.47 |
| chrisl | henrys: well, we don't *know* he can't use PCL...... | 14:00.47 |
| henrys | kens2: of 695387, I ran the file with PDFDEBUG saw font operators and the fonts on the page were a mess so I guessed there were font or language problems | 14:02.07 |
| kens2 | henrys there are font operations, but all (as far as I can see) in text renderig mode 3. The 'text' on the page is all part of the messed up JPX image | 14:02.37 |
| henrys | kens2: right | 14:02.49 |
| kens2 | If you fix the image, I think the output will look fine | 14:03.00 |
| henrys | kens2: itâs probably the interface somewhere given luratech gets the same answer, Iâll look | 14:03.30 |
| kens2 | If Luratech is the same, then it does sound like its not the decoder | 14:03.49 |
| chrisl | What's the output look like? | 14:04.00 |
| kens2 | I wonder if its another case where the JOX data is suppsed to override (or be overridden by) the PDF information | 14:04.22 |
| | chrisl looks like it has too many samples, the lines wrap round, with gaps between and in the wrong colour | 14:04.41 |
| henrys | kens2: Iâll double check luratech, Iâm relying on the customer for that. | 14:04.44 |
| | information | 14:04.56 |
| kens2 | Checking would be good I guess | 14:05.04 |
| chrisl | There are some color space edge cases we couldn't find examples for, so it might be one we guessed wrong | 14:05.20 |
| kens2 | It could be that. | 14:05.38 |
| | At first glance I thought it might be the wrong number of components | 14:05.53 |
| | colr is the colour box right ? | 14:06.52 |
| chrisl | Can't remember - it's ages since I looked at it | 14:07.25 |
| kens2 | This image doesn't seem to have too many boxes, I'll need to go consult the spec though | 14:07.40 |
| | looks like its sRGB | 14:10.23 |
| chrisl | Hmm, that should work.... maybe an alpha channel? | 14:10.58 |
| kens2 | Can't see one, but that proves nothing | 14:11.50 |
| | Hmm, its a 4bpc image according to the PDF file, that's unusual | 14:12.15 |
| | I wouldn't be surprised if that's causing a problem | 14:12.44 |
| chrisl | kens2: is that even allowed in JPX? | 14:13.46 |
| kens2 | Certainly, JPX can have a pretty much arbiotrary number of components and bit depths | 14:14.06 |
| | BPC ranges from -127 to +127 | 14:14.18 |
| chrisl | Hmm, I suspect we always assume 8bpc (or maybe 16bpc) | 14:14.45 |
| kens2 | It wouldn't surprise me ot be 8 | 14:14.54 |
| | I'm just struggling with decoing the ihdr box to see if the JPX agrees with the PDF | 14:15.13 |
| | Well it seems to say its 0.... | 14:16.00 |
| mattchz | kens2: seems to work okay for me with ndk-10 | 14:16.10 |
| kens2 | mattchz : OK thanks, then I don't understand the problem and will leave it to those better qualified | 14:16.35 |
| mattchz | let me check the bug report. | 14:16.47 |
| kens2 | chrisl ok so if BPC is 0 then it uses the JP2 header box <sigh> | 14:17.05 |
| chrisl | "The color components in an image may have different numbers of bits per sample. Any value from 1 to 38 is allowed." Really?? | 14:17.39 |
| kens2 | Yep | 14:17.46 |
| | Mad as a fish | 14:17.51 |
| chrisl | Absolutely bonkers | 14:18.04 |
| mattchz | kens2: iâm using a mac, mind. | 14:18.08 |
| kens2 | mattchz : I've no idea if that makes a difference, and I'm not in a position to try it myself.... | 14:18.29 |
| mattchz | Iâll a comment. The bottom problem is probably that he hasnât built the generated files. | 14:18.41 |
| kens2 | OK thanks | 14:19.01 |
| mattchz | oh, he says that was his mistake. | 14:19.33 |
| kens2 | Grr there is no BPC box. I wish I'd kept my jpeg2000 decoder..... | 14:19.36 |
| logikos | i'm using ghostscript from a ubuntu server to create many documents and then i will need to merge them together into a single pdf. incase someone prints the pdf with duplex i need to make sure each of the many documents have an even number of pages before they are merged into the final pdf | 14:22.25 |
| | there isn't some built in magical way to tell ghostscript to add blank pages to accomplish what I want is there? | 14:22.53 |
| kens2 | tURNING ON dUPLEX DOES THAT | 14:23.04 |
| | oops caps | 14:23.08 |
| | However, I'm pretty certain that Duplex only works with the rendering devices, not pdfwrite | 14:23.33 |
| logikos | is ps2write a rendering device? | 14:24.37 |
| kens2 | No | 14:24.43 |
| logikos | cause i could make them .ps 's then merge them .... | 14:24.48 |
| | ok | 14:24.49 |
| kens2 | Please note that taking a bunch of PDF files and running them through pdfwrite does not 'merge' them. It creates a new PDF file whose content is the marking operations from teh input files. This is not the smae thing as merging, none of the content is preserved. In general, its a bad idea | 14:25.33 |
| logikos | so useing pdfwrite i can not tell ghostscript to add a blank page if the page count is odd? to make it even? | 14:25.47 |
| kens2 | I can't htink of any way offhand, though you could modify pdfwrite to do so. | 14:26.18 |
| henrys | mad as a fish - never heard that one before | 14:27.39 |
| kens2 | How about 'mad as cut snakes' ? That's an Aussie one | 14:28.02 |
| rayjj | kens2: I just posted a question on bug 695394 about the performance issue also on bug 695396. Let me know. | 14:28.03 |
| chrisl | JPEG2000 tends to inspire the search for new ways to describe insanity..... | 14:28.28 |
| kens2 | rayjj if its a different problem it should have a different bug report. | 14:28.29 |
| rayjj | kens2: right, sorry. The question is whether I should open a new customer bug, or just change the title on that one | 14:29.07 |
| kens2 | Given that we are trying to persuade the customer to use MuPDF< I'm not inclined to treat it with any degreee of urgency | 14:29.18 |
| rayjj | was lazy in adding both to one bug last night | 14:29.29 |
| kens2 | I think (given that I closed that one as a duplicate) a new enhancement request is probably in order | 14:29.55 |
| henrys | kens2: havenât heard that one either but itâs not as odd as the other | 14:30.02 |
| kens2 | :-) | 14:30.08 |
| rayjj | kens2: the problem is that (1) mupdf doesn't support splitting pdf's (yet) and (2) the customer uses pdf2ps and has complained about the speed on this file | 14:30.47 |
| kens2 | rayjj does the file complete ? If so then its an enhancement | 14:31.06 |
| | to make it faster | 14:31.13 |
| | I have so many new bugs and problems to deal with I don't expect I'll get to it any time soon | 14:31.48 |
| rayjj | kens2: to make it more clear, I'll try ps2write, and see how long it takes and open a new bug. | 14:32.06 |
| kens2 | OK | 14:32.15 |
| | Frankly processing multi thousand page files is daft too | 14:32.43 |
| rayjj | kens2: I understand, and unfortunately since we are working through HCL, we don't know how important these actually are to cust 534 :-( | 14:32.58 |
| kens2 | Well if they are important to the customer, they can contact us direct and let us know | 14:33.20 |
| chrisl | It's inevitable that pdfwrite (and thus ps2write) will get slower as the size of the input increases....... | 14:34.27 |
| rayjj | kens2: in the "real world" of business class printers, such massively large PDF's aren't uncommon. I've seen 30,000 page files, but this is the first I've seen for ps2write. | 14:34.30 |
| henrys | rayjj: really not part of the design intent of the high level devices. If they must use ps2write something mupdf/pdftk should split the file into pages first. What do you think kens? | 14:37.09 |
| rayjj | kens2: this file seems to run fine, at a consitent 10 pg/sec(which is a bit slow, but tolerable), but then it drops to 1 pg/sec at one point. I'll also check what happens if I start at with a page after the slowdown. | 14:37.10 |
| chrisl | rayjj: that kind of change hints at overflowing some file/memory cache or other | 14:38.08 |
| kens2 | Peter reported more or less the same problem, it does not occur for me with his file, but it turned out he was using an ancient version of Ghostscript. As chrisl says, the way pdfwrite and ps2write works a slowdown as file size increases is totally inevitable | 14:38.22 |
| rayjj | henrys: that does make some sense. It's a bit frustrating that we can't talk to the actual customer, so getting them to switch tools in their workflow may be difficult | 14:38.27 |
| | henrys: kens2: BTW, I did try using pdftk "burst" to split the file into pages and that takes 45 seconds for 3001 pages | 14:39.07 |
| kens2 | I'm not surprised, since it doesn't actually do any processing of the content. I keep telling people that using pdfwrite for this is a really Bad Idea | 14:39.38 |
| henrys | and mupdf really should do that anyway. tor8 would that take long to do? | 14:39.54 |
| | best not to refer them to pdftk | 14:40.57 |
| kens2 | OK so now I get the CharProcs out too. Acrobat won't use the font, but hey, close enough.... | 14:43.28 |
| rayjj | henrys: also a concern with mupdf's "spliting" is that its pdf device (that emits the PDF) gives errors and warnings for every page that are a concern: | 14:43.33 |
| | error: pdf device supports only base 14 fonts currently | 14:43.35 |
| | warning: Ignoring error during interpretation | 14:43.36 |
| tor8 | henrys: mupdf already can split pages from one pdf | 14:44.49 |
| | mutool clean takes a page range to preserve, and deletes all other pages | 14:45.11 |
| henrys | tor8: okay I thought rayjj suggested it didnât | 14:45.38 |
| tor8 | we don't support merging pages from separate pdf files into one output though | 14:46.02 |
| henrys | rayjj, tor8: the fonts are definitely a proablem, if the error message is accurate | 14:46.33 |
| rayjj | tor8: henrys: I was trying (as marcos did) mudraw -o x.pdf in.pdf 1100-1300 | 14:47.08 |
| tor8 | rayjj: the mupdf pdfwrite device is like using the gs pdfwrite device | 14:47.13 |
| | mutool clean will copy the objects and content streams verbatim, without interpreting | 14:47.33 |
| | rayjj: henrys: mutool clean -g in.pdf out.pdf 1100-1300 | 14:48.41 |
| rayjj | tor8: can mutool "burst" a file into single page files ? | 14:48.56 |
| tor8 | rayjj: not in a single invocation | 14:49.20 |
| | doing that should not be too much work, it's just a matter of parsing the command line | 14:49.42 |
| rayjj | tor8: I had tried it without -g and it was taking 7 seconds to do a single page (or the 1100-1300 range). | 14:50.24 |
| tor8 | we could trigger on %[0-9]*d in the output filename | 14:50.29 |
| | rayjj: yeah, I noticed it was really slow now too | 14:50.41 |
| | it might be doing something stupid :( | 14:50.46 |
| rayjj | tor8: that sounds useful | 14:50.49 |
| tor8 | since robin isn't here to defend himself I'll blame him :) | 14:51.16 |
| rayjj | tor8: but with -g the time for a single page is 0.22 sec and for the 1100-1300 range it is 0.85 sec | 14:51.21 |
| tor8 | without the -g it's copying all the objects (even the now dangling page objects that aren't referenced) so that might be what's slow | 14:51.55 |
| | it still takes 1.3s with -g to copy 5 pages from pdfref17.pdf :( | 14:52.36 |
| rayjj | tor8: yes, that seems to be the case. With -g page 1 is 405 Kb. Without -g it is 1958 Mb ! | 14:54.21 |
| | tor8: note, however that gs pdfwrite output for page 1 is 12 Kb and pdftk is 16 Kb | 14:54.58 |
| tor8 | pdfwrite producing smaller files is not surprising | 14:55.23 |
| kens2 | Nice to hear some good news about pdfwrite for a change..... | 14:55.24 |
| tor8 | but I wonder what pdftk does | 14:55.27 |
| rayjj | but if we are just using it to pre-split for input to gs, that should be OK. | 14:55.35 |
| | kens2: :-) | 14:55.38 |
| | tor8: with -ggg mutool for a single page is 9 Kb (sorry kens2) | 14:56.25 |
| tor8 | rayjj: -gg should produce smaller files (but renumber all the objects) | 14:56.29 |
| kens2 | chrisl O.O bug 695397..... | 14:56.33 |
| rayjj | have to go now | 14:56.39 |
| tor8 | and -ggg is slow but tries to detect duplicate objects | 14:56.42 |
| chrisl | kens2: strange one.... | 14:57.06 |
| kens2 | Bizarre..... | 14:57.17 |
| | I'm just reading the commit | 14:57.25 |
| chrisl | Especially as I'm *sure* I tested Arial when I made those change before..... | 14:57.50 |
| kens2 | That actually works ? | 14:57.58 |
| chrisl | What, parsing out the uniXXXX names? Yes, it does | 14:58.18 |
| kens2 | I meant the 16 byte check | 14:58.35 |
| chrisl | Well, it now works for me | 14:58.57 |
| kens2 | How strange, I'm not sure that would have occured to me | 14:59.11 |
| | But thanks for fixing it :-) | 14:59.23 |
| chrisl | Well, that was the only set of changes I could think of since 9.14, so I started looking there | 14:59.42 |
| kens2 | Oh, 9.14 worked ? I must have missed that | 15:00.01 |
| chrisl | Jacek says so in the report | 15:00.27 |
| kens2 | Oh yeah, I was thinking of another bug | 15:00.38 |
| | Really odd bug | 15:00.52 |
| chrisl | kens2: oh, were you thinking of the bug with the wrong glyphs being printed? | 15:02.14 |
| kens2 | Yeah that's the one | 15:02.21 |
| | Waiting for a simpler test file there | 15:02.40 |
| chrisl | I didn't think that exhibited with rendering devices | 15:02.54 |
| kens2 | It probably doesn't, no. Using pdfwrite with an external TTF to replace a missing font in a PostScript file is pushing the boundaries | 15:03.38 |
| jogux | mattchz: I wonder if it's worth retrying that ndk 10 on linux and/or windows. I think that's been at least 3 reports of that same problem in the last week (2 bugs + at least one on stackoverflow) | 15:23.58 |
| kens2 | and people here in IRC also, at elast 2 (probably some of tehse people also raised bugs) | 15:24.26 |
| mattchz | yeah, it probably is. Iâd thought Iâd let the OP check with r9d first though, to save us time. | 15:24.29 |
| rayjj | kens2: The slowdown happens from page 1253 on because they are pages consisting of a single image 3840x2560 JPEG in ICCBased colorspace. Up to that point the pages are simple text. Note that the pages are also 3840.0 x 2560.0 points | 15:59.51 |
| | kens2: I guess we don't need to worry about it. | 16:00.21 |
| kens2 | So basically it gets slower because its processing immense amounts of data ? | 16:00.28 |
| | That doesn't sound like something we need to worry about/can do much about | 16:00.44 |
| rayjj | kens2: probably not. | 16:16.11 |
| | kens2: is there a reason that ps2write doesn't use DCT for images -- pdfwrite does and a single page of this image is 617 Kb. ps2write is using LZW A85 and the file is 12 Mb | 16:17.18 |
| kens2 | Offhand I can't remember | 16:17.41 |
| rayjj | kens2: I thought that JPEG was standard Level 2 PS | 16:17.42 |
| kens2 | I'm not certain, it might have been an addition | 16:17.58 |
| rayjj | kens2: I just checked -- it's in the Adobe PLRM-2nd | 16:18.55 |
| kens2 | It seems to be standard level 2 | 16:18.56 |
| | You cna probably meddle with the colorfilterstrategy if you want to test it | 16:19.29 |
| rayjj | kens2: probably because of the amount of data written, ps2write takes 8.7 sec vs. 2.8 for pdfwrite | 16:20.02 |
| kens2 | Well, the amount of data woul likely be a factor, yes | 16:20.22 |
| rayjj | kens2: I may fiddle with it, but I'll leave you alone | 16:20.24 |
| | kens2: I just added the comment to the RESOLVED DUPLICATE bug so we don't lose track and I'll go back to other work | 16:22.23 |
| kens2 | OK thanks. | 16:22.33 |
| dlskidmore | I'm having trouble downloading from http://downloads.ghostscript.com/public. I appear to get the file fine, but when running the windows installer I get an integrity check failure. Same thing with the last four versions of the windows 32 bit installer. Co-worker had the same issue, so it's not my PC although it could be my network. | 19:14.03 |
| | Can anyone confirm if it's me or the server? | 19:29.42 |
| rayjj | kens: (for the logs): I spent a few minutes with grep and see why ps2write doesn't use DCT (at least I think so). It does images as inline images, and the stream setup only uses LZW or Flate for general streams, never DCT | 20:42.19 |
| Feras | Hello | 20:43.58 |
| 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. | 20:43.58 |
| Feras | so i'm planning to use ghostscript on my server where my clients will upload PDF files, do some optimization on these files and send it back to them, Now the question is: do i have to make my server's code available to my clients? | 20:47.15 |
| rayjj | Feras: Recent Ghostscript is licensed under AFGL (Afero GPL). Please see: https://www.gnu.org/licenses/why-affero-gpl.html | 21:04.24 |
| | The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run the | 21:04.25 |
| | program on a server and let other users communicate with it there, your server must also allow them to download the source code | 21:04.26 |
| | corresponding to the program that it's running. If what's running there is your modified version of the program, the server's users must | 21:04.28 |
| | get the source code as you modified it. | 21:04.29 |
| | Feras: but read the rest of the site about SaaSS | 21:05.53 |
| | Feras: First, I AM NOT A LAWYER, but generally as long as you aren't doing something that the user can do on their machine, given the ability to download the ghostscript that you use, then you are OK | 21:07.54 |
| | The goal of GPL (and AGPL) is to prevent "special modified versions" of GPL software being used, and the user having no way to get the source to what is used to do the work (gs file conversion, in this case) | 21:09.16 |
| Feras | so i'm using the AGPL version without modifications, sort of calling gs from java and executing some tasks on it. do i have to give my client the source of my web pages styles and web application ? | 21:09.45 |
| rayjj | Feras: As I Understand It (AIUI), no. As long as the tasks your web app is doing can be accomplished by the user on some other machine using the "stock" ghostscript. | 21:11.11 |
| | Feras: and you can even modify the Ghostscript you use as long as you make the source of the modified GS available under the AGPL (and tell users). | 21:12.15 |
| Feras | alright then, thank you for helping me to understand it | 21:12.37 |
| | i sure will if i modified it | 21:13.23 |
| rayjj | Feras: Now, it is polite to acknowledge Artifex Software AGPL Ghostscript so that users know who makes it. And you ARE required to tell people that it is AGPL licensed and make the license available to them | 21:13.48 |
| | Feras: and we appreciate it if it isn't buried in some fine print somewhere, so that when they are using Ghostscript, they know it (so you don't assume credit for it all) | 21:14.49 |
| Feras | oh absolutely i have no problem doing that | 21:15.24 |
| rayjj | Feras: generally, since you have to tell them where to get source for Ghostscript, you would probably be doing that anyway unless you want to mirror Ghostscript distribution. Then we will redirect all of the downloads to your mirror ;-) | 21:16.16 |
| | Feras: only about 1.6 Tb/mo if I remember correctly | 21:16.42 |
| Feras | LOL please don't | 21:16.50 |
| rayjj | Feras: that's why the ;-) -- we have lots of downloads as it is. | 21:17.21 |
| Feras | my confusion was opening my web application and exposing the way we handle accounts, logins and stuff like that | 21:17.41 |
| rayjj | Feras: and depending on what you server is doing, you may want to look at our other apps -- mupdf based mudraw and mutool that might be more efficient for what you do | 21:18.31 |
| | Feras: they are also AGPL | 21:18.41 |
| Feras | i'm very interested in mupdf, do you offer royalty free license? | 21:19.34 |
| rayjj | Feras: I understand about opening the web app. As I understand the AGPL, that is NOT the intent | 21:19.36 |
| | Feras: it is also AGPL, so as long as you abide by those terms, it is royalty free. The issue we've had there is folks porting it to Android or iOS and NOt meeting the AGPL terms | 21:20.48 |
| | Feras: if you are actually doing a business, we offer support contracts that give you priority on bug fixes and questions for either mupdf or gs | 21:22.16 |
| Feras | my question about mupdf is about the commercial license | 21:23.34 |
| rayjj | Feras: and we have commercial licenses for either that let you have customizations that are private (that include support) | 21:23.38 |
| Feras | is it per device license or you purchase it and and distribute as many copies? | 21:24.33 |
| rayjj | Feras: the AGPL mupdf is royalty free. The commercial mupdf (or ghostscript or ghostpdl, ...) licensed are not. The cost depends on the business model | 21:25.00 |
| | Feras: for cost of commercial license of any Artifex Software product, contact Scott.Sackett @artifex.com | 21:26.22 |
| Feras | i see, right now i'm looking at mupdf and another library(you pay a certain fee for one application with a certain package name) | 21:27.21 |
| | i'm trying to sort of understand if i can afford it :) | 21:28.06 |
| rayjj | Feras: Depending on what the other app (with the fee) does, mupdf and the toolkit _may_ be a better all in one approach. What does the other app do ? | 21:34.56 |
| | Feras: we (not me, actually) are continually adding features and functions to mupdf and libmudf and the tools | 21:35.59 |
| | Feras: Even if you need something we don't have, we like to know so we know what the needs are in the real world. Also, we develop faster than we document, so it may be that waht you need was added and just not documented yet | 21:38.02 |
| | Feras: and if you are willing/able to (not legally constrained from) telling us the other package and what terrms they have that will help our marketing (Scott and Miles) understand what the market is like. | 21:41.26 |
| | Feras: you can email Scott, or me (ray @ artifex.com) , or even sales @ artifex.com and we'd appreciate it | 21:42.21 |
| | Feras: and if you conform to the AGPL, then yo can afford mupdf or ghostscript, for sure | 21:43.11 |
| | Forward 1 day (to 2014/07/31)>>> | |
IRC Logs