| | <<<Back 1 day (to 2017/06/23) | 20170624 |
| tor8 | Robin_Watts: hm, I think keeping cmyk and spot colors in fz_pixmaps inverted all the time makes a lot of sense | 00:30.50 |
| | and all cmyk colors represented as bytes in the 0..255 range would also be inverted | 00:31.21 |
| | and we just need to take care of inverting when going to-from float vectors | 00:31.32 |
| | and for outputting to image files | 00:31.42 |
| | that would let us do premultiplied cmyk+alpha and keep the blending logic as is | 00:32.03 |
| | the second question is doing pixmap color conversions on premultiplied alpha pixmaps | 00:32.23 |
| | hopefully we can avoid it altogether, but it might make sense to have a=1 for non-premul and a=2 for disassociated alpha | 00:32.54 |
| | and have a fz_ensure_pixmap_is_premultiplied before plotting with it | 00:33.27 |
| | or take the hit and divide, color-convert, multiply | 00:33.40 |
| | another argument in favour of premul alpha is image interpolation. | 00:34.10 |
| | interpolating the color channels and alpha channels in disassociated alpha can result in bad color fringing due to color values in the 'transparent' pixels being interpolated and showing through when they shouldn't | 00:34.49 |
| sebras | why does mupdf have the warning in do_hash_insert()? | 04:09.50 |
| | on sebras/separated I have broken 9322cd into several pieces, the last one being the one that causes page 1143 of pdfref17.pdf to warn. | 04:11.41 |
| | previously warnings could poentially be seen in the case of fz_resize_hash() or fz_hash_insert() | 04:13.44 |
| | but in the case of fz_store_item() care was taken to request a hash position which in turn avoided the warning | 04:14.03 |
| | now, why was it previously important to print the warning when resizing and inserting, but not important when storing an item? | 04:14.30 |
| | commit 9322cd might have made a mistake by now allowing the warning to be printed even in case of fz_store_item(), but... | 04:15.02 |
| | ... I wonder if the warning shouldn't just be removed completely..? | 04:15.22 |
| | the comment preceeding it even states that this is all legal! | 04:15.45 |
| | you'd lose the previously stored item of course, but one could argue that this is by design. | 04:16.09 |
| | and that anyone using the hash should be aware of this, i.e. don't store two distinct items whose keys will hash to the same values. | 04:16.50 |
| | this all means that if an item is about to be inserted to the store, the existing item will be returned. | 04:19.19 |
| | how does this affect reference counting? in fz_store_item() the new item is dropped and a new ref is taken for the existing item. | 04:19.45 |
| | this all seems quite consistent to me. | 04:19.55 |
| | I'm confused as to why we have a warning: why do we have a warning? | 04:20.05 |
| | I stumbled across this warning/assert while trying to get rid of my remaining patches. | 04:21.19 |
| RobinWattsLenovo | tor8: Yes, mvrhel and I discussed it yesterday, and we're trying for exactly that solution now (keeping subtractive stuff inverted). | 07:42.45 |
| atnbueno | Hi? | 10:21.49 |
| | Is there more information about the syntax for "mutool create" than the example at https://mupdf.com/docs/manual-mutool-create.html ? | 10:22.55 |
| sebras | atnbueno: I did a quick search in the mupdf git repo | 10:28.11 |
| | atnbueno: and I can only find the html page you mention along with a manpage that states even less information. | 10:28.41 |
| atnbueno | Yep :-( | 10:29.17 |
| sebras | atnbueno: if it is the content stream page information that you are unsure about then this can be found in the pdf reference manual. | 10:29.24 |
| | atnbueno: e.g. available here: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf | 10:30.27 |
| | atnbueno: if you explain what you want to do in more detail, someone might be able to help you. | 10:31.04 |
| atnbueno | Indeed :-) Let me give a look at that link... | 10:31.48 |
| | Wow. +1300 pages :-D | 10:32.10 |
| sebras | atnbueno: the content stream operator description starts at page 196, but yeah mutool create is supposed to be a low level way of creating PDFs. | 10:33.40 |
| atnbueno | And yes, there it is. The Tf, Tj, BT "commands". I didn't even know that was called "content stream" :-P | 10:34.26 |
| | I only want to be able to create single-page PDF with a bitmap as background, and some centered text on top | 10:35.08 |
| | I'm doing it for some whose computer knowledge is limited to Facebook amd Twitter :-D so I want it to be a "double click here, write your text, press enter and you'l get the PDF" | 10:36.56 |
| | *someone | 10:37.00 |
| sebras | atnbueno: to me it sounds like this is something that would be easily done in libreoffice/word or perhaps google docs..? | 10:39.13 |
| | atnbueno: I think mutool create is too lowlevel for you since you would likely need to sort out things like wordwrapping etc. on your own. | 10:40.15 |
| atnbueno | I was trying to go for a no-install, single-button solution, but you're right. Doing it with mutool create is too complicated. | 10:46.07 |
| | I guess I'll have to teach her Google Docs :-S | 10:46.24 |
| sebras | atnbueno: if you still want to script it perhaps you can look into asciidoc..? | 10:46.54 |
| atnbueno | Thanks, anyway. At least now I know whats a PDF content stream :-) | 10:46.56 |
| | *what's | 10:47.02 |
| | asciidoc? I'll give it a look. Thanks. | 10:47.46 |
| sebras | atnbueno: I guess asciidocs input is markdown style and so it might be easier to edit the layout. | 10:48.13 |
| atnbueno | Sounds like I was looking for :-) | 10:48.46 |
| | *like what | 10:48.56 |
| | Let's learn AsciiDocs :-) | 10:49.18 |
| | Bye | 10:49.20 |
| | Forward 1 day (to 2017/06/25)>>> | |
Log of #mupdf at irc.freenode.net.