| | <<<Back 1 day (to 2016/06/22) | 20160623 |
| psmlbhor | Hello. The bluebook of postscript mentions that an image with 1 bit per sample can only print black and white. Is there no way in which RGB colors may be printed with 1 bit ? Means either R on/off G on/off and B on/off | 09:18.56 |
| kens | The Blue Book was written in the days of level 1 PostScript, while it is useful for learning PostScript , you should refer to the Red Book for details of the current language | 09:19.59 |
| psmlbhor | Oh. I wasn't aware of that. Sorry | 09:20.39 |
| | Actually I had doubt in PLRM. It says on page 607 that if bit/sample is less than 8, sample values are packed from left to rith within a character. What does that mean? I referred section 4.10.2, but I did not see any reference to this point | 09:26.11 |
| kens | It means waht it says, each byte contains 8 bits of sample data, which are consumed from left to right | 09:26.46 |
| psmlbhor | Does it affect the image reading process using the image operator? | 09:28.02 |
| kens | Your question makes no sense to me | 09:28.13 |
| psmlbhor | When I read image data which comes from RGB color model and 1 bit depth, I get /undefined error. So I was wondering whether the info given in PLRM about bits/sample being less than 8 has anything to do with the error | 09:30.50 |
| kens | This is not a PostScript tutorial forum. You have consistently refused to follow advice, if you insist on writing your own PostScript thenyou are going to have to learn PostScript and we are not here to teach it to you | 09:34.07 |
| psmlbhor | I am really sorry. I won't bother anyone here with postscript. | 09:39.12 |
| sebras | tor8: two trivial patches over at sebras/master if you LGTM them I'll push. | 09:46.27 |
| tor8 | sebras: looking | 09:57.03 |
| sebras | tor8: still working my way through the failing jpx-cases. | 09:57.35 |
| tor8 | sebras: first one ... didn't we do the opposite once to not mess up marcosw's cluster testing scripts? | 09:58.10 |
| | sebras: hm, change the memcmp to buf[0] == 'M' && buf[1] == 'M' && ... ? | 09:58.57 |
| sebras | tor8: the surrounding pieces of code also use memcmp(). do you want me to change them all? | 09:59.23 |
| | tor8: I guess I could do some \xff-thingy in the string, but it always looks awkward to me. | 10:00.01 |
| tor8 | sebras: the two-byte ones at least :) | 10:00.05 |
| sebras | tor8: oki. I fix. | 10:00.13 |
| tor8 | sebras: yeah, I'm not a fan of that either. | 10:00.18 |
| | sebras: thanks. | 10:00.25 |
| | how's the apartment hunting? | 10:00.31 |
| sebras | tor8: concerning the filenames... we normally print the filenames for mutool draw -P | 10:00.45 |
| | tor8: to it seems as if we should for mutool draw too..? | 10:00.59 |
| | tor8: this was changed when robin introduce the background interpretation/rendering. | 10:01.30 |
| | tor8: so I'm not sure it was intentional. | 10:01.37 |
| tor8 | sebras: I have no real opinion there; I'd consult marcosw and Robin_Watts | 10:01.52 |
| sebras | tor8: got an apartment yesterday evening. a bit pricey, but it is only for a short time. | 10:02.00 |
| | tor8: ok but the second patch is almost at lgtm. I'll push once I changed it. | 10:02.46 |
| | tor8: hm... memcmp(buf, "\211PNG\r\n\032\n" | 10:04.55 |
| tor8 | sebras: yeah, ugly | 10:05.47 |
| sebras | tor8: can you help me with looking up what the maximum number of colors are in a jpeg2000 index palette? | 10:20.24 |
| | tor8: I'm having trouble downloading the spec and I forgot my usb 3.0 cable at home so I cannot access my external drive. | 10:20.44 |
| | tor8: is it 256? or 1024? | 10:22.08 |
| kens | 1024 | 10:22.27 |
| | At least that's the maximum number of entries in the table according to the palette box | 10:22.42 |
| sebras | kens: ok. that fits with pdfref17. | 10:23.58 |
| | kens: but then there ought to be a bug in gs:: s_jpxd_write_data() when image_is_index is set since it appears to use unsigned char to index into the palette array. | 10:25.11 |
| kens | No that's in the JPEG 2000 spec | 10:25.36 |
| | SOrry, I thought you were saying that was teh PDF entry | 10:25.52 |
| sebras | kens: pdfref17.pdf section 3.3 page 89 also mentions it. | 10:26.07 |
| kens | There are other entries in the box of course, such as the number of components | 10:26.13 |
| | Yes probably | 10:26.21 |
| sebras | wait a minute... what does "entry" mean in this context? | 10:26.39 |
| kens | LOL good question :-) | 10:26.53 |
| sebras | I thought it meant one color in the palette. | 10:26.54 |
| kens | Ah now.... | 10:27.00 |
| | THere's also Number of components | 10:27.15 |
| | created by application of the palette | 10:27.27 |
| | and teh bit septh of the generated component | 10:27.45 |
| sebras | yes, but that is just how many components each indexed color uses, right? | 10:27.49 |
| kens | Its how many each produces | 10:28.02 |
| sebras | mmm, agreed. | 10:28.08 |
| kens | You can have N input compnents and M output components | 10:28.18 |
| sebras | for the palette can I really have N input components? I thought it was just a single array with one index, hence 1 input component. but with M output components of course. | 10:29.00 |
| kens | Technically you can have more than one inptu component yes | 10:29.19 |
| | I'm not certain I;ve ever seen one | 10:29.36 |
| sebras | I doubt that luratech supports that. | 10:29.37 |
| | it just returns a linear array that you can index into.. | 10:29.58 |
| kens | Using the palette index ? | 10:30.14 |
| | The thing is it might just be returning the 'C' entry | 10:30.32 |
| sebras | yes. that you get from pucData in the code I referenced above. | 10:30.36 |
| kens | Which is the actual palette | 10:30.39 |
| | That is organised by component makor order | 10:31.08 |
| | Apparently there should be number of created components x number entries in the palette in that table | 10:31.30 |
| | I would guess you are required to deindex the table yourself | 10:32.29 |
| sebras | now you lost me completely. | 10:32.47 |
| | I read that from the file (at least if I'm a j2k image consumer) | 10:33.28 |
| kens | Well, I suspect that Luratech just returns the 'C' from the Box, which is the palette table and you have to interrogate that yourself, knowing how many input and output components there are | 10:33.30 |
| | Its not clear to me how this works for multiple input components | 10:34.09 |
| | And its been a long time since I wrote a JPX consumer | 10:34.27 |
| sebras | kens: seems like gs only support single input components. | 10:34.31 |
| | kens: and it artificially limits #componets to 256 since it alrays reads the indicies using unsigned char. | 10:35.01 |
| kens | I wouldn't be surprised, in fact I suspect that the PDF implementation may have that as a limot | 10:35.08 |
| | TO be honest, this is one of the things about JPX< its madly ocercomplicated | 10:35.25 |
| | The comittee seems to have stuck every possible thing in there, without any thought as to whether its actually sensible. | 10:36.02 |
| sebras | kens: aha! now I get what pdfref says: you are indeed correct. while j2k may have up to 1024 entries in its palette j2k-files in a pdf only needs to support up to 256. | 10:36.18 |
| kens | Right, there are some quite specific limits on what a PDF can have | 10:36.45 |
| sebras | if that's the case then I can just do what gs does and be fine with it. | 10:36.52 |
| kens | :-) | 10:36.58 |
| | You may want to check and throw an error if someone tries to be clever :-) | 10:37.12 |
| sebras | kens: well, if they are then I'll just misinterpret the bigger indicies as small indicies so we'd just see garbage. | 10:38.47 |
| | that is if we _ever_ see such a file. | 10:38.57 |
| kens | Well it woulcn't be a legal PDF file, but then that's never stopped anyone | 10:39.14 |
| | I suspect the GS PDF interpreter checks the size and throws an error if its invalid | 10:39.30 |
| | We may even have a test case, maybe.... | 10:39.39 |
| | It sounds vaguely familiar | 10:39.49 |
| sebras | kens: then it'll be caught when I clusterpush. | 10:44.10 |
| | kens: thanks for setting me straight. :) | 10:44.19 |
| kens | NP | 10:44.43 |
| | I remember the pain of teh JPX spec :( | 10:44.53 |
| sebras | foods, see you! | 10:45.04 |
| ManDay | Hi, I have a PDF which embeds plenty of pictures with unreasonably high resolution. Can gs be used to reduce the resolution of the images? | 10:58.23 |
| kens | Yes,provided you accept that it will do more than simply reduce the resolution, ti will write a completely new PDF file, not just modify the existing one | 10:59.06 |
| ManDay | Yeah I know | 10:59.35 |
| kens | Then the answer is yes :-) | 10:59.48 |
| ManDay | Could you give me a hint? On Stackoverflow people mentioned the -r option, but appears to have not the desired effect for me | 10:59.59 |
| kens | Nah that won't do anything, you need to use the distillerparams | 11:00.18 |
| | Look in doc/VectorDevices.htm | 11:00.36 |
| ManDay | thanks | 11:00.39 |
| kens | specifically DownsampleColorimages ColorImageDownsampleThreshold ColorImageResolution COlorImageDownsampleType and the equivalents for Mon and Gray images | 11:01.17 |
| | I know its complicated, but that's the way dobe implemented it :-( | 11:01.44 |
| | Adobe* | 11:01.48 |
| ManDay | hm | 11:18.02 |
| | I tried now | 11:18.07 |
| | gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/default -dColorImageResolution=15 -dGrayImageResolution=15 -dMonoImageResolution=15 -dColorImageDownsampleThreshold=0 -dGrayImageDownsampleThreshold=0 -dMonoImageDownsampleThreshold=0 -dNOPAUSE -dQUIET -dBATCH -dDetectDuplicateImages -dCompressFonts=true -sOutputFile=QFTI_very_resized.pdf QFTI.pdf | 11:18.09 |
| kens | DOn't use PDFSETTINGS | 11:18.21 |
| ManDay | oh | 11:18.30 |
| kens | You haven't set DownsampleColorImages, if you dont' then it won't downsample | 11:18.46 |
| | same for Mono and Gray | 11:19.00 |
| ManDay | missed that one :) | 11:19.27 |
| kens | I wouldn't set the threshold to 0, that will likely not work | 11:19.29 |
| | set it to 1 | 11:19.33 |
| ManDay | works fantastic! all formulas look like braille with resolution 15 :) | 11:26.02 |
| kens | Really ? well as long as you're happy :-) | 11:26.22 |
| ManDay | I'm sure going to use a higher value now :-P | 11:26.57 |
| | But it makes for some interesting art with 15 | 11:27.05 |
| tor8 | Robin_Watts: commit on tor/master to fix the muraster build on unix | 14:44.56 |
| | fredross-perry: commits on tor/master to fix the java desktop viewer issues you ran into yesterday | 14:45.12 |
| Robin_Watts | looking | 14:45.31 |
| tor8 | Robin_Watts: the first 5 commits on tor/master are good to go from me; I'd like to hold on a bit with the per-language CJK fonts | 14:45.42 |
| | until I've figured out why gs and acrobat don't like our pdfwrite output using those fonts | 14:45.56 |
| Robin_Watts | git's taking ages to fetch.... | 14:46.54 |
| tor8 | sorry. another bunch of 20mb font files :( | 14:47.04 |
| | the NotoSansCJK fonts are just rebranded Source Han Sans, with no modifications but the name | 14:47.33 |
| | so I went direct to the source instead | 14:47.38 |
| Robin_Watts | ok, so the muraster commit... I don't like the movement of the #elif MURASTER_THREADS == 3 line. | 14:48.18 |
| | I can see why you want it changed, but I don't like moving it. | 14:48.35 |
| tor8 | I put the comment inside the section, like with the == 2 line | 14:48.36 |
| | I can move it up, if you prefer | 14:48.48 |
| | but can I then move the pthreads comment too? | 14:48.57 |
| Robin_Watts | The point is that people are encouraged to add new sections. | 14:48.59 |
| | the #elif line is part of what needs to be added. | 14:49.18 |
| tor8 | right, so that's why you had it commented out? | 14:49.40 |
| | I'll change it then | 14:49.44 |
| Robin_Watts | tor8: Yes, that whole section was supposed to be commented out, but that's hard to do with # stuff. | 14:50.05 |
| tor8 | well, you can remove the nested /* */ comments | 14:50.22 |
| Robin_Watts | We could have it all as a #ifdef ADD_NEW_SETTINGS_IN_HERE section ? | 14:51.03 |
| | still a bit nasty. | 14:51.06 |
| tor8 | I've pushed a new revision, that changes the nested comments to // | 14:51.13 |
| | and leaves the big block /* */ comment around the whole section | 14:51.34 |
| Robin_Watts | tor8: In the "Update JNI code" commit... in gl-main.c | 14:53.08 |
| | you have added 0 to the the page_contents call, and 1 to the annot call. That seems odd to me. | 14:53.38 |
| | oh, you plot the alpha one over the non alpha one? I see. | 14:54.52 |
| tor8 | Robin_Watts: yeah. the page doesn't need alpha, but the annotations are semi-transparent and plotted over using opengl. | 14:55.55 |
| Robin_Watts | You've changed Page.toPixmap from ,1 to ,3. | 14:56.24 |
| | Was the ,1 wrong before? | 14:56.35 |
| | That's the number of args (other than 'this') right? | 14:57.21 |
| tor8 | yes, it should have been 2 before | 14:57.45 |
| Robin_Watts | so it used to be this(page), ctm, colorspace and it's now this(page),ctm, colorspace, alpha. | 14:57.50 |
| | OK, that makes sense, ta. | 14:57.56 |
| tor8 | correct, number of args other than 'this' | 14:58.05 |
| Robin_Watts | Urgh. Changing what TOFU does again. | 14:58.53 |
| tor8 | nah, just adding one more level to the CJK tofu | 14:59.23 |
| | just clarifying the comments | 14:59.46 |
| Robin_Watts | Ah, ok. | 15:00.09 |
| | OK, so all those commits look good to me except the first one. Let me refetch... | 15:00.28 |
| tor8 | Robin_Watts: I've got to run. If you're happy with the commits, can you push (or rearrange and push the ones you approve of) so that fred doesn't need to stall? | 15:05.43 |
| Robin_Watts | tor8: Sure. | 15:08.36 |
| | tor8: 4 commits pushed. 1 updated on robin/master | 15:13.41 |
| sebras | Robin_Watts: ages? try that on over a capped 3G connection. :-/ | 17:04.14 |
| Robin_Watts | sebras: Ah, yuck. | 17:04.38 |
| sebras | Robin_Watts: seems this is what I'm stuck with for the coming 5 months. DSL seems to be uncommon. | 17:05.05 |
| | maybe at the library or something. need to find that out. | 17:05.17 |
| | Robin_Watts: btw... my patch over at sebras/master for printing filenames in mutool draw | 17:07.23 |
| | Robin_Watts: did you intentionally remove them when you did the bg interpration/rendering threads? | 17:07.54 |
| | Robin_Watts: tor8 mentioned that there had been some problems with the cluster logs? | 17:08.14 |
| Robin_Watts | Not that I can remember. | 17:08.19 |
| | Printing filenames becomes harder to do when bgprinting. | 17:08.58 |
| | but I didn't think I removed anything. Let me look at your patch. | 17:09.20 |
| sebras | Robin_Watts: mutool draw -P -s t pdf.pdf prints the name | 17:10.25 |
| | Robin_Watts: whereas mutool draw -s t pdf.pdf does not | 17:11.31 |
| | Robin_Watts: the same goes for mutool draw pdf.pdf | 17:11.45 |
| | Robin_Watts: this used to be the case before your commit though. | 17:11.58 |
| Robin_Watts | Right, so I only have it printing names in the bgprint case, and you fix it to do it always. | 17:12.23 |
| sebras | Robin_Watts: that was my intention at least. | 17:12.38 |
| | Robin_Watts: so we keep the logs we used to have. what was the issue that marcosw has mentioned to tor8 about the logs in the cluster? | 17:13.06 |
| | Robin_Watts: is it even related? maybe things got mixed up along the way. | 17:13.20 |
| Robin_Watts | I thought we previously only ever printed stuff when one of the show options was enabled. | 17:13.32 |
| | but I could be wrong. | 17:13.58 |
| | Your commit seems sane though - we are now at least consistent. | 17:14.12 |
| | sebras: I don't know anything about logs. | 17:14.31 |
| sebras | Robin_Watts: yeah, having these logs helps point to what file/page a certain warning/error happened on. | 17:15.09 |
| | Robin_Watts: regardless of if you also print timing, md5 or features. | 17:15.29 |
| | Robin_Watts: thanks for taking a look. | 17:15.59 |
| Robin_Watts | (sebras: So, just to be clear, that's me passing the review. Push away) | 17:16.26 |
| sebras | Robin_Watts: yeah, got it. :) | 17:17.25 |
| Robin_Watts | sebras: There is 1 commit on robin/master awaiting review. | 17:19.46 |
| | Tor fixed muraster for unix, and I tweaked the commenting in muraster.c slightly from his version. | 17:20.21 |
| sebras | Robin_Watts: some parts like ctm -> identity or NULL -> render.bounds look reasonable to me but I'm not well versed in that part of the code. | 17:27.57 |
| Robin_Watts | sebras: Most of it is tors changes. I've reviewed all them. | 17:28.19 |
| sebras | Robin_Watts: right. | 17:28.29 |
| | Robin_Watts: I looked at the patch as a whole. | 17:28.38 |
| Robin_Watts | The bit that needs reviewing is... the 2nd hunk. | 17:28.57 |
| sebras | Robin_Watts: so FWIW: LGTM. :) | 17:29.01 |
| Robin_Watts | Ta. | 17:29.06 |
| sebras | realizes that he should push _first_ and _then_ review. ;) | 17:30.36 |
| | Robin_Watts: I spoke briefly with tor8 about adding jpegxr as a conditional library, like luratech. so if you clone it out then it will be compiled in. | 17:35.10 |
| Robin_Watts | That would be fab. | 17:35.20 |
| sebras | Robin_Watts: the quality of the code is a bit questionable. e.g. one of the testfiles i have causes an assert in the library itself. | 17:35.34 |
| Robin_Watts | sebras: The code will never be improved if we don't support it at all. | 17:35.54 |
| sebras | Robin_Watts: do we support it for gs? | 17:36.04 |
| Robin_Watts | No, but if we can get the lib working well, we could. | 17:36.24 |
| sebras | Robin_Watts: so far only one file causes an assert. but I'd not be surprised if there are a few buffer overruns and what not in that code given that it hasn't really been exercised a whole lot. | 17:37.38 |
| | Robin_Watts: anyway, it will be optional so we don't have to include it in the official release builds. | 17:37.59 |
| | good night! | 17:48.40 |
| Robin_Watts | night! | 17:48.56 |
| | Forward 1 day (to 2016/06/24)>>> | |
IRC Logs