| | <<<Back 1 day (to 2017/04/09) | 20170410 |
| ray_laptop | so, finally figured out why changing the fillpage to UNTOUCHED causes a difference with shading. | 14:44.38 |
| | the "check_device_separable" was failing to classify the bitrgbtags device as SEP_LIN because 0,0,0 components in didn't produce color_index == 0 (it had the tag bit set for PATH in the "before" case. After the change, it was left at UNTOUCHED which is 0, so it classifies the device as SEP_LIN | 18:09.45 |
| | we generally prefer SEP_LIN since we can put fill_linear_color_trapezoid into the clist rather than having to "flat" fill_trapezoid | 18:10.59 |
| Robin_Watts | ray_laptop: Ah, yes. | 18:14.07 |
| ray_laptop | the shading difference is because the shading interpolation for the two paths is (slightly) different. | 18:15.52 |
| | but at least now I can ignore the minor differences (since I know the reason). | 18:16.42 |
| | Robin_Watts: I think that the bitrgbtags device should be SEP_LIN_STANDARD -- do you agree (the 3 components have encoding which is standard) ? | 18:21.40 |
| | the bitrgbtags device has a tag part of the gx_color_index, but that isn't counted in the num_components | 18:22.26 |
| Robin_Watts | Not sure if the tests will detect it that way though. | 18:22.47 |
| | In fact, I strongly suspect they won't. | 18:23.11 |
| ray_laptop | Robin_Watts: is looks to me like the test for STANDARD at the end of check_device_separable only checks the num_components | 18:24.12 |
| Robin_Watts | right, but there are now 2 tests. check_device_separable and... another one. | 18:24.47 |
| | hold on, while i look. | 18:24.53 |
| | yeah. check_device_compatible_encoding is the bit that I think will fail to detect it as SEP_LIN_STANDARD. | 18:25.55 |
| | ooh. | 18:26.17 |
| | possibly we could rescue it by setting the tag to be 0 at the start of check_device_compatible_encoding and resetting it at the end. | 18:26.53 |
| | oh, but is that safe? | 18:27.24 |
| | The point of this dance is to figure out if color_indexes encoded into the clist by any pdf14 compositor can safely be read back out validly by the devices decode_color, right ? | 18:28.51 |
| ray_laptop | Robin_Watts: I've imposed a new requirement that if a device is SEP_LIN and has tags, then the comp_shift[num_components] and comp_mask[num_components] must be for the tag info | 18:29.09 |
| Robin_Watts | Does the pdf14 compositor encode tags too ? | 18:29.36 |
| ray_laptop | and we know if the DEVICE_ENCODES_TAGS | 18:29.40 |
| | Robin_Watts: the pdf14 device maintains a tag plane if DEVICE_ENCODES_TAGS is set (has_tags) | 18:30.10 |
| Robin_Watts | so colors can safely be encoded by pdf14 and decoded by the device if we decide to skip transparency? cool. | 18:30.44 |
| ray_laptop | I have to run an errand. bbiav | 18:31.12 |
| | Robin_Watts: sorry. back now. Yes, skipping pdf14 transparency is safe with tagged devices | 19:16.07 |
| Robin_Watts | sounds good to me then. | 19:20.53 |
| | Forward 1 day (to 2017/04/11)>>> | |
Log of #ghostscript at irc.freenode.net.