| | <<<Back 1 day (to 2016/06/12) | 20160613 |
| psmlbhor | Hello. If I use Flate filter for encoding an image data, then is there any method by which a PS level 2 interpretor can decode it? | 06:00.57 |
| kens | psmlbhor : Of course you can use Flate in a level 2 PostScript program. Since PostScript is a programming language, all you need to do is write a Flate decompressor in (level 2) PostScript. | 06:54.36 |
| | Its a simple matter of programming | 06:54.48 |
| psmlbhor | kens, ok. That seems fair enough but a lot of work to do | 06:55.59 |
| kens | Yes, and probably it won't be very fast either. | 06:56.17 |
| psmlbhor | yes you are right. Thanks | 06:56.36 |
| Gaiseric_ | Hello everyone - first time joining this channel! Two quick questions: I'm using gs with "-sDEVICE=pdfwrite" and "-dPDFA=2" with a few PDFs as input (one for each invokation of gs). (1) does "-dPDFA=2" guarantee PDF/A compliance, or it needs anything else? I'm using a few other options, is it possible that they would create non-compliant documents? Or would gs complain? | 07:11.51 |
| kens | PDFA-2 does not guarantee a valid PDF/A file. Read the documentation in VectorDevices.htm for more detail | 07:12.31 |
| Gaiseric_ | And (2) Sometimes gs fails to process its input. Can I convince gs to automatically delete those files? They are often missing pages etc. The failure doesn't bother me so much, as long as I don't end up with incomplete files and accidentally delete the originals! | 07:14.14 |
| kens | Using other command line switches should not cause a problem, as any incompatible controls are disabled | 07:14.14 |
| Gaiseric_ | kens: Thanks! | 07:14.19 |
| kens | In answer to question 2, no, not without considerable work. You would eiother need to write some non-trivial code in PostScript or write some code to interface hrough the API and not use the default Ghostscript executable. | 07:16.15 |
| | If you set -dPDFSTOPONERROR and the input is PDF then you should not get an output file if an error occurs. The default for the PDF interpreter is to continue processing after an error, in order to miic the behaviour of Adobe Acrobat | 07:17.42 |
| Gaiseric_ | I'm already using a Bash script, I guess I could check the return code and delete the file myself? I'll also try -dPDFSTOPONERROR, looks very useful. | 07:19.48 |
| | I'm already using a Bash script, I guess I could check the return code and delete the file myself? I'll also try -dPDFSTOPONERROR, looks very useful. | 07:20.09 |
| | BTW, the line I'm using is the following: | 07:20.42 |
| | gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pdfwrite \ | 07:20.44 |
| | -dPDFA=2 -dCompatibilityLevel=1.6 -dEmbedAllFonts=true -dSubsetFonts=true \ | 07:20.44 |
| | -dCompressFonts=true -dCompressPages=true -dDetectDuplicateImages=true \ | 07:20.47 |
| | -sOutputFile="${OUTDIR}/${NEWFILE}.pdf" "${INPUTFILE}" | 07:20.50 |
| kens | If the input is PDF you will only get an error on sever cases, unless you set -dPDFSTOPONERROR but yes you can delete the files yourself | 07:20.51 |
| | You haven't supplied a pdfa_def.ps file, so at the very least you won't have an OLutputICCProfile, which is not legal for PDF/A | 07:21.28 |
| Gaiseric_ | Yeah, I noticed (was reading the page you pointed me to), but I have no idea regarding ICC. (Not that it would matter in practice, the documents contain no colored images... but yeah) | 07:23.50 |
| | But the rest of the options shouldn't hurt, right? | 07:24.12 |
| kens | No, shouldn't be any problem. But the ICC profile is a requirement of PDF/A | 07:24.33 |
| Gaiseric_ | I see | 07:24.39 |
| kens | Most of the options you have set are the default anyway | 07:24.53 |
| Gaiseric_ | Thanks, you are very helpful :D | 07:25.23 |
| kens | I think you will need to set a ColorConversionStrategy as well, in order to be certain that any RGB/CMYK data is properly converted to one of RGB or CMYK, and also to set the ProcessColorModel for other spaces | 07:25.56 |
| | Note that setting ColorConversionStrategy will set ProcessColorModel for you, you don;t need to do both. | 07:26.22 |
| Gaiseric_ | This is getting scary, I might just drop PDF/A for now - after all, I got started with gs yesterday just to feed some nice files into my e-ink reader! | 07:27.59 |
| | However I've always wanted to know about PDF/A, so what you wrote will definitely be useful in the future :D | 07:28.49 |
| kens | Its mostly not hard. PDF/A only supports colour dtaa in *either* RGB or CMYK, not both, so you have to decide which you want. Once you decide that, you supply either a CMYK or an RGB ICC Profile and that's pretty much it | 07:29.07 |
| | Ghostscript and the pdfwite device will take care of pretty much everything else for you, the only decision we can't make is which colour model to use. | 07:30.04 |
| Gaiseric_ | I have to say, I'm quite impressed - I looks to be a super-powerful tool (the advantage of using a proper programming language as a format, I guess) | 07:31.39 |
| | Very nice project. | 07:31.48 |
| kens | You are correct, using PostScript gets us some advantages, it does also have some disadvantages :-) | 07:32.11 |
| amrx | What is the news ? What did I miss. | 07:32.32 |
| | PostScript, now I know the news. | 07:32.57 |
| Gaiseric_ | kens: I'll give the ICC thing a try, and possibly return to bother you some more. Again, thank you very, very much :D | 07:33.14 |
| kens | No problem | 07:33.26 |
| Gaiseric_ | is seriously thinking that learning postscript some day would be a nice exposure to a different programming paradigm | 07:34.05 |
| halabund | Is there anything I could do to make Ghostscript run faster on _very_ small PS or PDF documents (with PDF output)? Currently it runs in 0.08 seconds. | 08:31.01 |
| kens | That's not really an easy question to answer, but given the time you are talking about, probably not. About the only thing you could do would be to set it up as a job server, so that it doesn't restart between jobs, which is likely to be where your time is going. | 08:32.00 |
| halabund | I guess this is mostly just the startup time. Iâm thinking along the lines of starting up once, and then processing multiple documents on demand. Is this possible at all, perhaps using Ghostscript as a library from C (if this is possible again)? | 08:32.14 |
| kens | Yes to both | 08:32.29 |
| halabund | OK, so the keyword to google for is âjob server"? | 08:32.31 |
| kens | It refers to the PostScript job server loop | 08:33.04 |
| | Which simply runs round a loop waiting for input, when it gets some it processes it. | 08:33.20 |
| | Given the way the pdfwrite device works, you start by setting up some *other* device, then as part of the job you switch to the pdfwrite device and configfure it, and run the job. | 08:34.11 |
| | When the job is complete you restore back to the job server loop, which unloads the pdfwrite device, causing it to flush its output. | 08:34.42 |
| | I'd suspect you would have to use the Ghostscript API to do this, or at least it would be easier to do so. Offhand I'm not sure how you would do it from the existing Ghostscript binary. | 08:36.04 |
| | I feel compelled at this juncture to point out the licence for Ghostscript, which is the AGPL. Creating a new C program which uses the Ghostscritp API will mean definitely you have to make your code available under the terms of the licence, or seek a commercial licence instead. | 08:37.35 |
| halabund | I have no problem with *wanting* my code AGPL, but there is a little issue about whether I *can*. I must run but Iâll ask later ... | 08:43.02 |
| tor8 | Robin_Watts: ping? | 09:09.00 |
| | regarding the TIFF loading; the xps tiff loader in XPS sets EarlyChange and FirstBitLowOrder for tiff version 5.0 | 09:13.35 |
| | I'm not sure we supported those for our LZW filter, but I know that sebras extended mupdf's LZW to support FirstBitLowOrder (a.k.a. reverse) for GIF support | 09:14.12 |
| | this deal with 1024 codes rather than 512; you sure you're not just seeing the effects of EarlyChange? | 09:15.05 |
| | because I see now that we don't do the test for tiff version in mupdf's tiff loader | 09:15.28 |
| Robin_Watts | tor8: Hi. | 09:19.37 |
| | No, it's definitely not enough to do early change. | 09:19.55 |
| | In TIFF 6.0, you are required to send a CLEAR code as the next code when you hit the end of 12 bit codes. | 09:20.24 |
| | I have an example file where they continue to send new codes. | 09:20.37 |
| | (though obviously they are not used). | 09:20.46 |
| | Running yesterday, I thought of a nicer way of handling it than the 1024 extras. | 09:21.03 |
| | I'm going to try that now. | 09:21.06 |
| | So, by all means, please look at the commits on robin/master, but the TIFF one is subject to change. | 09:21.38 |
| tor8 | Robin_Watts: I wonder ... we might be able to tweak our PAM output to be able to do MAXVAL 1 (instead of MAXVAL 255) and strip muraster down to only one output format | 09:34.44 |
| Robin_Watts | tor8: Lots of pam readers don't support MAXVAL != 255 | 09:35.05 |
| tor8 | though I suspect the usefulness will drop radically, I wouldn't count on 1-bpc PAM support existing in any readers | 09:35.14 |
| | given how thin PAM support is in general | 09:35.24 |
| jogux | welcome back tor8. not urgent but could you give an opinion on http://git.ghostscript.com/?p=user/joseph/mupdf.git;a=commitdiff;h=ea173763a01a64f082378bd319e549cff5693d52 when you have time please? the --gc-sections upset the OS X linker. | 09:40.46 |
| Robin_Watts | Yeah, there is a bug open about that. | 09:42.40 |
| | (opened over the weekend by a user) | 09:42.51 |
| jogux | Robin_Watts: ah, ta. I've updated the commit message to reference the bug number then: http://git.ghostscript.com/?p=user/joseph/mupdf.git;a=commitdiff;h=2777fb92d7f4a6617ba5d83868d8597b7bac3465 | 09:47.42 |
| tor8 | jogux: LGTM | 09:48.27 |
| jogux | great, thanks tor8! | 09:48.44 |
| daren | hi everyone! may i ask you for some help? i've just downloaded a MuPDF from http://git.ghostscript.com/?p=user/robin/mupdf.git;a=tree and opened a Visual Studio project, that is included. the problem is - it won't build. i read a readme file, that had a note abound thirdparty libs, that should be present. i assume, this is the problem, why i get linker errors. but could anyone please clearify, if i should try and find things like | 09:49.54 |
| | i've done something wrong already | 09:50.03 |
| Robin_Watts | daren: You've used the 'snapshot' option there? | 09:50.19 |
| daren | thank you in advance for you time | 09:50.19 |
| | yes | 09:50.24 |
| Robin_Watts | That doesn't give you the thirdparty libs, which are git submodules. | 09:50.35 |
| | Instead, use git. | 09:50.44 |
| | git clone --recursive git://git.ghostscript.com/mupdf.git | 09:51.08 |
| kens | On Windows, you will need to install Git first | 09:51.10 |
| daren | Robin_Watts: ok, thanks | 09:51.11 |
| | yeah, i've used git before | 09:51.26 |
| kens | Ah, No problem then | 09:51.33 |
| halabund | kens: Regarding AGPL: What if my code compiles to a shared library which then gets loaded by a closed source application as a sort of âpluginâ? I have no problem making my own code AGPL. But the closed source program is not mine and I have no control over it. | 10:15.11 |
| kens | But, they would be required to abide by the AGPL (its viral in that sense) | 10:15.47 |
| | So they would have to publish their code, or get a commercial licence from us, *and* from you | 10:16.06 |
| halabund | kens: To clarify: I am working on an (open source) Mathematica package. Mathematica is a closed source programming language. This would introduce a binary component into my package (which so far is pure interpreted Mathematica code and calls Ghostscript as a separate process). | 10:17.40 |
| | I donât interact with the makers of Mathematica. I just made a package for personal use, which I then published as open source so others can use it, and now Iâm trying to improve performance. | 10:18.23 |
| kens | OK so in order to use GS you need to put your code under AGPL | 10:18.43 |
| halabund | Thatâs not problem. Itâs now MIT-licensed, it might as well be AGPL. | 10:19.02 |
| kens | Now, if your code isd then called as a process by another application, that's 'probably' OK (caveat , I am not a lawyer, if in doubt you *must* seek expert legal opinion) | 10:19.32 |
| | If the other package links to your package (ie its not a process bu, sy | 10:19.48 |
| | say a shared object | 10:19.54 |
| | Then the package doing the linking must also be AGPL, or use a commercial licence | 10:20.18 |
| halabund | Even if the other program is not distributed together with mine? | 10:20.31 |
| kens | Well clearly the publishers of that package aren't resposible for what you add | 10:21.15 |
| Robin_Watts | halabund: You'd clearly be fine if it was the LGPL. | 10:21.27 |
| kens | But if anyone distributes the code, they havce to abide by the AGPL | 10:21.28 |
| | It sounds to me, in this case, that you are 'probably' OK, but I'm no expert | 10:22.05 |
| Robin_Watts | And AIUI, the AGPL vs GPL differences make no odds in your case. | 10:22.07 |
| kens | True | 10:22.13 |
| Robin_Watts | So the question is is the GPL OK with your usage. | 10:22.17 |
| tor8 | linking GPL code as a plugin to closed source applications is a bit of a gray area | 10:22.47 |
| | gnu.org makes the distinction between fork/exec type plugins (which they state is okay) and dynamically loaded code (which they state is not okay) | 10:23.53 |
| Robin_Watts | so by that reckoning halabund is OK. | 10:24.14 |
| halabund | Well, mine would be dynamically loaded ⦠| 10:24.44 |
| tor8 | halabund: since the ghostscript binary (which is what is covered by the GPL) is called by fork/exec all should be good. to play "nice" with the GPL, having *your* code be open source as well would be a nice display of good faith, IMO | 10:25.51 |
| Robin_Watts | So not as a separate process then, as you said before? | 10:25.52 |
| halabund | The host application has another API, so I have the option to make my âpluginâ run in a separate process. But then the âpluginâ would have to rely on a closed source shared library again. This shared library would never be distributed together with the plugin. It would be expected to be present on the usersâ system. But it would definitely be required. | 10:25.54 |
| kens | If you can make your code run as a process, then I believe there is no problem, if it is a .so then I think that could be problematic | 10:26.59 |
| tor8 | halabund: gs <-(fork/exec)-> your plugin code <-(shared library)-> Mathematica is the architecture, as I understand it. correct me if I'm wrong. | 10:27.07 |
| | if it's gs <-(shared library)- | 10:27.24 |
| Robin_Watts | tor8: AIUI, it's perfectly fine to have a bit of code as the plugin (either closed or open source), as long as all that does is call ghostscript as a separate process. | 10:27.27 |
| tor8 | if it's libgs.so -(shared library)- your plugin + mathematica closed source library -(fork/exec)- mathematica, then that would not be okay | 10:28.08 |
| | Robin_Watts: yes, exactly. | 10:28.47 |
| | as long as 'gs' is in its own process, you're safe | 10:28.54 |
| Robin_Watts | tor8: Updated commits on line. | 10:31.21 |
| halabund | Right now Iâm calling gs as a separate process. Earlier today I asked here if there is any way to reduce the latency of calls. Right now it takes 0.08 s, which seems short, but adds up ⦠kens suggested to set Ghostscript up as a job server. My understanding was that this would require using it as a shared library, but itâs not clear yet | 10:31.33 |
| Robin_Watts | halabund: No, you can still do that as a process. | 10:31.57 |
| halabund | tor8: Are you the guy who made Gargoyle, the interactive fiction player? I had a lot of fun with that program many years ago :) | 10:32.01 |
| kens | It ought to be possible to start a GS job servere process, send jobs to it, and shut it down, all from external input. But not (I htink) with the standard executable. | 10:33.09 |
| | The inter-process communication is the tricky part there, along with setting up the server loop, and configuring GS for each job | 10:33.57 |
| Robin_Watts | kens: So driving it via stdin and stdout is not enough ? | 10:34.37 |
| tor8 | halabund: yes, that was me! glad you enjoyed it :) | 10:34.53 |
| kens | Robin_Watts : you would need some way to kill it, and to reconfigure it, because pdfwrite doesn't flush at the end of job | 10:35.30 |
| Robin_Watts | kens: Can it be made to flush by feeding it appropriate PS commands ? | 10:35.58 |
| kens | I guess you ocould do it with stdin, it would mean sending a deal of PostScript statup for each job | 10:36.14 |
| tor8 | Robin_Watts: all but the TIFF stuff LGTM | 10:36.30 |
| kens | You can close GS by sending 'quit' | 10:36.34 |
| tor8 | Robin_Watts: the sgi stuff, is that from gs? | 10:36.39 |
| | Robin_Watts: there are some libmupdf.vcproj changes in the TIFF SGI LUV commit | 10:37.02 |
| Robin_Watts | tor8: Yeah, stolen from libtiff (and bent into shape) | 10:37.06 |
| kens | However, there is no way for a PostScript interpreter to know when a program finishes | 10:37.08 |
| | finishes input that is | 10:37.13 |
| | SO you need an EOJ token | 10:37.20 |
| Robin_Watts | tor8: Yeah, 2 files swap order in the xml for some reason. | 10:37.20 |
| kens | Normally that's a controlD (0x04) but I'm not certain if we actually process that. | 10:37.42 |
| tor8 | Robin_Watts: I probably put them in the wrong alphabetic order when doing the original commit | 10:37.46 |
| kens | Ray is the expert on running GS as a job server | 10:37.51 |
| tor8 | Robin_Watts: it's got weird stuff with floating point constants | 10:38.13 |
| Robin_Watts | tor8: Yeah, lifted from libtiff. | 10:38.27 |
| tor8 | (float)0.228352 in the table ought to be 0.228352f | 10:38.29 |
| | and all the double constants should be 'f' suffixed | 10:38.38 |
| Robin_Watts | ok. | 10:38.41 |
| tor8 | at least that's what we do everywhere else to avoid double precision floating point math | 10:39.05 |
| kens | OK according to the docs, if you specify -dJOBSERVER then you cna use 0x04 (control-D0 to start a new encapsulated job | 10:39.43 |
| tor8 | Robin_Watts: the gxps code loads 5.0 tiffs with earlychange and reverse-bits but the muxps code doesn't ... or I'm being confused | 10:40.22 |
| Robin_Watts | The gxps code loads 5.0 tiffs with early change and reverse-bits. | 10:40.53 |
| | This is enough to make 'some' 5.0 tiffs work. | 10:41.02 |
| | I have an example of a 5.0 tiff that this is not enough for. | 10:41.12 |
| | So I have just committed a fix to the gs code inspired by the code in libtiff to solve that. | 10:41.40 |
| tor8 | Robin_Watts: okay. and libtiff uses this old_tiff flag hack? | 10:42.00 |
| kens | SO what you woudl do is start GS with -dJOBSERVER then send each job to stdin,starting with PostScript to configure the device, and ending with a 0x04 to terminate it. To shut GS down you would send a 'quit', pssibly that would need to be preceded by 'serverdict begin 0 exitserver' to terminate the job server loop I beleive that should all work with the standard executable, at least on Lnux though I can't see a reason why it wo | 10:42.06 |
| | uldn't work on Windows. According to the docs, if you use -dJOBSERVER you *must* use stdin | 10:42.06 |
| Robin_Watts | The same change, along with the earlychange/reversebits stuff is now in my commits for mupdf. | 10:42.12 |
| | No. libtiff doesn't differentiate between old and new style schemes. | 10:42.36 |
| tor8 | Robin_Watts: ah, yes. now I see where you moved the old_style flag to fz_open_lzwd | 10:42.49 |
| Robin_Watts | But I REALLY don't want to change the behaviour of lzw streams for PS/PDF etc. | 10:43.05 |
| tor8 | s/old_style/old_tiff/ to stay consistent? | 10:43.17 |
| Robin_Watts | hence I have a specific 'old_tiffs' flag to adjust behaviour. | 10:43.20 |
| tor8 | otherwise, LGTM | 10:43.22 |
| Robin_Watts | Sure. | 10:43.30 |
| tor8 | Robin_Watts: yeah, changing slzwd for gs would be scary... | 10:44.03 |
| Robin_Watts | tor8: I've just done that, but behaviour should be identical when that flag isn't set. | 10:44.42 |
| tor8 | for mupdf we could change the behaviour and test and see; but going with the extra flag is probably safer | 10:44.44 |
| Robin_Watts | For gs, you could write a postscript program that relied on the behaviour of the failure being in spec. | 10:49.00 |
| | tor8: Updated tiff commits to address your concerns. | 11:21.42 |
| | tor8: I want to do some more work on muraster. | 12:12.55 |
| | I'd like to remove a load of command line flags. | 12:13.07 |
| | and have more #defines. | 12:13.18 |
| | If you're setting up a printer, you probably don't want to be able to define stuff on the command line. | 12:13.43 |
| | I'd like to have #defines for: 1) the maximum amount of memory in your system (which will be used to set the max store size). | 12:14.34 |
| | 2) The number of cores in your CPU (which will be used for render threads). | 12:14.45 |
| | 3) The minimum number of rows to use for banding (the number of nozzles in your ink head). | 12:15.11 |
| | Then have the code try to print as best it can based on those variables. | 12:16.22 |
| | oh, and also 4) The maximum resolution to use, 5) the maximum printable width supported. | 12:17.04 |
| | We'd calculate band sizes to be a multiple of the minimum size. | 12:17.34 |
| | We'd aim for (say) 1/8th of the memory to be used for band buffers (divided between render threads). | 12:18.04 |
| | then if we run out of memory drop back to single threaded rendering, then smaller band buffers, then reinterpreting the file to minimal buffers to avoid the display list overhead as required. | 12:18.51 |
| tor8 | Robin_Watts: okay. can we make the #defines use functions that return actual true values on linux/windows? | 12:22.13 |
| | and pick a reasonably large defaults for 3, 4, and 5 | 12:22.44 |
| Robin_Watts | Possibly. Not sure how I'd implement that. | 12:22.48 |
| | The point of muraster is to give potential customers something they can just 'configure and go'. | 12:23.11 |
| tor8 | on linux there's /proc/cpuinfo and /proc/meminfo | 12:23.16 |
| Robin_Watts | Right, except if I was building a printer based on linux, I might miss out /proc from the kernel for space reasons - you can do that, right? | 12:24.07 |
| | but yes, in the absence of a #define I could read from there. | 12:24.56 |
| tor8 | Robin_Watts: not sure, I think a lot of system tools depend on /proc/* stuff being there | 12:25.34 |
| | of course, on *BSD I wouldn't count on /proc | 12:25.53 |
| malc_ | Robin_Watts: man 3 get_nprocs (that said the get_nprocs implementation might itself depend on presence of procfs) | 12:30.52 |
| tor8 | Robin_Watts: malc_: in the absence of procfs, it's perfectly possible for an integrator to just put a text file with the desired values in /proc/cpuinf | 12:33.37 |
| malc_ | tor8: yes, you are in a lucky position of actually having some sort of control of the installation site | 12:36.17 |
| Robin_Watts | I still reckon I prefer the idea of allowing integrators to tune it directly. | 12:37.37 |
| tor8 | Robin_Watts: of course. #ifndef MURASTER_CPU_COUNT etc | 12:38.41 |
| ts1690 | hey again peeps, am trying to compile mupdf in windows 7 64 bit in vs 2012. any suggestions, getting a number of warnings which should be ok eg size_t to int but specifically getting final link errors relating to no libfonts.lib, so i looked and it hasnt created an x64 platform for that project but has for the rest except also jni too. any ideas? | 13:04.23 |
| | ok think have sorted it. it wouldnt let me add x64 to project becase 'create new platform' was ticked too | 13:15.50 |
| | @ Robin & ray: some things I had to do to make it compile x64 on windows vs2012: | 13:37.07 |
| | 1. libfonts and jni didnt have x64 platform options so i added them under build configuration also generated was set to win32 so changed it to x64. | 13:37.16 |
| | 2. mutool couldn't find mujs.h because it needed additiona include directory ;..\..\thirdparty\mujs | 13:37.19 |
| Robin_Watts | jni doesn't matter. Nor does generated. | 13:37.34 |
| | nor does libfonts. | 13:37.40 |
| | mutool change is required though, thanks. | 13:37.56 |
| ts1690 | oki was just fyi | 13:37.59 |
| | ;) | 13:38.04 |
| Robin_Watts | Appreciated. | 13:38.09 |
| ts1690 | please thanks for writing the best pdf lib out there! | 13:38.29 |
| | pleasure* | 13:38.36 |
| | ciao for now | 13:38.43 |
| | \o | 13:38.45 |
| rayjj | Robin_Watts: muraster doesn't need to pre-define the band size when creating the display list, right? (as gs does) | 15:03.24 |
| Robin_Watts | rayjj: Indeed not. | 15:03.37 |
| | In mupdf the display list is resolution independent. | 15:03.58 |
| rayjj | so why limit the band size to 1/8 the memory -- that seems like it would lead to small bands | 15:03.59 |
| Robin_Watts | rayjj: Well, the competing things for memory are: | 15:04.19 |
| | 1) The file itself. | 15:04.25 |
| | 2) The structure of the file that we load into mupdf. | 15:04.49 |
| | 3) The resources (images/fonts/etc) that we decode from that file. | 15:05.06 |
| | 4) The display lists. | 15:05.12 |
| | 5) The rendered bands. | 15:05.26 |
| rayjj | and for a "real" printer, it would be nice to be able to tell muraster the available memory when starting a job, since diskless printers may have the PDF in RAM (which varies the amount left for muraster) | 15:05.28 |
| | Robin_Watts: so the biggest rather unpredictable thing is fonts or images that get loaded from the file whilst processing into a band | 15:06.43 |
| Robin_Watts | 6) Transparency buffers. | 15:06.59 |
| | Yes. | 15:07.05 |
| rayjj | oh, yeah -- transparency buffers are a big "gotcha" | 15:07.22 |
| Robin_Watts | Hence I'm trying to aim for a system that falls back gracefully to smaller and smaller bands, and will eventually abandon bgprint/num render threads and even display lists in order to get a print out. | 15:08.15 |
| rayjj | I assume you don't pre-scan for transparency buffer depth or colorspace | 15:08.56 |
| Robin_Watts | It's all very well us telling customers "Sure, MuPDF can cope, you just need to drive it cleverly". The aim here is to give them something that has the cleverness in, and that should be close to being what they need. | 15:09.31 |
| | In muPDF all transparency is rgb. | 15:09.47 |
| rayjj | Robin_Watts: I'd recommend falling back from multiple render threads BEFORE changing band size since the band you need next might fit | 15:09.48 |
| Robin_Watts | rayjj: Yeah. | 15:10.03 |
| | I plan to drop bgprint first, then num render threads, then shrink the band height. And only if the band height hits the minimum will I ditch the display list. | 15:10.53 |
| rayjj | Robin_Watts: yes, more like gs that hides some of the complexity (falling back on band size and multiple threads). Of course, gs is somewhat more predictable during rendering | 15:11.38 |
| Robin_Watts | gs is more predictable for things like images because it (by and large) decodes them line by line. | 15:12.17 |
| rayjj | ditch the display list and render into a minimal band directly from the input file, rihgt | 15:12.22 |
| Robin_Watts | but for stuff like jpx it doesn't. | 15:12.25 |
| | And even then predictability goes out the window if you set flatness down and start stroking wide curves. | 15:13.13 |
| rayjj | but rendering stage from the display list is never from the original (compressed) image, so JPX/JPEG etc. is during parsing | 15:13.23 |
| Robin_Watts | so no solution is perfect. | 15:13.30 |
| | rayjj: jpx images never make it into the clist? | 15:13.57 |
| rayjj | compared to transparency buffers, paths are not a proble, | 15:14.02 |
| | Robin_Watts: right -- gs clist has simple images, not the original | 15:14.31 |
| Robin_Watts | rayjj: Right, so clists can be huge then. | 15:14.57 |
| rayjj | Robin_Watts: yeah, but we can dynamically fall back to compressing the clist | 15:15.40 |
| Robin_Watts | losslessly recompressing jpegs will never get you the space back. | 15:16.06 |
| rayjj | and then if the compressed clist fails, we can fall back to banding from the input PDF | 15:16.07 |
| Robin_Watts | rayjj: Right, but gs doesn't currently do that fallback, right? | 15:16.22 |
| | Like I say, no single approach here is perfect in all circumstances. | 15:16.38 |
| rayjj | (that last is *not* in standard code, but a big printer customer uses what I wrote for them to do that) | 15:16.49 |
| | cust 532 (we aren't on #artifex) | 15:17.14 |
| | I should probably put "pdfband.ps" into lib with a write up on using it | 15:18.03 |
| | Robin_Watts: it is hard to anticipate all needs, but it sounds like you have a reasonable set of "automagic" features | 15:19.16 |
| | ISTM that pre-scanning to see if the PDF uses transparency (as gs does) would be fairly easy and helpful in guessing the band size | 15:20.19 |
| Robin_Watts | We have a function to do that. | 15:22.12 |
| | I think gs divides the bandheight by 3 or something ? | 15:22.30 |
| | (in the presence of transparency) | 15:22.46 |
| | rayjj: I'm not imagining that I'll get this perfect first time, so we can tweak it. | 15:23.12 |
| | Forward 1 day (to 2016/06/14)>>> | |
IRC Logs