| <<<Back 1 day (to 2017/09/11) | 20170912 |
tor8 | Robin_Watts: I don't see anything problematic with "Start to rework plotters." | 10:04.40 |
| Robin_Watts: "Ensure colorspace colorants are named for ICC spaces too." LGTM | 10:04.56 |
Robin_Watts | Ta. | 11:08.26 |
tor8 | Robin_Watts: in "Fix separation pixmap conversion functions for DeviceN." fz_clear_pixmap already looks at is-subtractive so the fz_clear_pixmap_with_value if-case is not needed | 12:00.24 |
| Robin_Watts: in the mapping of lost spots to process colors, the symmetry between the 4 subtractive/additive cases looks off | 12:05.18 |
| ss: v = sd; clamp dd + v * convert. | 12:05.54 |
| sa: v = 255-sd; clamp dd - v * convert. | 12:06.05 |
| as: v = sd; clamp dd - v * (1-convert) | 12:06.21 |
| aa: v = 255-sd; clamp dd - v * (1-convert) | 12:06.33 |
| looks like a + or - sign might be wrong | 12:06.43 |
| the -O flag commit LGTM | 12:08.59 |
| the "Fix Gradients" commit has a FIXME | 12:09.08 |
Robin_Watts | tor8: Thanks. I have to reboot my sodding machine now, so back in a mo, I hope. | 12:24.55 |
| tor8: I see what you mean about symettry. | 12:46.03 |
| tor8: That FIXME is copied from existing code. | 13:16.21 |
| I can't tell you why it was there :) | 13:16.53 |
tor8 | me neither! | 13:16.57 |
Robin_Watts | oh, it came from the 'Add spots to fz_pixmaps'. | 13:18.15 |
| So I think this commit *is* the fixme. | 13:18.21 |
| I'll remove it. | 13:18.24 |
tor8 | Robin_Watts: I never merged my warning fix for lcms2; on tor/lcms2-art is a commit. should I push, or is there something special needs doing for our lcms2 fork? | 13:27.51 |
Robin_Watts | tor8: I see you just put a load of commits in. | 13:28.21 |
| let me look at the lcms2 one. | 13:28.30 |
| tor8: Urm... the ContextID = ContextID; stuff is to ensure we don't get warnings about unused args. | 13:29.39 |
| The correct formulation should be (void)ContextID; | 13:29.47 |
tor8 | Robin_Watts: but they're used! | 13:29.51 |
Robin_Watts | oh! | 13:29.58 |
| ok then :) | 13:30.01 |
| lgtm. | 13:30.04 |
| Urm... | 13:30.11 |
| actually... let me just check that's not going to conflict with my lcms2art stuff. | 13:30.38 |
tor8 | unless the cmsSignalError etc are just macros that don't use ContextID | 13:31.03 |
Robin_Watts | no, it's good. go for it. | 13:31.10 |
tor8 | thanks. | 13:31.20 |
Robin_Watts | ok, I've tweaked the commits as requested. New ones on robin/spots | 13:32.54 |
Robin_Watts | lunches | 13:34.43 |
tor8 | Robin_Watts: up to and including "Fix whitespace in draw-blend.c" LGTM | 13:34.51 |
| Robin_Watts: I think it may be time to consider passing a struct (pointer or value) instead of the two score arguments to the paint functions :) | 14:19.49 |
Robin_Watts | tor8: OK. The gradients commit causes changes in our rendering, cos stuff now renders in deviceN before converting down to process colors. | 14:30.09 |
| The spec says that we should do that. | 14:30.14 |
tor8 | right, so we interpolate in DeviceN before the mapping, rather than mapping then interpolating in the process color | 14:30.42 |
| that's what the comment in the code said :) | 14:30.50 |
Robin_Watts | right. | 14:31.42 |
sebras | Robin_Watts: can I bother you with a review of sebras/master? | 14:34.45 |
Robin_Watts | Sure. Seems only fair given the massive chunk of reviews I've dropped on tor. | 14:35.10 |
sebras | Robin_Watts: I know, he's been cursing right next to me for a while. ;) | 14:35.36 |
Robin_Watts | sebras: "Do not lie" ? | 14:38.28 |
| OK, I get it. | 14:39.27 |
sebras | Robin_Watts: yes, tor helped me write that commit message. :) | 14:39.32 |
Robin_Watts | Are we sure the mac compiler doesn't have that bug now ? | 14:40.32 |
tor8 | Robin_Watts: fz_blend_separable_nonisolated has an interesting comment... but I shan't force you to understand it because I don't want to either! | 14:40.40 |
Robin_Watts | tor8: The "This looks like composition rather than decomposition" one ? | 14:41.02 |
tor8 | Robin_Watts: yes. | 14:41.08 |
Robin_Watts | yeah. The comment exactly encpsulates my current understanding :) | 14:41.25 |
| but it works, so I'm ignoring it. | 14:41.32 |
tor8 | the rest of that commit LGTM so go ahead with that one too. | 14:41.43 |
| the next commit ("Logic for Sep and Devicen") could do with some cleanup in the commit message. fz_colorspace_device_n_info is a cryptic function name with a more cryptic comment. | 14:43.52 |
sebras | Robin_Watts: the workaround comes from using gcc on macos, aren't they all using clang nowadays? | 14:44.25 |
| Robin_Watts: that's apparently in macos 10.7 from 2012. | 14:44.44 |
| Robin_Watts: and since I'm rearranging the code in other commits quite possibly the bug no longer triggers. | 14:45.29 |
tor8 | okay, now I get the function. it's connected to the DeviceN type enum. | 14:46.51 |
| I think this could be part of the colorspace-type enum I mentioned wanting yesterday | 14:47.23 |
| but that can be a later cleanup | 14:49.13 |
| so "Logic for Sep and Devicen" only needs some commit message cleaning (Devicen to DeviceN consistently, etc) | 14:49.33 |
| and I should teach mvrhel to use a period at the end of the initial commit sentence. | 14:49.54 |
| the colorspace.flags enum values living in two headers irks me. maybe FZ_HAS_CMYK = (FZ_CS_LAST_PUBLIC_FLAG << 1) or something to that effect? | 14:51.11 |
| in the "Change colorspace 'device_n' field to be a flags word." commit | 14:51.47 |
Robin_Watts | tor8: sorry. on phone. brb. | 14:58.26 |
bencc | a web service that converts pdf to svg by calling mupdf from the command line can use the opensource license without releasing the project code? | 15:06.14 |
Robin_Watts | bencc: Not necessarily. | 15:06.34 |
| Lookup the difference between the AGPL and the GPL. | 15:06.49 |
| A web service, falls under the "Software As A Service" category. | 15:07.05 |
| So, as such the whole web service (including all the other project code) needs to be AGPL licensed. | 15:07.36 |
bencc | what is the "project code" ? | 15:07.56 |
| if I'm using the SAAS inside docker, only the docker container? | 15:08.12 |
Robin_Watts | basically, if you have a web service that takes a PDF, and feeds it to MuPDF and then does something with the result... all that code. | 15:10.55 |
| conceivably that could be just the contents of a docker container, yes. | 15:11.09 |
| but if you squirt data from that container over to some other service elsewhere in a different docker container, that too, I think. | 15:11.39 |
bencc | ok | 15:13.21 |
| thanks | 15:13.24 |
Robin_Watts | basically, you can't escape open sourcing stuff by splitting it into a new container. | 15:17.29 |
sebras | Robin_Watts: LGTMed? | 15:33.41 |
Robin_Watts | sebras: sorry. All but the last one, yes. | 15:40.35 |
| For the last one, nicer to use break rather than ; /* nothing to do */ I think? | 15:41.42 |
| and i don't understand why TRYLATER is special cased in the last hunk of the last one. | 15:43.31 |
sebras | Robin_Watts: because we used to throw upon TRYLATER in the last hunk, but we forgot to drop the stream. | 16:33.17 |
| Robin_Watts: in the normal case we just warn and continue so in the end the stream will be returned and (hopefully!) dropped by the caller. | 16:33.46 |
| Robin_Watts: why TRYLATER was there in first case I don't know. | 16:34.03 |
Robin_Watts | sebras: OK. lgtm. | 16:34.43 |
| tor8: For the logs: Updated on robin/spots | 18:11.15 |
happy_gnu[m] | Hello | 20:04.28 |
mubot | Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 20:04.28 |
happy_gnu[m] | When using f-droid versión there is a reflow made for PDF's | 20:07.39 |
| But if you are at the bottom of the page and change to next page you are still at the bottom | 20:08.08 |
| So you have to move up and down a lot | 20:09.33 |
| Is it possible to implement a continued reading or that when moving to next page you start at the top so reading is a little smoother? | 20:10.25 |
| Forward 1 day (to 2017/09/13)>>> | |