| | <<<Back 1 day (to 2015/10/15) | 20151016 |
| mvrhel_laptop | looks like the digital signing stuff is going to be pretty straight forward in windows. I won't need to use the openssl stuff | 01:55.07 |
| | this is for gsview | 01:55.16 |
| | successfully pulled out the signature and verified it with out too much trouble | 01:55.46 |
| kens | Ah another excellent piece of worj by Hin-Tak I see | 07:07.22 |
| ismail | Hmm is mupdf 1.8 out? | 07:24.49 |
| | https://freshcode.club/projects/mupdf claims so but I can't find a tarball | 07:25.40 |
| kens | I don't believe that site is anything to do with us, and as far as I'm aware, no,it isn't released yet | 07:26.19 |
| ismail | yeah weird, they usually don't make up news about new releases like this :) | 07:27.05 |
| kens | THere *will* be a new release, but not yet | 07:27.22 |
| ismail | I know, I keep watching :D | 07:27.30 |
| lasse_ | Hi! Does anyone in here have any experience with creating PDF/A-1b valid documents with GS? | 08:20.55 |
| kens | Yes | 08:21.01 |
| lasse_ | I've been strugling with for a day now, and I can't seem to get a valid PDF document without using the deprecated -dUseCIEColor switch | 08:21.47 |
| kens | Works for me, are you using current code ? | 08:22.04 |
| lasse_ | I've been trying the 9.18 version | 08:22.19 |
| kens | Then that's current | 08:22.25 |
| lasse_ | Yes, would think so | 08:22.32 |
| | In the documents, it's assumed that I want to compile a PDF from a .ps file, but I'm converting from .pdf | 08:23.10 |
| kens | When you say you can't get a 'valid' PDF document I assume you mean you can't get a PDF/A-1b file which passes some validation process | 08:23.18 |
| lasse_ | Is the PDFA_def.ps necessary? | 08:23.23 |
| | Correct. | 08:23.28 |
| kens | The documentation does not assume PostScript input | 08:23.32 |
| | Yes PDFA_def.ps is absolutely essential | 08:23.43 |
| lasse_ | It's complaining about OutputIntent which doesn't have a icc-profiles | 08:23.56 |
| kens | Then you have not executed PDFA_def.ps, or not modified it correctly | 08:24.12 |
| lasse_ | Most likely the latter | 08:24.38 |
| kens | You can set teh color to one of RGB, CMYK or DeviceIndependent using the ColorConversionStrategy control | 08:25.03 |
| lasse_ | Do I need to alter the PDFA_def.ps that exists in the lib, or do I need to have it in the same directory as the pdf that I want to convert? | 08:25.04 |
| kens | If you use RGB or CMYK you must supply an OutputIntent profile | 08:25.15 |
| | lasse neither | 08:25.23 |
| | The file is supplied as an example, you must create a file which works for your setup. You can modify the one in lib if you like, or copy it and modify the copy. You supply the fully qualified path to Ghostscript. Its an input file to bexe executed in exactly the same way as teh PDF file you want to work on | 08:26.16 |
| kens | continues form above | 08:26.46 |
| lasse_ | So I have to provide the whole path to the PDFA_def.ps file? | 08:26.47 |
| kens | The OutputIntent is defined in PDFA_def.ps, which is why you *must* execute it | 08:27.01 |
| | Yes, you have to supply the full path tot he PDFA_def.ps file, just as you would for any other input file | 08:27.23 |
| lasse_ | Well, what would you reckon is the better option? | 08:28.01 |
| | Device-independent or colors with OutputIntent? | 08:28.16 |
| kens | I have no idea, that depends on what you are trying to do | 08:28.23 |
| lasse_ | This is for archiving PDF documents | 08:28.24 |
| kens | I can't really decide that for you | 08:28.48 |
| | Whoever decided that PDF/A should be your archive format should define what flavour of PDF/A you want. | 08:29.22 |
| lasse_ | Agreed, but they don't seem to know much about the format, other than that is the format I am supposed to use. | 08:30.16 |
| | After Googling for a day, I suspect I more about it then they do. | 08:30.29 |
| kens | NB even if you don';t want an OutputIntent you still must execute PDFA_def.ps because it does other things too, which are also essential | 08:30.32 |
| lasse_ | Okay, thanks. | 08:30.45 |
| kens | lasse_ then I suggest you pick somethign you like :-) | 08:30.45 |
| lasse_ | Hehe, yeah | 08:30.52 |
| | Since this is for digital archives, I suspect that Device-independent would be the way to go | 08:31.14 |
| kens | As I said, you'll stil have to run PDFA_def.ps, and teh output files might be larger (maybe) | 08:31.53 |
| | It depends on what the ionput is like. | 08:32.02 |
| lasse_ | Size is not an issue | 08:32.03 |
| kens | Ah well, for some people it is :-) | 08:32.13 |
| lasse_ | It's all about preserving quality | 08:32.21 |
| kens | You will need to be very caregful with images then | 08:32.46 |
| | Ensure you are not using JPEG compression on the output file | 08:32.55 |
| lasse_ | I've been battling jpegtran the past week to be able to rotate any picture without resampling the picture, because they want no loss of quality | 08:33.02 |
| | Ah, I though ghostscript didn't resample jpgs in the process? | 08:33.22 |
| | thougt* | 08:33.28 |
| kens | It doesn't. But it has to decompress the input, if you then write that back out as a JPEG, it gets quantised again | 08:33.47 |
| | Not reasmpled, but quantised. | 08:34.02 |
| | THe effect is very poor quality | 08:34.10 |
| lasse_ | Oh, thanks for the heads up. What do I need to do to avoid this? | 08:34.26 |
| kens | You will need to fiddle with teh Color Image parameters to use Flate instead of JPEG as the output | 08:34.29 |
| lasse_ | That's within the PDFA_def.ps right? | 08:34.44 |
| kens | No, that's via the istillerparams PostScript operator | 08:35.02 |
| | The derfault is to use JPEG for minimum size | 08:35.14 |
| | See file:/ghostpdl/doc/Ps2pdf.htm#Options | 08:35.51 |
| | You will need to change ColorImageFilter | 08:36.47 |
| | From /DCTEncode to /lateEncode | 08:37.06 |
| lasse_ | Huh, can't see the /lateEncode option on the page | 08:37.28 |
| kens | Sorry /FlateEncode | 08:37.50 |
| | had overwrite set instead of isnert | 08:37.58 |
| | and its not on the doc page, its a standard PostScxript filter | 08:38.35 |
| lasse_ | So I need -sColorImageFilter=/FlateEncode? | 08:38.37 |
| kens | That might work | 08:38.47 |
| | I'd use -c "<</ColorImageFilter /FlateEncode>> setdistillerparams" -f | 08:39.12 |
| lasse_ | I've never written postscript before, so I like commandlines :P | 08:39.34 |
| kens | You can then stick any other setting in the dictionary (dicts are defined between << and >>) at the same time | 08:39.41 |
| | Not all the pdfwrite parameters can be controlled from the command line | 08:40.02 |
| | In particular NeverEmbed, AlwaysEmbed and ColorImageDict etc | 08:40.33 |
| lasse_ | Don't know what those do | 08:40.53 |
| kens | NeverEmbed and AlwaysEmbed control the font embedding (you cannot change those with PDF/A output anyway) and the Color/Gray/Mono ImageDict and ACSImageDict parameters affect the way images are written | 08:41.50 |
| lasse_ | But the /FlateEncode is the best option for my usecase, right? | 08:42.34 |
| kens | Its lossless, which is important if you want quality and 'might' have JPEG (DCTEncoded) input | 08:42.58 |
| lasse_ | It is very likely, yes | 08:43.08 |
| kens | Then you defintely want Flate, you will get quantisation artefacts otherwise | 08:43.25 |
| lasse_ | How much bigger is the filesize though? Just wondering | 08:43.53 |
| kens | Depends on the input | 08:44.00 |
| | It shouldn't be a whole lto bigger | 08:44.12 |
| lasse_ | Sounds good to me | 08:44.19 |
| kens | It *will* be somewhat larger though | 08:44.28 |
| lasse_ | As long as it's not 2-3X times the size | 08:44.36 |
| kens | You'll have to experiment, I can't promise anything | 08:44.48 |
| lasse_ | Yeah, true. I have to finish my system before I can get real data to test it with, so I really can't experiment that much at this point | 08:45.25 |
| kens | Except that you won't like the result of applying DCT to a data stream which has previously been quantised | 08:45.26 |
| lasse_ | Noted. | 08:45.39 |
| | Do you have any pointers about what I should change in the PDFA_def.ps file? | 08:46.09 |
| kens | You *must* set the OutputIntentProfile appropriately (it has to be correct for RGB or CMYK, or missing if you are using DeviceIndependentColro throughout) | 08:46.49 |
| | You can drop the Title and stuff | 08:46.58 |
| | ie the DOCINFO pdfamrk | 08:47.16 |
| lasse_ | I've read somewhere that the Title is mostly just a placeholder if the input document does not contain a title | 08:47.45 |
| kens | Actually I thnk you may be able to get away without it entirely if you go with DeviceIndependentColor | 08:47.51 |
| | lasse_ that's partially true | 08:48.11 |
| | It sets a Title, that will be overridden if the input specifies a different Title | 08:48.35 |
| | IIRC PDF/A files are required to have a Title | 08:48.50 |
| lasse_ | Yes, that's the way I understood it | 08:49.11 |
| kens | Though that might possibly be a reccomendation | 08:49.12 |
| lasse_ | Well, it's no harm in having it in the file though? | 08:49.28 |
| kens | No, it causes no damage, and will be overwritten should the input specify something else | 08:49.51 |
| lasse_ | Great | 08:49.57 |
| kens | checks the PDF/A-1 spec | 08:50.29 |
| lasse_ | I don't see any OutputIntentProfile to remove though | 08:50.58 |
| kens | Seems to be a 'should be' rather than a 'must be' | 08:51.06 |
| lasse_ | Well, I'll leave it be anyways | 08:51.26 |
| kens | Almsot everything in PDFA_def.ps is related to the OutputIntent | 08:51.29 |
| | Starting from % Define an ICC profile : to the end of file | 08:51.54 |
| lasse_ | Sorry, I'm not that good with the terminology here | 08:51.55 |
| kens | Oh, and including the '/ICCProfile (srgb.icc) % Customise' line | 08:52.28 |
| lasse_ | Yes, that's what I've changed it to. | 08:52.59 |
| kens | You don't need that line if you aren't writing an OutputIntent | 08:53.19 |
| lasse_ | Alright, I'll remove it then | 08:53.33 |
| kens | That line defines a key 'ICCProfile' whose value is a string (srgb.icc) | 08:53.39 |
| lasse_ | Alright, I'll remove it then | 08:54.07 |
| kens | That is used in the 'Define an ICC profile' section to create a stream in the output PDF file by opening a file with that name, and writing its contents into the output file | 08:54.18 |
| lasse_ | Is it anything different from "-sOutputICCProfile=srgb.icc"? | 08:54.19 |
| kens | Yes, quite different | 08:54.32 |
| | An OutputIntent is not an OutputICCProfile | 08:54.49 |
| | The OutputICCProfile is used when rendering | 08:55.02 |
| lasse_ | And OutputIntent is for compiling the PDF? | 08:56.46 |
| kens | No | 08:56.52 |
| | The OutputIntent is stored in the PDF file | 08:56.59 |
| | When the PDF is rendered, teh OutputIntent is consulted in order to convert the device-dependent colour specifications into a device-independent colour | 08:57.28 |
| lasse_ | I see | 08:57.56 |
| kens | Grrr | 08:58.33 |
| | As I was trying to say; | 08:58.40 |
| lasse_ | bad connection? | 08:58.42 |
| kens | If you use device independent colours, then you don't need to convert back from a specific device space to device-independent space, so you don't need the OutptuIntent profile | 08:59.09 |
| | Just had a network glitch of some kind | 08:59.17 |
| lasse_ | Yes, that sounds good. | 08:59.38 |
| kens | What the OutputIntent says is 'the colours in ths document were intended to be used 'as is' on ths particular device' | 08:59.39 |
| lasse_ | So if it says device-independent, all devices have to convert colors? | 09:00.19 |
| kens | To use on a different device, convert back to device-independent using these rules, then convert forwards to the destination device using whatever rules you already kow about for that device' | 09:00.21 |
| | lasse_ : all devices have to convert colours anyway | 09:00.33 |
| | The exception beign when they are in the correct device space already | 09:00.47 |
| lasse_ | Yes, then I understand | 09:00.59 |
| kens | But that is a non colour-managed workflow, and leads to poor colour reproduction | 09:01.03 |
| lasse_ | Don't want none of that. | 09:01.19 |
| | So, back to the PDFA_def.ps, what should I remove/alter? | 09:01.45 |
| kens | Like I sadi, you can remove everything | 09:01.59 |
| | Or just not execute it | 09:02.05 |
| | Providing that you are using device independent colour | 09:02.17 |
| lasse_ | Do you mean in the input files? | 09:02.33 |
| kens | NB unless you set the inptu profiles properly you will, in a sense, be lying about the output :-) | 09:02.38 |
| lasse_ | I do not know beforehand what kind of formats the PDF-s will be in | 09:02.57 |
| kens | That's usually the problem yes | 09:03.09 |
| | So they can contain a mixture of Gray, RGB, CMYK, calibrated spaces, and ICC profiles | 09:03.27 |
| lasse_ | I just hoped that ghostscript could convert the PDFs and make the colors device-independent | 09:03.31 |
| kens | It can, but...... | 09:03.39 |
| | Unless it knows what device(s) the Gray RGB and CMYK were intended for, it cna't know how to make them into a device-independent space. | 09:04.09 |
| | SO if you set -sColorConversionStrategy=DeviceIndependent then it will have to use its defaults | 09:04.28 |
| lasse_ | Done that, and that's when I encountered validity problems | 09:04.55 |
| kens | Which are pretty much guaranteed to be wrong. But no worse wrong than using the colours 'as is' or converting to a device space (RGB or CMYK) | 09:04.55 |
| | Wll if you have problems you can open a bug report and I'll look at it | 09:05.24 |
| | But you will need to supply an example file, a complete command line and be prepared to wait until I have time to look into it. | 09:06.00 |
| lasse_ | Hopefully it's not a bug, and I can get this to work without filing a report | 09:06.53 |
| kens | I cannot tell from what you;'ve said so far | 09:07.05 |
| | I can safely say that the DeviceIndependentColor setting is *much* less well tested than the RGB or CMYK settings. | 09:07.43 |
| lasse_ | Alright, noted | 09:08.00 |
| | I've encountered issues with CMYK though, where some pages of the PDF would turn full cyan | 09:08.22 |
| kens | I've a feeling there's a bug open against that somewhere | 09:08.40 |
| lasse_ | I tried to check the bug tracker, but I couldn't find anything related | 09:09.01 |
| kens | I've a feelign the title of the report is somewhat misleading | 09:09.17 |
| | But I can't immediatley see it at the moment, its possible I already assigned it to our colour expert | 09:10.00 |
| lasse_ | Alright. | 09:10.12 |
| | Since you recommend using CMYK/RGB, I do need to use the outputintents and DPFA_def.ps, correct? | 09:10.52 |
| kens | Yes | 09:11.02 |
| lasse_ | And what changes do I need to implement? | 09:11.12 |
| kens | You need to change the ICCProfile | 09:11.25 |
| lasse_ | to srgb.icc | 09:11.35 |
| kens | Well, not really | 09:11.42 |
| | That's if you want everything to be treated as if it were sRGB input | 09:11.55 |
| | And you have to set the output space to be RGB | 09:12.14 |
| lasse_ | Hmm... Well, it's most likely scanned documents | 09:12.16 |
| | So I guess CMYK would make more sense | 09:12.29 |
| | default_cmyk.icc ? | 09:12.39 |
| kens | Unlikely, scans are more normally in RGB | 09:12.41 |
| lasse_ | Oh, did not know that | 09:12.49 |
| kens | you can use our default profiles, but they won't be 'correct' | 09:12.55 |
| lasse_ | Should I use one of Adobes profiles perhaps? | 09:13.20 |
| kens | Same problem, they won;t be 'ciorrect' | 09:13.37 |
| lasse_ | I assume that the documents don't include .icc, so I have no chance of getting it right anyway | 09:13.50 |
| kens | THe only way to get colour controlled output is to put colour control in at every stage of the workflow | 09:13.54 |
| | ANd yes, you have no real possibility of getting it 'correct' after the facxt | 09:14.18 |
| | fact* | 09:14.22 |
| lasse_ | I can't guarantee this, since I also need to support user-uploaded PDF-s | 09:15.35 |
| kens | SO like I said, its going to be 'wrong' at least sometimes. | 09:16.04 |
| lasse_ | But it should be okay to use default_cmyk.icc? | 09:16.07 |
| kens | Up to you | 09:16.12 |
| lasse_ | Up to my employer, really | 09:16.20 |
| kens | I'd probably use RGB myself, if the input is likely to be scanned documents | 09:16.30 |
| | file:///D:/ghostpdl/doc/Ps2pdf.htm#OptionsRGB->CMYK->RGB (for viewing on screen) will introduce colour problems | 09:16.55 |
| lasse_ | default_rgb? | 09:16.56 |
| kens | Again, up to you. It should work, but I can't really reccomend it | 09:17.13 |
| | If quality is important you should really be using a colour calibrated workflow throughout | 09:17.38 |
| lasse_ | Alright | 09:18.23 |
| | Have to go to lunch now | 09:18.33 |
| | Thanks a bunch for the help so far | 09:18.40 |
| kens | NP | 09:18.51 |
| lasse_ | kens: You still here? | 10:37.03 |
| kens | Yes, sorry was working in another window | 10:41.36 |
| lasse_ | No problem | 10:42.52 |
| | I was wondering about the '/OutputConditionIdentifier' | 10:43.09 |
| kens | In PDFA_def.ps ? | 10:43.20 |
| lasse_ | Yes | 10:43.23 |
| kens | Yes ? | 10:43.52 |
| lasse_ | What kind of values do I have to choose from, and what should I choose for default_rgb | 10:43.54 |
| kens | Well really you should read the PDF/A spec :-) | 10:44.07 |
| lasse_ | As the internet meme says: Ain't nobody got time for that | 10:44.35 |
| | But, I guess you're right. | 10:44.48 |
| kens | Well, its what I'll have to do | 10:44.50 |
| | Actually you need the PDF spec | 10:45.10 |
| lasse_ | http://www.pdfa.org/2011/08/pdfa-%E2%80%93-a-look-at-the-technical-side/ | 10:45.29 |
| | This one....? | 10:45.33 |
| | It didn't look comprehensive enough | 10:45.41 |
| kens | Oh its just a human readable version of what the ICC profile represents | 10:45.44 |
| | lasse_ no that's not the spec | 10:45.54 |
| | The spec is an ISO standard | 10:45.59 |
| | You have to pay for it | 10:46.04 |
| | So to answer your question, it has to be a string (so delimited by '(' and ')') it should be human readable and shouldl describe the ICC profile you embedded | 10:46.51 |
| | From the PDF Reference: | 10:47.21 |
| | "A typical value for this entry would be the name of a production condition maintained in an industry-standard registry such as the ICC Characterization Data Registry (see the Bibliography)." | 10:47.22 |
| | "If the intended production condition is not a recognized standard, the value of this entry may be Custom or an application-specific, machine-readable name. The DestOutputProfileentry defines the ICC profile, and the Info entry is used for further human-readable identification." | 10:47.51 |
| lasse_ | Damn, this is getting advanced | 10:54.22 |
| | Right, so it's a human readable representation of the profile selected in /ICCProfile? | 11:00.54 |
| kens | A human readable description, not a representation (that wouldn't make sense) | 11:01.19 |
| lasse_ | ... yes, that's what I actually meant. | 11:01.38 |
| | Sorry, not a native speaker. | 11:01.47 |
| kens | And teh ICCProfile is just a variable in the PostScript, it ends up as the stream in the PDF file referecned by DestOutputProfile | 11:01.55 |
| | You're doing remarkably well if ths is your second language | 11:02.07 |
| lasse_ | Haha, thanks. | 11:02.19 |
| | Hmm.... yes, I can kind of see that. I'm not fully understanding the syntax of postscript yet, though | 11:04.14 |
| kens | A lot of what's going on in there isn't evern normal PostScript | 11:04.36 |
| | pdfmark is a PostScrip extension only understood by 'Distiller' type applications | 11:04.58 |
| | and it has its own separate rules | 11:05.08 |
| lasse_ | But for the ICCProfile, if I want to select other profiles I need to include the full path (as long as it's not in /usr/share/ghostscript/current/iccprofiles? | 11:05.13 |
| kens | http://www.bbc.co.uk/news/technology-34549042You need the full path yes | 11:05.24 |
| | No matter where it is | 11:05.36 |
| lasse_ | Hmm... shame that this script needs to be able to run on multiple computers, have to configure it for every computer then. | 11:06.46 |
| kens | Or store teh ICC profile you intend to use in a central location. | 11:07.14 |
| | Just a reminder; Ghostscript is licenced under the Affero General Public Licence, you might want to check and make sure you are conforming to the terms. | 11:07.50 |
| lasse_ | and mount the location to the machines? | 11:08.01 |
| kens | Well I was thinking of having a specified locatoin, but if that works for you...... | 11:08.27 |
| lasse_ | Your solution is probably better | 11:09.27 |
| | Will check the license | 11:09.30 |
| kens | Good grief, someone claiming to actually be using XPS (though admittedly, OpenXPS ;-) | 11:14.02 |
| lasse_ | Do not have much experience with that format | 11:15.01 |
| kens | Nobody does | 11:15.09 |
| lasse_ | I think I saw it and thought "Why do we need another format when we have PDF?" | 11:15.37 |
| kens | Becasue its not a Microsoft format :-) | 11:15.57 |
| lasse_ | Is PDF a M$ format? | 11:16.25 |
| kens | But MS have never really followed through with it, so its as nearly defunct as a live and used format can be | 11:16.27 |
| | No, PDF is an Adobe format | 11:16.34 |
| lasse_ | Oh, XPS | 11:16.35 |
| kens | Yeha XPS | 11:16.47 |
| lasse_ | Yeah, that's what I've always thought. Thought you were about to blow my mind | 11:17.02 |
| kens | No XPS is Microsoft saying 'we need to get into the codument interchange market, because people aren;t just using Word documents any more' | 11:17.34 |
| | And then totally failing to understand the market, or listen to the people they employed as consultants | 11:18.04 |
| kens | heads for lunch | 11:19.12 |
| lasse_ | Yeah, well... That's just Microsoft | 11:50.58 |
| | kens: I tried to run GS with the following command: ./gs -dPDFA=1 -dBATCH -dNOPAUSE -sColorConversionStrategy=/RGB -sDEVICE=pdfwrite -sOutputFile=out-a.pdf -dPDFACompatibilityPolicy=1 /path/to/PDFA_def.ps input.pdf | 11:53.48 |
| | The /ICCProfile is reffering to the default_rgb.icc, and the /OutputConditionIdentifier is set to (Default RGB) | 11:54.59 |
| | Still, when i try to validate the PDF (Using Apache PDFBox) I get a bunch of the following outputs: Invalid Color space, The operator "k" can't be used with RGB Profile | 11:55.23 |
| | I suspect the 'k' comes from cmyK..? | 11:55.57 |
| | However, if I use the -dUseCIEColor switch, the output is valid. | 12:03.25 |
| kens | -sColorConversionStrategy=RGB | 12:15.03 |
| | If you get that wrong, then colours are not converted, 'k' is a CMYK definition, so you can't use it with an RGB Profile | 12:15.39 |
| | See /ghostpdl/doc/Ps2pdf.htm#Color_Conversion_and_Management | 12:17.40 |
| lasse_ | http://ghostscript.com/doc/9.18/Ps2pdf.htm#OptionsRGB | 12:32.41 |
| | Then why does it say '/' in front there? | 12:32.56 |
| kens | Where ? | 12:33.23 |
| lasse_ | -sColorConversionStrategy | 12:33.38 |
| | It says either /CMYK or /RGB | 12:33.45 |
| | Or /UseDeviceIndependentColor | 12:34.03 |
| kens | TYou'll have to give me more of a clue | 12:34.12 |
| lasse_ | It's specified with a forward slash, but you told me to use it without | 12:34.32 |
| kens | The link I pointed out says CMYK RGB or UseDeviceIndependentColor | 12:34.51 |
| | Oops also LeaveColorUnchanged and Gray | 12:35.06 |
| | Section 6 ColorConversion and Management | 12:35.20 |
| lasse_ | Yes, but check section 9 | 12:35.47 |
| kens | OK the PDF/A section is out of date | 12:35.52 |
| | Section 6 is correct | 12:35.58 |
| lasse_ | lol | 12:36.14 |
| | That has probably been the error this whole time | 12:36.21 |
| | Now it got verrified | 12:36.29 |
| kens | I'll try and remember to change the documentation | 12:36.58 |
| | I clearly missed that bit when I updated it | 12:37.08 |
| lasse_ | Yes, thanks | 12:37.11 |
| | Would have saved me a couple of 6-7 hours :P | 12:37.35 |
| | kens: I have one final question. How do I create a PDF from a JPEG without loosing quality? | 13:53.32 |
| tor8 | lasse_: I wrote a quick program to do that once, you can get the source here: https://github.com/ccxvii/snippets/blob/master/jpegtopdf.c | 13:55.16 |
| kens | lasse_ you set Flate compression | 13:55.38 |
| tor8 | lasse_: also, it's 'losing' not 'loosing' :) | 13:55.48 |
| lasse_ | You learn something new every day | 13:56.53 |
| kens | Tor's method starting form a .jpg file is better of course, because the jpeg doesn't have to be decompressed | 13:57.27 |
| lasse_ | Was just about to ask what the benefit was | 13:57.40 |
| | So the DPI and resolution won't affect the .jpg? | 13:57.58 |
| kens | There is no DPI or resolution ion a PDF file | 13:58.14 |
| tor8 | the program I wrote just embeds the existing JPEG file in a minimal PDF skeleton | 13:58.16 |
| kens | If you want to scale the JPEG then you will have to do some extra work | 13:58.30 |
| lasse_ | Don't think I have to do that. | 13:58.43 |
| | My project manager left for the day, so can't ask him either | 13:59.01 |
| tor8 | the command line options determine how to place the image on the page | 13:59.02 |
| lasse_ | I'll bookmark your script for monday | 13:59.17 |
| kens | That's a C program source file, not a script :-) | 13:59.36 |
| lasse_ | true | 13:59.42 |
| | My project manager hadn't left after all. He told me that the JPEG had to be in a PDF/A-1b format. I guess @tor8's program is too simple for that? | 14:11.53 |
| kens | Yes, but it could easily be extended | 14:12.05 |
| | Colour space conversion would be a problem though, you would have to live with whatever space the4 image is already in | 14:12.26 |
| | The only way to change that is to decompress the image and alter all the sample data | 14:12.44 |
| lasse_ | Well, I do not have the knowledge about such matters. | 14:12.52 |
| Robin_Watts | lasse_: If the JPEG includes text, then don't use a JPEG. | 14:12.54 |
| kens | Robin_Watts : we're talking about existing JPEG images | 14:13.10 |
| lasse_ | Robin_Watts: It's really not something I have a say in | 14:13.26 |
| Robin_Watts | kens: I appreciate that, but if it's possible to change the workflow to avoid JPEGs they should. | 14:13.54 |
| kens | I always encourage people to be very careful about using JPEG :-) | 14:14.13 |
| lasse_ | Well, JPEG already exists. Only solution is to find a way to cope with it. | 14:14.56 |
| | kens: Is it possible to use Flate compression on a JPEG into a PDF/A-1b? | 14:16.17 |
| kens | Err you would need to un-compress the JPEG first | 14:16.34 |
| | Flate compressing a JPEG doesn't have a lot of effect | 14:16.43 |
| lasse_ | Of course, but I thought maybe ghostscript would do it automatically | 14:17.04 |
| kens | If you use viewjpeg.ps to read teh JPEG file, use pdfwrite and set the ColorImageFilter to FlateEncode then that will produce a PDF file whch has an image which is now Flate compressed (but no longer as JPEG) | 14:17.53 |
| lasse_ | viewjpeg.ps will produce the decoded version of a JPEG? | 14:19.37 |
| kens | viewjpeg.ps reads a JPEG file and 'draws' it. If the device is pdfwrite then it draws it to a PDF file | 14:20.11 |
| | In order to draw the image, we must of course decompress it | 14:20.28 |
| lasse_ | Alrigt, I'm checking out viewjpeg.ps. I can see that it consists of different functions, but I'm not really sure about how to use it. | 14:26.41 |
| | I need to use the /viewJPEG, I assume | 14:27.38 |
| kens | Its documented at the top of the file in the comments | 14:27.47 |
| | "% Usage example: | 14:28.48 |
| | % (jpeg-6/testimg.jpg) viewJPEG" | 14:28.48 |
| | Obviously preceded by gs or gswin32 or whatever the binary is on your platform of choice | 14:29.08 |
| lasse_ | Linux | 14:29.17 |
| | I was looking at the command at the bottom | 14:29.31 |
| | gs -sDEVICE=pdfwrite -o stuff%03d.pdf viewjpeg.ps -c "(image.jpg) << /PageSize 2 index viewJPEGgetsize 2 array astore >> setpagedevice viewJPEG" | 14:29.32 |
| | Wasn't able to make sense of everything that's happening there and the order of operations | 14:30.06 |
| Robin_Watts | gswin32c -sDEVICE=pdfwrite -o out.pdf <any other flags> viewjpeg.ps (input_path.jpeg) viewJPEG | 14:30.47 |
| | Well, gs, in your case. | 14:30.57 |
| | not gswin32c | 14:31.02 |
| lasse_ | Yes, true | 14:31.06 |
| | Thanks a bunch | 14:31.21 |
| | ./gs -dPDFA=1 -dBATCH -dNOPAUSE -sColorConversionStrategy=RGB -sProcessColorModel=DeviceRGB -sDEVICE=pdfwrite -sOutputFile=out-a.pdf -dPDFACompatibilityPolicy=1 -c "<</ColorImageFilter /FlateEncode>> setdistillerparams" -f /path_to/PDFA_def.ps /path_to/viewjpeg.ps /path_to/picture.jpg viewJPEG | 14:34.59 |
| | Got an error, but was it something like that you meant? | 14:35.17 |
| kens | Probably | 14:37.00 |
| rayjj | lasse_: viewJPEG is a PS function created by viewjpeg.ps -- to tell gs that something is PostScript on the command line (rather than a file to process) you precede it with -c | 15:57.25 |
| lasse_ | So right after PDFA_def.ps ? | 15:58.06 |
| rayjj | lasse_: and the viewjpeg proc expects the input file to be in a PostScript string on the stack, so after viewjpeg.ps you should have: -c "(/path_to/pircture.jpg) viewjpeg" | 15:59.59 |
| | lasse_: note that -o out-a.pdf is the same (but shorter) as: -dBATCH -dNOPAUSE -sOutputFile=out-a.ps | 16:01.47 |
| | lasse_: Note the -c ... is after the viewjpeg.ps *NOT* the PDFA_def.ps | 16:04.00 |
| lasse_ | Makes sense | 16:04.44 |
| rayjj | lasse_: the comment in viewjpeg.ps right above the viewJPEGgetsize proc has it this way. | 16:05.40 |
| lasse_ | yes, but it had a lot of other functions that confused me, but I think I understand it now | 16:06.28 |
| rayjj | lasse_: oh, my bad. I hadn't capitalized correctly. The PS proc is viewJPEG -- not viewjpeg as I typed above | 16:06.42 |
| lasse_ | I was aware :) | 16:06.55 |
| rayjj | PostScript is totally case sensitive | 16:07.05 |
| | as you already know, apparently | 16:07.14 |
| lasse_ | I'm new to ghostscript/PostScript, but I have picked that bit up, yes | 16:08.02 |
| | Alright. So I only need to include the path to the picture within the command to viewjpeg.ps, and nothing after | 16:14.03 |
| dinamic | evning folks anyone around that can assist in using mujs apis ? | 22:11.59 |
| Robin_Watts | for mujs you probably need tor8, and he's gone. | 22:36.24 |
| dinamic | Robin_Watts, ah thanks.. ill hang around for a while.. | 22:48.34 |
| | Forward 1 day (to 2015/10/17)>>> | |
IRC Logs