| | <<<Back 1 day (to 2020/10/26) | Fwd 1 day (to 2020/10/28)>>> | 20201027 |
| user38 | Greetings everyone. Robin_Watts, chrisl, sebras: as discussed previously, I have opened https://bugs.ghostscript.com/show_bug.cgi?id=703047 and attached all my Solaris 10 and (Ultra)SPARC patches to it. | 09:43.03 |
| | ...In the hope that they will at least be useful as a reference. | 09:43.35 |
| Robin_Watts | user38: Many thanks! | 10:15.44 |
| user38 | Robin_Watts you're very welcome. | 10:24.24 |
| Robin_Watts | user38: The sparc fixes for lcms2 and the display list alignment stuff are all on master now. | 10:28.28 |
| user38 | Ah, you made fixes in the meanwhile? | 10:28.55 |
| | How'd the review go? | 10:29.15 |
| Robin_Watts | The display list alignment one was the one you had a preview of. | 10:29.25 |
| | Fine, thanks. | 10:29.53 |
| user38 | Cool when a plan comes together <3 | 10:30.05 |
| | Well, ladies and gentlemen, I leave you for now... if there are any questions, I will be checking the two bug reports until Friday evening, please feel free to write them there. | 13:51.55 |
| malc_ | Robin_Watts: your rectangle changes broke certain functionality in llpp, can you summarize the change before i dive headfirst into it? | 18:27.06 |
| Robin_Watts | malc_: sure. | 18:27.20 |
| | Basically, it's a change to the representation of infinite and empty rectangles. | 18:28.18 |
| | I think, IIRC, we used to represent infinite rectangles by rectangles with x0 > x1 or y0 > y1 | 18:30.07 |
| | and empty rectangles used to be x0 = x1 or y0 = y1 | 18:30.21 |
| | That is a pain because we have no way of representing zero area rectangles. | 18:30.47 |
| | (like (0,0) to (100,0) ) | 18:30.58 |
| | So, I've changed the representation. | 18:31.13 |
| | infinite rectangles now have specific coord values (0x8000000, 0x8000000), (0x7fffff80, 0x7ffffff80) | 18:32.06 |
| | and empty rectangles are any where x0 > x1, or y0 > y1. | 18:32.38 |
| | So, if you're only ever using our rectangle functions, you should have no problems. | 18:33.04 |
| | If you're checking the values yourself, then you might get problems. | 18:33.20 |
| malc_ | Robin_Watts: i do poke into .x/y values | 18:33.33 |
| Robin_Watts | (previously x1-x0 = 0 for empty rects, typically) | 18:33.47 |
| malc_ | Robin_Watts: and i'm getting problems, thanks for explanation | 18:34.00 |
| | let's see if i can find the problem in my code | 18:34.12 |
| Robin_Watts | If you want widths, then use fz_irect_width() for example. | 18:34.32 |
| malc_ | i have following loveliness | 18:35.26 |
| | (x >= q->ul.x && x <= q->ur.x && y >= q->ul.y && y <= q->ll.y) | 18:35.30 |
| | guess you have some "within" helper | 18:35.47 |
| | but it didn't exist when i wrote that or something | 18:35.55 |
| Robin_Watts | malc_: The mupdf datastructures don't use ul, ur, so that must be your code? | 18:51.43 |
| malc_ | Robin_Watts: fz_quad does | 18:53.57 |
| Robin_Watts | oh, I haven't changed fz_quad stuff, AFAIK. | 19:00.03 |
| malc_ | phrase having this form - "i haven't" and followed by "AFAIK" is bizarre tu uneducated eastasian proles such as myself | 19:01.56 |
| sam_ | I haven't changed blah, as far as I know | 19:02.16 |
| malc_ | i haven't i know | 19:02.37 |
| sam_ | no | 19:02.47 |
| malc_ | as far is completely bizarre in the context | 19:02.52 |
| sam_ | you misunderstood | 19:02.57 |
| | "oh, I haven't changed fz_quad stuff, as far as I know" it means "as much as I can remember... I did not change it" | 19:03.11 |
| | it is like saying, "I did not change it assuming I remembered fully" | 19:03.24 |
| | it is explaining there is some possible error but unlikely | 19:03.33 |
| | like maybe he did not verify 100% | 19:03.37 |
| malc_ | sam_: i understand what it MIGHT mean, but c'mon words do have a straightforward meaning to | 19:03.49 |
| sam_ | I'm just explaining what it means to help | 19:04.10 |
| | it's a common pattern | 19:04.16 |
| | I honestly never realised it might be confusing | 19:04.25 |
| malc_ | sam_: appreciated but defies logic | 19:04.37 |
| | erm... appreciated, but the wording still defies logic | 19:04.56 |
| Robin_Watts | malc_: I'm not sure what's confusing. | 19:04.57 |
| malc_ | Robin_Watts: English is | 19:05.47 |
| | or rather all natural languages | 19:05.56 |
| Robin_Watts | As far as I know, none of my fz_rect changes should have had any changes with respect to fz_quads. Of course, it's always possible that there is some dependency there that I may have overlooked, but nothing has shown up in my testing. | 19:06.19 |
| malc_ | Robin_Watts: i think i know what's going on. my code uses an empty rect and then expands it with the bounding boxen of fz_chars that mach criteria | 19:07.48 |
| | it used to work but now it doesn't | 19:08.00 |
| | makes sense? | 19:08.02 |
| | expands == fz_unionizes | 19:08.43 |
| sh4rm4^bnc | btw while reading fitz headers i noticed there are many API description comments that refer to variables that are not actually in the function signature | 19:08.45 |
| | re: overlooked | 19:09.32 |
| malc_ | sh4rm4^bnc: programmers tend to suck at writing documentation... and comments | 19:09.48 |
| sh4rm4^bnc | especially if that "documentation" isnt actually ever exported | 19:10.25 |
| | because e.g. javadoc would tell you "hey, the @param you refer to doesn't exist" | 19:11.15 |
| malc_ | Robin_Watts: AFAICS union of empty_rect with anything is broken | 19:22.38 |
| Robin_Watts | malc_: I'll check it out, ta. | 23:29.00 |
| | malc_: const fz_rect fz_empty_rect = { FZ_MAX_INF_RECT, FZ_MAX_INF_RECT, FZ_MIN_INF_RECT, FZ_MIN_INF_RECT }; | 23:30.49 |
| | so that's a invalid rect with large bounds. | 23:31.01 |
| | fz_union_rect(a,b) | 23:31.33 |
| | if a is invalid, then we return b. | 23:31.45 |
| | if b is invalid, then we return a. | 23:31.55 |
| | So fz_unioning anything with the empty rect should return what you are unioning. | 23:32.11 |
| | That looks right to me. You may need to be more specific about exactly what calls are going wrong. | 23:32.31 |
| | <<<Back 1 day (to 2020/10/26) | Forward 1 day (to 2020/10/28)>>> | |
Log of #mupdf at irc.freenode.net.