| | <<<Back 1 day (to 2018/06/17) | 20180618 |
| tor8 | inflex: changing the API (causing some breakage along the way) is the preferred mupdf approach. it's our way to keep a 15 year old code base from growing too baroque. | 08:51.49 |
| inflex | So you'd rather see fz_enumerate_selection() take on another parameter rather than a flags var in fz_context_s ? | 09:09.09 |
| | ( not that I see any of this modified code ever migrating outside of its use ) | 09:10.46 |
| domidumont | Hi, On Android, mupdf always opens a PDF file at the first page. It does not remember where I left of, even if the file path has not changed. Is that expected ? | 09:19.57 |
| tor8 | inflex: yes. that said, I've got some revisions to the selection/enumeration API already planned out. | 09:33.51 |
| | two main changes will be changing the highlight from rects to quads (to cope with rotated text) and adding a flag word to select by word breaks | 09:35.14 |
| inflex | Okay, so if I had started my project 3 months later, you'd have done all my hard work already :D :D | 09:48.41 |
| | I just hope after I do all this work, that I use it more than just for what I'm doing it for now. | 09:59.59 |
| | Question, is there a way in the enumerate function that I can test for word boundary alignment? ie, A17 matches only A17, instead of BA17 or A179 | 10:31.47 |
| | I suppose ->next should be null for the latter, and the node should be the first node for the former? | 10:32.27 |
| paulgardiner | I'm confused by this: | 10:38.30 |
| | n = alpha + s + fz_colorspace_n(ctx, colorspace); | 10:38.37 |
| | if (stride < n*w && stride > -n*w) | 10:38.38 |
| | fz_throw(ctx, FZ_ERROR_GENERIC, "Illegal stride for pixmap (n=%d w=%d, stride=%d)", n, w, stride); | 10:38.40 |
| | So, does the samples array I pass into fz_new_pixmap_with_data need to have an additional byte per pixel for each separation? | 10:40.28 |
| inflex | After all these years, I've never had to deal with this sort of statement in C, "return *endp = end, s;" ( from static const char *find_string() ). Can someone explain the a=b,c; expression? I know (a)?b:c but... | 11:07.58 |
| pink_mist | I'm not a C guy, so I can't say for certain, but I'd expect that it changes the *endp pointer and then returns s | 11:10.20 |
| | though I'm not sure why that wouldn't be done in two separate statements | 11:11.46 |
| | perhaps try asking in #c or ##c | 11:12.35 |
| tor8 | paulgardiner: the number of bytes per samples in a pixmap is: number of color components for the colorspace, number of separation channels, and 1 for alpha (if present) | 11:18.31 |
| | so a pixmap with RGB, one separation, and alpha = 5 bytes per pixel | 11:18.58 |
| | inflex: word boundaries exist at the beginning of a line, the end of a line, and when the next/previous character is a space | 11:20.50 |
| | so within the fz_stext_line you need to check if it's the first character, last character, or followed by a space (ch == line->first_char || ch->next == NULL || ch->next->c == 32) should do it | 11:23.09 |
| | inflex: or add a on_word_boundary callback to the enumerator | 11:24.01 |
| | inflex: or implement a regexp search :) | 11:24.08 |
| inflex | Oh so tempting for the last option :cough: :D | 11:35.04 |
| | pink_mist, yes, sometimes these compound statements do make me scratch my head a bit. Clearly I needed to read more obfusicated-C-competition entries. | 11:36.17 |
| tor8 | inflex: a comma expression is always the result of the last part | 11:40.43 |
| | so (a, b, c) evaluates to c | 11:40.51 |
| | but any side effects from a and b are also made | 11:40.59 |
| | pink_mist: inflex: mupdf uses that idiom when returning multiple values via out-parameters | 11:41.54 |
| pink_mist | that's kindof what I figured =) | 11:42.58 |
| inflex | thanks, appreciate that. Good, but terrifying that in spite of the years, I still learn new things. | 11:44.42 |
| paulgardiner | tor8: I'm trying to refresh the proofing code in muso that Michael and I worked on. It seems to work, but perhaps only because fz_count_active_separations is returning 0 for the file I'm testing. | 11:54.47 |
| | ... or is that separations need explicit activation? | 11:56.23 |
| | "or is it", I meant | 11:59.16 |
| tor8 | separations need explicit activation yes. | 11:59.25 |
| paulgardiner | Ah okay. That makes sense. | 11:59.50 |
| | I'm also wondering what effect passing 1 for alpha has. I realise that it informs mupdf that there's an extra bpp, but does it also cause all rendering operations to calculate an alpha pixel? Is there a way to get the speed of nonalpha rendering into a buffer that has the extra bpp. | 12:04.04 |
| tor8 | paulgardiner: alpha vs non-alpha for RGB should make little difference in terms of speed | 12:04.44 |
| paulgardiner | Oh okay, good | 12:04.55 |
| tor8 | if we need an alpha plane for transparency blending, we create intermediate buffers with alpha planes | 12:05.02 |
| | this is just to save some memory on the final destination | 12:05.11 |
| | you waste a bit of memory bandwidth, but save a bit on having pixels neatly aligned to words | 12:05.51 |
| paulgardiner | Do some color spaces require more grunt than others? | 12:06.18 |
| tor8 | robin coded up some optimized SIMD-like painting functions that work nicely for RGBA | 12:06.21 |
| | CMYK is not recommended unless you absolutely need it | 12:06.51 |
| | it's got awkward alignment, not many optimized functions, and has weirdness to cope with alpha blending | 12:07.10 |
| | but RGBA or BGRA or Gray or Gray+Alpha should all be fairly good | 12:07.31 |
| | or just plain RGB or BGR too | 12:07.37 |
| paulgardiner | The muso proofing code seems to prevent use of the previous default returned by fz_device_rgb, and instead uses DeviceP3 read from a file as default. | 12:08.08 |
| tor8 | the win32 viewer renders to BGR since that's the format windows uses internally | 12:08.13 |
| paulgardiner | On rendering speed, I was wondering about RGBX compared to RGBA | 12:08.51 |
| tor8 | you'll have to ask Robin or mvrhel ... I'm not familiar enough with the proofing workings to be comfortable giving a good answer for that | 12:09.02 |
| | we don't do RGBX :) | 12:09.08 |
| | we do RGB and RGBA | 12:09.20 |
| paulgardiner | Yeah, that was what I was wondering. I couldn't see a way to request RGBX in the API | 12:09.59 |
| tor8 | both should be similar enough to not be worth worrying about; and any gains had from one will probably be lost in the conversion to whatever you're feeding it to draw with | 12:10.12 |
| | so it's best to pick the one the API you're working with wants | 12:10.28 |
| | s/the one/the format/ | 12:10.52 |
| | RGBA cleared to a solid white before rendering will work as a standin for RGBX there | 12:11.31 |
| | it's premultiplied alpha, so you may need to let the graphics API know that, if feeding pixmaps with actual transparent parts | 12:12.08 |
| Robin_Watts | If you use RGBA cleared to a solid white before rendering the premultiplied vs non-premultiplied isn't an issue (I think) | 12:12.55 |
| | All the final renders will end up with A = 255, so they are the same. | 12:13.23 |
| tor8 | that's what I was trying to get at, but robin stated it more clearly as always :) | 12:13.33 |
| paulgardiner | Thanks. That clears that up. | 12:33.33 |
| | Now I'm wondering why I see so much difference when I change the soft profile. AFAIKS, we are telling mupdf to render using the profile and then telling the OS to use it when deriving the image to display from the bitmap. I'd imagined that the intentions was that those two actions would mostly cancel out. | 12:41.03 |
| Robin_Watts | paulgardiner: It's not clear to me exactly what you're doing. | 12:46.45 |
| paulgardiner | Nor to me. :-) Some of this is Michael's. I should probably ask him. | 12:47.32 |
| Robin_Watts | Old MuPDF had no concept of profiles. We just used fixed conversions between colorspaces. | 12:48.03 |
| | New MuPDF has default profiles for RGB/CMYK etc, and any conversions between the spaces will be done with reference to those spaces. | 12:48.31 |
| | If I understand what you're meaning by "soft profile", then you're telling it to transform the output by a given profile at the end so you can see what it would look like on a given device. | 12:50.08 |
| inflex | tor8, thanks... now my searching/auto-filling is working even better with the "whole word" search ( in my case, basically the entire line had to be the match ) | 13:00.57 |
| peturvilj | Hi. Is there a way to make an option permanent for mupdf (on Linux)? I use all the time the option -C f2d5b8 and would like to make it the default. | 13:53.54 |
| Robin_Watts | peturvilj: alias mupdf "mupdf -C f2d5b8" (or whatever that command is) ? | 13:59.11 |
| peturvilj | Thanks Robin_Watts. I can do that but I was hoping for a way to create a proper configuration file. | 14:20.29 |
| moolc | tor8, sebras: congrats | 14:44.50 |
| sebras | moolc: ? | 14:44.59 |
| | moolc: ooh, something about soccer I bet. | 14:45.13 |
| Robin_Watts | sebras: Your sport team sported really hard. | 14:46.21 |
| moolc | sebras: retracted... you taiwanese spook you | 14:47.20 |
| sebras | Robin_Watts: wow! whom did they sport with? I might need to discuss this topic in a foreign language with a korean tomorrow. | 14:47.31 |
| Robin_Watts | sebras: Dunno. I was just bluffing. | 14:47.47 |
| sebras | Robin_Watts: you could have fooled me. | 14:48.55 |
| | Robin_Watts: apparently south korea, and our sports team outsported the south koreans. that's all I need to know. | 14:49.24 |
| moolc | judging by my experience with south koreans (employed by them for two years) they've probably outplayed themselves | 14:51.03 |
| Robin_Watts | You reckon they outsported themselves? | 14:53.55 |
| sebras | Robin_Watts: I'm trying to figure out how to say outsported in mandarin chinhese. that was not easy. | 14:54.42 |
| Robin_Watts | How do you say outsmarted? | 14:54.58 |
| moolc | outsported is not even in my dictionary.. web to the rescue | 14:55.14 |
| Robin_Watts | moolc: outsported is not a word. | 14:55.26 |
| moolc | Robin_Watts: au contraire | 14:56.08 |
| | according to the web | 14:56.11 |
| | https://www.wordplays.com/definition/outsported | 14:56.17 |
| sebras | moolc: I'm sad to see that there is nothing for mandarin. :( | 14:56.59 |
| moolc | sebras: try putonghua >B) | 14:57.15 |
| | and i'm willing to bet dollars for donuts (or is it the other way around) that there is a Yue word for it... | 14:57.49 |
| moolc | dreads the day when the final will be held... living 3.7 km away from the stadium where it will be held... sigh.. another sleepless night | 14:58.49 |
| | Forward 1 day (to 2018/06/19)>>> | |
Log of #mupdf at irc.freenode.net.