| | <<<Back 1 day (to 2015/04/28) | 20150429 |
| mvrhel_laptop | wow. The blending group color space stuff is getting even more interesting and starting to make some sense now. When the blending spaces are one of the device color spaces then we treat all the RGB and CMYK colors that we draw into it as device colors and use the unmanaged color conversions. The exception to this is the base buffer for the pdf14 device | 05:29.21 |
| | So if the source color is an ICC RGB color value and we are drawing into a transparency group that was defined to be DeviceCMYK we do the unmanaged conversion. | 05:30.17 |
| | The UCR/BG transform that is used is the 0% black. So rgb values are converted to cmy values using the 1-X operation. | 05:31.41 |
| | k values convert to equal amounts of rgb | 05:31.54 |
| | and the appropriate adjustments are made for cmyk combination | 05:32.23 |
| | so quite a bit to do here. luckily though there are just a few spots where we do conversions and we already have the setup to do the unmanaged color conversions. | 05:33.53 |
| | obviously if the blending color space was defined to be ICC then we do the conversions. during a group pop though the ICC based conversion will only happen if both spaces are ICC based | 05:35.33 |
| | the exception is when we pop to the final base group. In that case, the final group is treated with the default ICC profile for that color space and the conversion is made to the target device profile | 05:36.15 |
| | fun! | 05:36.17 |
| | done with this for the night. tomorrow I will start ripping things apart | 05:42.38 |
| tor8 | Robin_Watts: do you want to answer Junghen's latest question or should I? | 08:49.15 |
| Robin_Watts | looking... | 08:57.54 |
| | tor8: I shall leave that one to you :) | 08:59.21 |
| | tor8: random thought. | 10:10.22 |
| | Suppose I open a document, and feed a password to fz_authenticate_password, and it passes. | 10:10.41 |
| | How do I know if that was a user or an owner password? | 10:10.52 |
| tor8 | you don't | 10:11.49 |
| Robin_Watts | Then how can I know which permissions I need to check for? | 10:12.01 |
| tor8 | though we *could* add an ugly trick to pdf_authenticate_password to return 2 on owner password and 1 on user password | 10:12.10 |
| Robin_Watts | tor8: That would seem sensible. | 10:12.52 |
| | (either that or have a separate fz_authenticate_user_password call) | 10:13.22 |
| tor8 | Robin_Watts: ah! I see. so if we open with the owner password, we should always allow all permissions? | 10:14.04 |
| Robin_Watts | tor8: Oh, yes. That'd be nice. | 10:14.44 |
| tor8 | it would. it's completely slipped my mind. | 10:15.08 |
| Robin_Watts | Although... Does Acrobat let you remove permissions if you have the owner password? | 10:15.14 |
| tor8 | the crypto code was written way before we added editing | 10:15.17 |
| | still, *none* of our viewers actually do anything to restrict use based on the permissions | 10:15.44 |
| | (and doing so in an open source product would be misguided at best) | 10:15.57 |
| kens2 | chrisl the bug #695972 looks more like a font rendering problem (though I'm puzzled that MuPDF apparently renders it OK) than a PDF interpreter problem, so I've chucked it over to you...... There is something odd happening, and it 'could' be the PDF nterpreter, some of the text seems to use more than 1 byte per glyph, some of it doesn't, strange | 12:45.08 |
| | :-) I see you bet me to it | 12:45.52 |
| chrisl | kens2: *definitely* font related, not pdf interpreter. I'll poke at it properly after lunch | 12:46.49 |
| kens2 | No rush, I cur the file down to remove all the images linework and transparency and it does hte same. | 12:47.15 |
| henrys | mvrhel_laptop: is it okay to talk about open printing here or should we use skype (the cone of silence) ;-) | 15:22.41 |
| | ? | 15:22.56 |
| Robin_Watts | Surely that would be closed printing? :) | 15:28.53 |
| kens2 | Robin_Watts : that reminds me (for some strange reason) you and Michael were discussing a PDF containing only a series of images a few days back. | 15:29.37 |
| Robin_Watts | kens2: Were we? | 15:29.52 |
| kens2 | pdfwrite is not the best way to produce such a thng, its massively over-complicated. Better to create a new device to do it. | 15:30.04 |
| Robin_Watts | kens2: Ah, we were discussing the idea of *making* such a thing, yes. | 15:30.20 |
| kens2 | Robin_Watts : I remember reading it in the logs, it was after I was offline | 15:30.22 |
| | Yes, creating a PDF like thatr | 15:30.31 |
| Robin_Watts | The idea was that we want to do color correct proofing on a mobile app. | 15:30.54 |
| kens2 | Ah yes, I kind of remember the context, vaguely | 15:31.12 |
| Robin_Watts | So we'd use get GS to generate us a PDF with all the overprint etc done and color profiles applied but where the result was simply RGB images. | 15:31.41 |
| | Then mupdf can just display that easily. | 15:31.49 |
| kens2 | THe thing is, if you want a PDF with a series of bands (or tiles) its better to write a new device, it would be extremely hard to poke pdfwrite into creatng such a thing, and comparatively easy to make a new rendering device which could do it. | 15:32.05 |
| Robin_Watts | kens2: Fair enough. Yes, it sounds doable. | 15:32.21 |
| kens2 | Mostly pdfwrite tries *really* hard *not* to render stuff | 15:32.27 |
| Robin_Watts | I might even be tempted not to do it as a PDF, but as a custom (easier to write) bitmap format. | 15:32.47 |
| kens2 | That would also make some sense, or even just a TIFF file with strips | 15:33.03 |
| | MuPDF can read TIFF already, can't it ? | 15:33.16 |
| Robin_Watts | It can. | 15:33.22 |
| | but it decodes whole images at a time | 15:33.30 |
| kens2 | Oh.... | 15:33.36 |
| Robin_Watts | Hence we'd want a file format that had multiple images per page. | 15:33.43 |
| | i.e. one image per strip. | 15:33.48 |
| kens2 | Well a tiff with strips would be equivalent, but you'd have to alter the way you load tiffs. A PDF would be fairly easy to create that way. Or invent a new format. Either weay a new device is the way to go, not try to repurpose pdfwrite :-) | 15:34.54 |
| Robin_Watts | yeah. | 15:35.01 |
| | We need to wait for ray to finish pushing the simulate overprint stuff inside the pdf compositor, rather than it being done at device level. | 15:35.42 |
| kens2 | Huh, that'll probably break all my device code again :-( | 15:36.04 |
| Robin_Watts | Do you do simulate overprint in pdfwrite? | 15:36.29 |
| kens2 | No, we preseve it | 15:36.35 |
| | Like I said, pdfwrite tries very hard not to do rendering | 15:36.51 |
| Robin_Watts | kens2: Right, this would only affect rendered stuff, AIUI. | 15:36.53 |
| | so you should be fine, I hope. | 15:37.07 |
| kens2 | No, I mean my new code, which allos for device chains | 15:37.18 |
| mvrhel_laptop | henrys: sorry I was out for a bit. We can talk about open printing here in terms of potentially mupdf replacing poppler for the linux handheld pdf solution | 18:19.40 |
| henrys | mvrhel_laptop: I'm concerned that we are getting signed up to do something ... was there anything they required before adopting mupdf? | 18:33.43 |
| mvrhel_laptop | henrys: this is in the very early stages | 18:34.01 |
| | I need to talk with Ira a bit about it | 18:34.27 |
| | we only spoke briefly about how they were not happy with poppler and that they thought mupdf would be a better solution for them | 18:34.57 |
| | he said he would follow up with me later about this | 18:35.08 |
| henrys | mvrhel_laptop: kind of skeptical too, it was made pretty clear that other parts of the system depended on poppler and it made no sense to switch. Robin_Watts was part of those discussions. | 18:35.44 |
| mvrhel_laptop | I recall that and I was a bit surprised | 18:35.58 |
| | I will find out more | 18:36.01 |
| henrys | interesting though. maybe next meeting you can tell folks a bit about the summit. | 18:36.34 |
| rayjj | kens: (for the logs). The "simulate overprint" would only use the pdf14 compositor to render when the device needs rendering and is not "overprint capable". I may create a new spec_op to ask devices if they are overprint capable | 18:36.47 |
| Robin_Watts | My memory of the discussions before is poor, but my basic thought was that they didn't want to move away from poppler cos one or more of the developers was attached to it. | 18:37.18 |
| mvrhel_laptop | henrys: yes. add it to the agenda :) | 18:37.26 |
| rayjj | Robin_Watts: ahh, nepotism at its best | 18:38.00 |
| mvrhel_laptop | Robin_Watts: yes I recall that too | 18:38.46 |
| | but apparently it is not working out so well | 18:38.53 |
| henrys | uhh linux handheld isn't working out at all... which was my concern about them needing stuff... | 18:39.41 |
| mvrhel_laptop | yes | 18:39.48 |
| henrys | another concern | 18:39.52 |
| mvrhel_laptop | my thought on the whole thing is that they really don't need anything from us. they would just drop in mupdf for their viewer and do all the work on it themselves | 18:41.27 |
| | I had not thought of it taking any of our time | 18:41.57 |
| henrys | mvrhel_laptop: obviously that would be great. | 18:43.23 |
| rayjj | grrr... I hate the color conversion -- 1 byte color 0xcf (in the pdf14 buffer) -> 0.81176478 (using decode_sample) -> 0xcfcf (using gx_remap_concrete_ICC using psrc[k] = (unsigned short) (pcc->paint.values[k]*65535.0) ) -> 0x67e1 (using ushort2frac(0xcfcf) == ((0xcfcf) >> 1) - ((0xcfcf)>> 13) ) -> 0xcfce (in cmap_gray_direct using frac2cv(0x67e1) == 0x67e1 << 1 + (ox67e1 >> 11) ) | 19:21.44 |
| | but then, 0xcfce -> 0xce (using pgm_map_rgb_color). Note that 0xcfcf would convert to 0xcf !!! | 19:23.25 |
| | everybody that touched this has added their own conversion ! At least mvrhel's icc_link is coming up "is_identity == 1" so it isn't part of the picture | 19:24.49 |
| Robin_Watts | rayjj: Yeah, I dislike the 'frac' stuff. | 19:25.53 |
| rayjj | mvrhel_laptop: how would you like to streamline all of the color conversion next ;-) [and clarify all of the various color representations. Concrete, ushort, frac, color, ...] | 19:26.08 |
| Robin_Watts | I'm sure it was very clever at the time, but... | 19:26.22 |
| mvrhel_laptop | rayjj: yes I disliked the frac stuff and did my best to avoid it in the icc stuff. unfortunately, it is everywhere and so at times, it was required to convert between it | 19:27.19 |
| | we had this discussion long agooo | 19:27.25 |
| Robin_Watts | I have a vague memory from when I looked at this, that the frac stuff was designed to give 'almost' 16bit accuracy in a short with room to slop over a bit. | 19:27.33 |
| | I kinda feel we should just use 16.16 everywhere. | 19:27.55 |
| rayjj | Robin_Watts: iirc (from ancient history) it was a clever way to allow integer ushort manipulation of colors and not get too many rounding errors | 19:28.11 |
| mvrhel_laptop | the frac stuff was designed I thought so that we could be more accurate at certain standard fractional values | 19:28.26 |
| Robin_Watts | * Normally one would represent a fractional value of this kind as a short | 19:28.27 |
| | * integer, in [-32767..32767]. Unfortunately, this approach cannot | 19:28.29 |
| | * represent any of the common values like 1/2, 1/3, or 1/5 exactly, causing | 19:28.31 |
| | * rounding errors. Instead, we opt for using the range [-32760..32760], | 19:28.33 |
| rayjj | Robin_Watts: right. We need to represent 1.0 and 0.0 | 19:28.34 |
| Robin_Watts | * which allows exact representation of almost all commonly used fractions | 19:28.34 |
| | * (e.g., N/360 for 0<=N<=360). | 19:28.36 |
| | rayjj: Yeah, your memory is better than mine. | 19:28.42 |
| mvrhel_laptop | Robin yes the common values | 19:28.44 |
| Robin_Watts | I still think we should just use 16.16. Or maybe 8.24 | 19:29.12 |
| | Or 1.31 - we have the space for that on modern machines. | 19:29.32 |
| rayjj | the thing is, AFAICT, 'frac' is internal (like gas in the intestine) and devices only see 'gx_color_value' which are ushorts | 19:29.56 |
| mvrhel_laptop | hehe | 19:30.14 |
| rayjj | mvrhel_laptop: so I wonder what will happen (other than all hell breaking loose) if I "round" the frac2cv which is causing the color shift I've tripped over | 19:31.35 |
| mvrhel_laptop | rayjj: this thing is a landmine | 19:32.38 |
| | I believe the long term solution is to go to 16.16 like Robin_Watts suggested. | 19:35.03 |
| rayjj | in this case: ((0x67e1 >> 10) + 1) >> 1 gives me the value I need (0xd instead of 0xc)) | 19:35.19 |
| mvrhel_laptop | In the short term if you are going to do some rounding, I thought Robin_Watts had done some work on this a couple years ago | 19:35.30 |
| | do you recall Robin_Watts ? | 19:35.35 |
| rayjj | mvrhel_laptop: landmine is not nuclear. This probably would be | 19:35.42 |
| | IMHO we don't really need 15.16 or 16.16 as long as our conversions "round trip" | 19:36.40 |
| Robin_Watts | Our conversions will never round trip if we go through fracs as they currently are. | 19:38.07 |
| rayjj | mvrhel_laptop: the reason I am on to this is some color differences depending on whether or not we go through the pdf14 compositor. It really only shows up post clist unless we compare clist to non-clist colors | 19:38.22 |
| Robin_Watts | because you're mapping 65536 values into 65500ish and back again :) | 19:38.35 |
| | You could alter gxfrac.h so that fracs were ints ? | 19:39.05 |
| rayjj | the pdf14_put_image is going though the extra color conversion and "rounding" 0xcf (in the pdf14 buffer) down to 0xce | 19:39.10 |
| mvrhel_laptop | rayjj: extra color conversion is bad news | 19:39.42 |
| | I generally try to avoid those | 19:39.49 |
| rayjj | mvrhel_laptop: that's why round trip idempotence is needed | 19:40.05 |
| | Robin_Watts: maybe that's worth a shot. | 19:40.17 |
| mvrhel_laptop | rayjj: round tripping in color conversions is *very* difficult to achieve | 19:41.03 |
| | and should be avoided | 19:41.10 |
| Robin_Watts | It would be nicer if we could detect that the color conversion is not required and just not do it... | 19:41.45 |
| mvrhel_laptop | yes | 19:41.49 |
| rayjj | mvrhel_laptop: maybe just one teeny, tiny, little bit more in the frac would solve it :-/ | 19:42.12 |
| Robin_Watts | rayjj: If that was the case, then you'd need to alter gxfrac.h so that fracs were ints. | 19:43.02 |
| rayjj | Robin_Watts: unfortunately pdf14_put_image is where we do the "heavy lifting" for old, dumb (most of them) devices to get the pdf14 buffer out to the device | 19:43.10 |
| | Robin_Watts: which is what you suggested, rigt ? | 19:43.32 |
| | Robin_Watts: or if fracs were really ushorts with 1.0 == 0xffff that would suffice | 19:45.35 |
| | i.e. make fracs and gx_color_values the same | 19:46.14 |
| | I think I'll have a look at where fracs are used and might really be "trickily" used (i.e. not with macros) and then if I get tired of staring a code, run a regression (nuclear option) | 19:47.25 |
| | hmm... not all that many files are involved 13 C files | 19:49.38 |
| mvrhel_laptop | heading to lunch. bbiab | 19:50.16 |
| rayjj | if LA drops offline, you'll know that I tried it and it didn't work out well ;-) | 19:50.19 |
| | same for me. Lunch before Armageddon | 19:51.06 |
| michaelrose | hey anyone know how to get the non mobile mupdf to display a table of contents? | 21:24.38 |
| | Forward 1 day (to 2015/04/30)>>> | |
IRC Logs