| | <<<Back 1 day (to 2017/06/28) | 20170629 |
| mvrhel_laptop | oh a few segvs.... | 00:35.31 |
| | work to do | 00:35.37 |
| Robin_Watts | mvrhel_laptop: Sorry. | 07:46.48 |
| sebras | tor8: there is a sequence of commits on sebras/master. | 10:52.06 |
| | tor8: thanks for reviewing and making me improve the /Name patch, I think it wound up better this way. | 10:52.48 |
| tor8 | sebras: first two LGTM | 11:08.22 |
| | sebras: I don't quite understand the color context one | 11:08.34 |
| | "Drop appearance stream content buffer upon error" LGTM | 11:10.17 |
| | "Drop buffers in case of error" LGTM | 11:11.08 |
| sebras | tor8: yeah, so the colorspace one... that's a hack. | 11:11.43 |
| | tor8: fz_default_rgb() returns a pointer to a statically allocated colorspace. | 11:12.04 |
| | now when we have lcms corresponding colorspaces are registered using the color management engine | 11:12.40 |
| | and these colorspaces are correspondingly static, despite being actual objects. | 11:13.01 |
| | this means that their ref count is -1 | 11:13.10 |
| | so when the main context is dropped, then the colorcontext attempts to drop these colorspaces. | 11:13.34 |
| | if this is default_rgb, then the drop is NOP | 11:13.41 |
| | if this is the corresponding icc colorspace, then the drop is _ALSO_ a NOP, despite it previously having been allocated using fz_malloc(). | 11:14.18 |
| tor8 | sebras: ahhh, I finally found the top secret option I was looking for... "set ignorespace 1" in ~/.config/git/gitk | 11:14.30 |
| sebras | therefore I attempt to detect if the colorspaces are icc related, and then fiddle with the reference count to trigger fz_drop_imp() to acctually drop the colorspaces. | 11:14.50 |
| Robin_Watts | sebras: ooh, yuck. I really don't like that. | 11:14.53 |
| sebras | Robin_Watts: absolutely, I dislike it myself. | 11:15.10 |
| | Robin_Watts: but at least my... repulsive patch is something that triggers this discussion. ;) | 11:15.47 |
| Robin_Watts | Why do we need is_static? | 11:16.27 |
| sebras | Robin_Watts: I think this is because we might call fz_default_rgb() at places and expect a borrowed reference. | 11:16.52 |
| | i.e. no need to drop it afterwards. | 11:16.59 |
| Robin_Watts | No, I think it's because the cs->data should not be freed. | 11:17.12 |
| sebras | so these default colorspaces are never _really_ reference counted. | 11:17.14 |
| tor8 | sebras: where are their refcounts set to -1? | 11:17.19 |
| | in fz_set_cmm_engine they're set to regular colorspace objects | 11:17.38 |
| sebras | tor8: when in... fz_new_colorspace() I think the function is called, when is_static is true. | 11:17.42 |
| tor8 | oh. that's ... ick. how did I miss that during the review? | 11:17.58 |
| | :) | 11:18.13 |
| Robin_Watts | yeah, I think the refcounts should always be 1. | 11:18.23 |
| | and we should only free the data if is_static != 0 | 11:18.35 |
| sebras | I noticed this when both ASAN and valgrind complained about leaks on code that was basically fz_new_context() followed by fz_drop_context(). | 11:18.38 |
| Robin_Watts | and we should only free the data if is_static == 0 | 11:18.39 |
| tor8 | the -1 are only intended for actual static objects | 11:18.43 |
| | having allocated objects that aren't -1 sounds bad to me | 11:18.53 |
| Robin_Watts | and is_static should perhaps be "static_data" | 11:18.57 |
| tor8 | there's a separate free_data field for static data isn't there? | 11:19.38 |
| | I suggest nuking the is_static field, and fixing whatever leaks crop up due to that instead of this hack | 11:20.01 |
| Robin_Watts | oh, actually, this may now be a complete red herring. | 11:20.02 |
| | I think possibly is_static can just go entirely. | 11:20.12 |
| tor8 | I've seen other changes to make sure we take reference counts even for device colorspaces | 11:20.20 |
| | like in the display list, etc | 11:20.30 |
| sebras | tor8: how does this affect fz_default_rgb()? | 11:20.57 |
| tor8 | not at all, those functions don't take ownership | 11:21.19 |
| Robin_Watts | yeah, I reworked the init of these colorspaces when I added fz_set_cmm_engine, and didn't realise that is_static was now unnecessary. | 11:21.22 |
| tor8 | they already return "borrowed" references, if you want to stow them you need to fz_keep_colorspace | 11:21.33 |
| | we may have a few places where we don't fz_keep_colorspace of the fz_device_xxx like when creating pixmaps etc | 11:21.52 |
| | those should be changed :) | 11:21.57 |
| sebras | right. | 11:22.03 |
| tor8 | but I think should be fairly few of those cases left | 11:22.15 |
| sebras | hopefully! :) | 11:22.44 |
| | tor8: ok, so rework the colorspace patch, but the rest on sebras/master were then LGTMed, correct? | 11:23.02 |
| | s/then // | 11:23.08 |
| tor8 | sebras: still looking at the stream filter chain one | 11:23.23 |
| | but the others were good | 11:23.27 |
| sebras | tor8: ok, I'll rearrange the patches and push. | 11:24.00 |
| Robin_Watts | sebras: There is a patch on robin/master for the is_static thing. | 11:24.39 |
| tor8 | fz_concat_push taking over ownership (as stated by the comment) seems at odds with our usual way of doing things | 11:24.43 |
| Robin_Watts | I'll test it properly when I get back unless you want to run with it. | 11:24.52 |
| tor8 | and pdf_open_object_array doesn't seem to play by those rules | 11:25.30 |
| sebras | tor8: sebras/master updated, I'll push in a few minutes. | 11:25.36 |
| tor8 | sebras: sebras/master LGTM | 11:26.16 |
| sebras | tor8: ty. | 11:26.23 |
| | tor8: pdf_open_object_array() doesn't free chain in case of error..? | 11:26.31 |
| | so when fz_concat_push() throws, who drops the stream created by pdf_open_stream() in pdf_open_object_array()? | 11:27.08 |
| tor8 | if it behaves as you made it, it should be called fz_concat_push_drop | 11:27.16 |
| | but I think it's clearer if we make it behave like other functions and do the cleanup at the call site | 11:27.42 |
| | especially considering there is only one call site for that function | 11:27.53 |
| | we can get rid of the comment | 11:27.59 |
| sebras | yes, though that is true for most of these stream opening functions. | 11:28.05 |
| tor8 | and make things more straigth forward | 11:28.07 |
| | it is an accident of history :) | 11:28.34 |
| | they should fz_keep_stream | 11:28.49 |
| sebras | tor8: I could fix that. | 11:28.58 |
| tor8 | it used to be that fz_stream was *not* reference counted | 11:29.09 |
| sebras | tor8: and yes, avoiding implicitly handing over ownership is good, imho. | 11:29.18 |
| | I see. | 11:29.33 |
| | tor8: I'll fiddle around with that patch as well for a bit then. | 11:29.55 |
| tor8 | and we added reference counting without changing the filter chain construction code | 11:29.58 |
| sebras | tor8: also I have found a lot of places where put_drop() might be a better fit, see e.g. 4a986c6c0 | 11:30.43 |
| | tor8: would you find that type of patch being useful or unnecessary churn? | 11:30.56 |
| tor8 | useful | 11:31.15 |
| | we have a lot of code that predates the put_drop functions that could be tightened up that way | 11:31.30 |
| sebras | ok, then I'll make the patches appealing. | 11:31.33 |
| avih | tor8: is there an "internal" registry which is not visible to mujs clients? | 11:37.11 |
| | or some naming convention you use as such? | 11:37.59 |
| tor8 | avih: you mean the secret registry object that is only accessible from the C side? | 11:38.30 |
| avih | doesn't look like it... | 11:38.31 |
| tor8 | js_get/setregistry() | 11:38.45 |
| avih | no, which is only accessible from the mujs code but not c code which uses mujs | 11:38.51 |
| tor8 | oh, you mean super internal stuff? | 11:39.25 |
| avih | like secret secret registry :) | 11:39.29 |
| | yes | 11:39.37 |
| tor8 | there are a few things stowed away in the js_State struct :) | 11:39.40 |
| | but no, not really | 11:39.45 |
| avih | don't know about super, but yes, which is not visible to c clients using mujs | 11:39.56 |
| tor8 | the prototype objects for various classes (Object, Array, RegExp, etc) | 11:40.07 |
| avih | hmm.. i was trying to implement number tostring using js code function which isn't visible to c code which uses mujs, but not sure how to do that | 11:41.07 |
| | (implement = copy my working implementation in js source into mujs source) | 11:41.41 |
| tor8 | Number.prototype.toString is defined in jsnumber.c | 11:42.02 |
| | that can be overridden like everything else from both the JS and C client side | 11:42.19 |
| avih | i know, and i want it to call into this js function if radix is not 10 | 11:42.32 |
| tor8 | I spent some time looking into doing any radix for floating point conversions | 11:42.41 |
| | it's trickier than I expected | 11:42.49 |
| avih | my js code is 12 js LOC | 11:42.56 |
| tor8 | yeah, but it's not really per spec | 11:43.05 |
| | it *should* be doing the same "minimal" number of digits approach that radix 10 does | 11:43.23 |
| avih | there's no spec. the spec explicitly states the algorithm is implementation dependent | 11:43.28 |
| | and mine is very close to firefox's output, except for sometimes one less digit and trunc vs round | 11:44.15 |
| tor8 | it's implementation dependent, "but should be a generalisation of that specified in 9.8.1" | 11:44.18 |
| avih | yes, that's correct | 11:44.31 |
| | (which admittedly i didn't read carefully) | 11:44.43 |
| tor8 | step 5 says "is as small as possible" | 11:45.00 |
| | but obviously with radixes > 14 we can't use exponential notation (since 'e' then means something else) | 11:45.32 |
| avih | right. i don't see how my implementation isn't as small as possible though | 11:46.02 |
| tor8 | it should be as small as possible *and* round trip bit-perfect | 11:46.26 |
| avih | i tested various magnitudes. the int part is trivial, so the only issue is the fraction part, and as far as i can tell, it's on par with firefox | 11:46.33 |
| tor8 | firefox uses david gay's dtoa bignum implementation | 11:46.50 |
| avih | i only compared outputs though | 11:47.03 |
| | ok, the round trip bit perfect part.. not sure it's possible on all cases | 11:47.30 |
| tor8 | I'm not sure it's worth bothering with, to be honest. | 11:47.53 |
| avih | for instance 0.5 in base 9 is 0.44444444444445 it's never perfect representation of the original value | 11:47.58 |
| tor8 | as long as when you "parse" the same string back into a floating point number, it should be the same bits | 11:48.24 |
| | but since we can't parse random radix floating point numbers, I don't see much value | 11:48.39 |
| avih | i don't think there's float radix parse... is there? | 11:48.46 |
| tor8 | there is not | 11:48.52 |
| avih | so? parse int then? that's trivial and correct | 11:49.10 |
| | the only issue is handling of the fractional part. | 11:50.23 |
| tor8 | at least I don't think so | 11:50.34 |
| avih | i haven't seen one too. there's radix int parse, and float tostring with any radix. you can't round trip it if it has a fractional part in built in js functions afaict | 11:51.26 |
| | (though it would be fairly easy to implement, especially it it's without exponent representation) | 11:52.30 |
| | tor8: but anyway, i think it could be useful to implement some functions in js, which is many times easier to code than c. so i was wondering where i could store such compiled js function while keeping it invisible from c code which uses mujs | 12:08.22 |
| | an internal registry would have been perfect for instance. or declaring that registry entry names which start with __mujs are reserved for internal use, which could also be acceptable | 12:09.26 |
| tor8 | why does it need to be invisible from C code? if it's available from JS it should also be available from C. | 12:10.32 |
| | if you want to override system functions, just replace the system objects | 12:11.06 |
| | there's a new implemention (very hackish) of Number.prototype.toString on tor/master | 12:11.43 |
| avih | indeed, you could just run it, for instance this https://0x0.st/0sy.txt | 12:12.14 |
| | checking your repo | 12:12.22 |
| | tor8: you don't need to empirically test. double in c has known mantissa size in bits | 12:13.18 |
| | or rather the IEEE double, which most c implementations use. and it can be configured explicitly how many meaningful bits you want to support at the conversion | 12:14.00 |
| tor8 | my math is not good enough to calculate the minumum needed number of digits for a certain base to represent all those bits :) | 12:14.10 |
| | JS mandates IEEE doubles | 12:14.19 |
| avih | right, so that's solved. | 12:14.34 |
| | my solution for the resolution is very simple, you can multiply the value by radix till it's big enough to overflow the number of significant bits. once it does, you can't reliably get more neaningful (fraction) digits | 12:15.35 |
| | (you could get more on some cases, but they'll start being garbage, or just 0's) | 12:16.29 |
| tor8 | yeah, that's possibly a better approach over all | 12:16.39 |
| avih | i also think your code uses quite big stack allocations | 12:20.43 |
| | this should be heap imo | 12:20.54 |
| | it can get quite long, especially with binary representation and very small/big numbers | 12:21.20 |
| | tor8: fwiw, these are my test values: https://0x0.st/0sv.txt | 12:23.34 |
| | and that's my output for those https://0x0.st/0sx.txt | 12:24.56 |
| | this for instance is more than 1k string (in firefox and my implementation): (1.3e-300).toString(2) | 12:27.22 |
| | also, the number of fraction digits depends on the size of the number itself (i.e. also the integer part - if it's big enough then there are no more bits for fraction resolution) | 12:29.24 |
| | oh.. yeah, you do start with ilen for significant digits. | 12:38.14 |
| | also, if you're interested, this is an online high precision radix converter including fractions, i found it a useful reference https://baseconvert.com/high-precision | 12:44.25 |
| tor8 | avih: thanks for the links, I'll poke at this some more at a later date. I need to take care of accounting stuff now. | 12:48.21 |
| avih | exciting! | 12:48.33 |
| | (it would be if you need to count $$$ flowing in :p ) | 12:48.58 |
| | actually.. where my example output is different than firefox's, mine is more accurate, be it with less digits where firefox gets the last one wrong, or more digits than firefox with correct accuracy | 12:57.23 |
| sebras | tor8: hm.. is it worth keeping the open stream functions as taking ownership in order to easily be able to do: | 13:28.55 |
| | chain = fz_open_null(ctx, chain, len, offset); | 13:28.58 |
| | ? | 13:29.01 |
| tor8 | sebras: possibly, yes. | 14:00.21 |
| sebras | tor8: let me see how this plays out. | 14:22.23 |
| mvrhel_laptop | Robin_Watts: so on my repos is a commit that fixes an alpha / color management issue | 14:43.47 |
| avih | tor8: https://0x0.st/0zO.txt ? | 15:09.29 |
| | no, actually the (radix == 10) cc needs to expand to include !isFinite | 15:14.20 |
| Robin_Watts | mvrhel_laptop: ah, just give me a few mins and I'll look. | 15:23.37 |
| avih | tor8: i think this is ok now https://0x0.st/0zx.txt | 15:31.47 |
| RobinWattsLenovo | mvrhel_laptop: That fix lgtm. | 15:34.22 |
| | Sorry if I broke that. | 15:34.28 |
| avih | huh, another bug (s[i++] = '.' could buffer overflow). dynamic string allocation is why i wanted to do this in js. | 15:36.25 |
| mvrhel_laptop | RobinWattsLenovo: no problem | 15:36.53 |
| RobinWattsLenovo | mvrhel_laptop: So, what's the state of play now? | 15:39.44 |
| | I've been in SOT and GS worlds yesterday/today. | 15:39.56 |
| | I still have 1 gs bug to look at. | 15:41.11 |
| mvrhel_laptop | RobinWattsLenovo: No problem. I have your WIP commit and am working on getting the color transforms needed for transparency working. | 15:41.27 |
| RobinWattsLenovo | And the WIP commit seems to be doing it's job? | 15:41.47 |
| mvrhel_laptop | RobinWattsLenovo: Yes I believe so. I have some issues that i will work on today that I think I have introduced. Then we need to think about DeviceN support and overprint | 15:42.36 |
| RobinWattsLenovo | cool. | 15:42.53 |
| mvrhel_laptop | Did you have some work that you did toward deviceN? | 15:42.59 |
| | I thought I saw you and tor8 discussing this | 15:43.09 |
| | something about spot names etc | 15:43.15 |
| RobinWattsLenovo | Only in so far as agreeing the principle of having pixmaps having 's' spot planes in them. | 15:43.34 |
| | One idea discussed was to have an fz_spots object that has a refcount, an 'n' and a list of spot names. | 15:43.59 |
| | So pixmaps would have an fz_spots * reference in them. | 15:44.23 |
| | All the pixmaps in use by a given draw device should have the same fz_spots details, right? | 15:45.01 |
| | The spots in use don't change between groups, right? | 15:45.39 |
| mvrhel_laptop | RobinWattsLenovo: Yes. That is correct. So if there are 2 spots on the page we would have them for all the groups | 15:46.39 |
| | That is the way gs does it too | 15:46.57 |
| | RobinWattsLenovo: ok so question for you | 15:49.19 |
| | we will also need to have "equivalent" cmyk or rgb colorants for the spots. I guess that is already in there for the gproof device? | 15:50.38 |
| | Longer term (like graphexpo time) to get proper rendering of the Altona files to an RGB pixmap for iOS application we actually need to render to some type of deviceN pixmap and map that to RGB | 15:54.37 |
| | RobinWattsLenovo: Hence the need for equivalent cmyk colorants. Some of this stuff is going to be done outside the library I suppose. I.e. set up the pixmap and do the conversion. Just stuff to keep in mind | 15:56.23 |
| RobinWattsLenovo | mvrhel_laptop: The current fz_separations structure has name/cmyk/rgba equivalents. | 15:56.39 |
| mvrhel_laptop | great | 15:56.47 |
| RobinWattsLenovo | I think the plan will be that when you create a draw device it'll default to mixing to composite. | 15:57.48 |
| | but if you give it a list of spots, it'll keep those ones as real spots. | 15:58.07 |
| | That seems sanest to me. Does it sound reasonable to you? | 15:58.28 |
| mvrhel_laptop | RobinWattsLenovo: So if I want all the spots that occur on the page, is it easy for me to ask for that? | 15:59.01 |
| RobinWattsLenovo | mvrhel_laptop: Presumably we'll have an fz_page_spots(ctx, page); call that returns details of the spots on a page. | 15:59.46 |
| mvrhel_laptop | ok great | 15:59.55 |
| RobinWattsLenovo | Then we'll have an fz_new_draw_device_with_spots(...) call that takes that spots list... | 16:00.07 |
| | and fz_new_draw_device() will just call fz_new_draw_device_with_spots with a NULL list. | 16:00.27 |
| mvrhel_laptop | ah ok | 16:00.43 |
| RobinWattsLenovo | (I'm making this up as I go along, so please feel free to point out any obvious thinkos) | 16:01.03 |
| mvrhel_laptop | RobinWattsLenovo: this all sounds good to me. | 16:03.30 |
| | brb phone | 16:04.19 |
| avih | tor8: hopefully finally.. https://0x0.st/0zk.txt | 16:04.36 |
| RobinWattsLenovo | mvrhel_laptop, tor8: There is a commit on my repos that rejigs the fz_separations stuff a bit. I'm wondering if fz_separations is exactly the fz_spots structure we want ? | 16:10.46 |
| | The GProof device requires us to be able to 'enable/disable' separations (by which it means include/remove them from rendering) | 16:15.13 |
| | Should we maybe extend that so we can set them to be 'excluded/spot/composite' ? | 16:15.52 |
| | The user could set: 0 = excluded, 1 = composite, 2 = spot | 16:17.02 |
| | Now GProof is unusual in that the format itself can enable/disable spots, whereas most sane things will require spots to be excluded by the draw device at render time. | 16:18.13 |
| | so if we try to set a spot to be excluded and the format doesn't support it, we can set the value in the spots array to 3, and the draw device can know to exclude it at render time. | 16:19.05 |
| | That gives a coherent view from both sides of the interface, I think. Thoughts? | 16:19.24 |
| mvrhel_laptop | RobinWattsLenovo: that makes a lot of sense to me. | 16:26.01 |
| | RobinWattsLenovo: one question though | 16:26.22 |
| | actually no. never mind I think I have my head wrapped around it | 16:26.45 |
| RobinWattsLenovo | I'm glad someone does :) | 16:29.44 |
| mvrhel_laptop | RobinWattsLenovo: I am just thinking about this scenario. If someone wants to generate a PNG output, which properly renders spots, transparency, output intent etc, we may really need to prerender to a CMYK+spots+alpha pixmap before creating the RGB+alpha pixmap. Where does this sort of thing get done? In mudraw? | 16:33.57 |
| RobinWattsLenovo | Because the PDF might have a CMYK blend space in it? | 16:35.00 |
| mvrhel_laptop | That is mudraw would create allocate the CMYK+spots+alpha pixmap, mupdf would render to it, and the mudraw would handle the rest to get it to RGB+alpha | 16:35.03 |
| | RobinWattsLenovo: Well if the output intent is CMYK | 16:35.42 |
| RobinWattsLenovo | just a tick. | 16:35.46 |
| mvrhel_laptop | and we are dealing with overprint for example | 16:36.24 |
| | actually any case that we are dealing with overprint will need to be done in CMYK | 16:36.43 |
| RobinWattsLenovo | ok, so the caller would say dev = fz_new_draw_device(.... pix) where pix is a pixmap in the required final output state. | 16:37.10 |
| | so in this case RGB+alpha | 16:37.44 |
| | OK, I may need to backtrack and change my mind over how stuff works... | 16:38.08 |
| | We call dev = fz_new_draw_device(.... pix) and we pass in an rgb + alpha pixmap. | 16:39.28 |
| | That says "I want rgb+alpha as my final result" | 16:39.39 |
| | we don't do anything special about spots (i.e. we don't disable them or anything) | 16:40.03 |
| | so by default, we'll get 'composite'. | 16:40.09 |
| | argh, ok. let me start again, but with a question.... | 16:41.20 |
| | in gs, if we want overprint simulation, we have to request it, right? | 16:41.38 |
| | In all cases, we should pass in to the draw device a pixmap in the exact format that we want to get out. An RGB+Alpha pixmap will get us a result with no overprint simulation, just composite colors. | 16:43.06 |
| | If you want overprint simulation then you request a 'draw_device_with_spots' and you pass in an RGB+spots+Alpha pixmap, where the spots structure that has all the spots marked as 'composite'. | 16:44.05 |
| | The draw device can then internally make cmyk+spots pixmaps as required and do the overprint simulation with them. Then it can produce the final blended output at the end. | 16:45.21 |
| mvrhel_laptop | RobinWattsLenovo: Sorry had to reboot | 16:47.09 |
| RobinWattsLenovo | No worries. Wait for that to come through in the logs and see if you can make sense of it. | 16:47.29 |
| | Actually, let me say it again. | 16:47.39 |
| | in gs, if we want overprint simulation, we have to request it, right? | 16:47.41 |
| | In all cases, we should pass in to the draw device a pixmap in the exact format that we want to get out. An RGB+Alpha pixmap will get us a result with no overprint simulation, just composite colors. | 16:47.45 |
| | If you want overprint simulation then you request a 'draw_device_with_spots' and you pass in an RGB+spots+Alpha pixmap, where the spots structure that has all the spots marked as 'composite'. | 16:47.47 |
| | The draw device can then internally make cmyk+spots pixmaps as required and do the overprint simulation with them. Then it can produce the final blended output at the end. | 16:47.49 |
| mvrhel_laptop | RobinWattsLenovo: Yes that is what my thinking was also | 16:48.42 |
| | You request what you want | 16:48.47 |
| RobinWattsLenovo | so everything remains neatly packaged under the API, and the tools remain as dumb as possible. | 16:49.10 |
| mvrhel_laptop | If you do RGB+alpha, there is not going to be any overprint and all the spots will use alternate tint transforms | 16:49.23 |
| | RobinWattsLenovo: question | 16:49.52 |
| | how does the draw device know what form to create the final blended output? | 16:50.20 |
| RobinWattsLenovo | mvrhel_laptop: Right. But if you say RGB+alpha+spots (where there are no extra channels for the spots, they are all set to composite), you enable overprint simulation and it works properly. | 16:50.21 |
| mvrhel_laptop | RobinWattsLenovo: no it wont | 16:50.33 |
| RobinWattsLenovo | mvrhel_laptop: I'm confused. | 16:50.44 |
| mvrhel_laptop | CMYK overprint cant work with RGB | 16:50.58 |
| RobinWattsLenovo | overprint is always in CMYK+Spots, right ? | 16:51.25 |
| mvrhel_laptop | yes. you said RGB+spots | 16:51.37 |
| RobinWattsLenovo | so if the draw device gets passed an RGB+alpha+spots pixmap, then the first thing it will do is to make a cmyk+alpha+spots pixmap internally and render to that. | 16:52.15 |
| | Then at the end it'll convert it back down. | 16:52.37 |
| mvrhel_laptop | oh ok | 16:52.43 |
| | so question | 16:53.10 |
| | Lets say I am going out to PNG, but I want to get rendering as if I had overprint and spot support. How does that work? | 16:53.46 |
| RobinWattsLenovo | So this blows a hole a bit in what I was saying before, in that while all the pixmaps in use by the draw device will have the same set of named spots etc, some will be disabled in some pixmaps and not in others. | 16:54.24 |
| | You're going to PNG, so you want RGB+Alpha out. | 16:54.41 |
| mvrhel_laptop | yes | 16:54.45 |
| RobinWattsLenovo | So you make an RGB+Alpha pixmap. But you want overprint simulation, so you mix in the spots structure with all the spots set to composite. | 16:55.13 |
| | So your pixmap still only has 4 channels. | 16:55.41 |
| mvrhel_laptop | So I am still a little confused. Where is the CMYK+spots+alpha pix map created? | 16:56.44 |
| | And where is it later blended to RGB+alpha | 16:56.55 |
| RobinWattsLenovo | Ok, so right inside fz_new_draw_device. | 16:57.09 |
| mvrhel_laptop | and how do I specify I wanted that instead of just what happens today | 16:57.11 |
| RobinWattsLenovo | it looks at the callers pixmap, to see if it has a non NULL spots record. | 16:57.27 |
| mvrhel_laptop | oh | 16:57.40 |
| | Sorry I am a little slow. I am coming around now | 16:58.04 |
| RobinWattsLenovo | If it does, it says to itself "Ah, the caller wants me to handle spots correctly - I'd better be working in a CMYK+Spots environment" | 16:58.08 |
| mvrhel_laptop | yes | 16:58.14 |
| | and then when its done, it collapses it to the target pixmap | 16:58.25 |
| RobinWattsLenovo | So it makes itself a cmyk+alpha+spots pixmap and works from that. | 16:58.25 |
| mvrhel_laptop | appropriately | 16:58.33 |
| RobinWattsLenovo | Right. When we close the draw device. | 16:58.37 |
| mvrhel_laptop | ok | 16:58.40 |
| | That is nice | 16:58.43 |
| RobinWattsLenovo | (As I say, I'm making this up as I go along) | 16:58.57 |
| mvrhel_laptop | Hence your comment or RGB+spots+alpha | 16:58.59 |
| | but the draw device will create CMYK+spots+alpha and do the conversion at the end | 16:59.20 |
| RobinWattsLenovo | Yes. | 16:59.24 |
| mvrhel_laptop | ok I follow now | 16:59.29 |
| RobinWattsLenovo | If we have that above the draw device interface, it'll just make tools more complex. | 16:59.49 |
| mvrhel_laptop | That is clean in that it keeps things all right there in the draw device | 16:59.52 |
| | I like it | 17:00.06 |
| | RobinWattsLenovo: ok. Let me see if I can fix my blending issues. I have to step out for a bit here to run Ethan to the bus for his class | 17:01.06 |
| RobinWattsLenovo | OK. ttyl. | 17:01.12 |
| mvrhel_laptop | thanks for the discussion RobinWattsLenovo | 17:01.25 |
| RobinWattsLenovo | Thank you! | 17:01.32 |
| tor8 | RobinWattsLenovo: so the fz_spots structure would have a flag to enable "overprint" which would add a second layer of render to cmyk then convert to rgb for the final step? | 21:58.31 |
| | I think it would be okay to say if you want overprint, pass a cmyk pixmap to the draw device, and convert to rgb when saving to png | 21:58.51 |
| | and yes, it seems like the fz_separations and fz_spot_list could well be the same structure | 22:01.50 |
| mvrhel_laptop | RobinWattsLenovo: I know its late there... | 22:56.19 |
| | I may have some softmask mupdf questions for you tomorrow | 22:57.25 |
| | ah figured it out | 23:30.33 |
| | an issue with softmasks not being treated as isolated groups which they must be | 23:30.52 |
| | Forward 1 day (to 2017/06/30)>>> | |
Log of #mupdf at irc.freenode.net.