| | <<<Back 1 day (to 2012/07/03) | 2012/07/04 |
| chrisl | bapt: where are you seeing the checksum differing - I get the same checksum as listed in the checksum files for ghostscript-9.05.tar.bz2 on our download site | 06:07.22 |
| | http://downloads.ghostscript.com/public/ | 06:07.42 |
| bapt | yes this morning everything is back to normal | 06:10.39 |
| | yesterday files from http://downloads.ghostscript.com/public/ where different from files from sf | 06:11.00 |
| | and the checksum of files from http://downloads.ghostscript.com/public/ was wrong | 06:11.29 |
| | tested fetching from and US and fetch from France | 06:11.45 |
| | weird | 06:11.51 |
| | anyway back to normal I can restart building packages | 06:12.15 |
| chrisl | Cool, thanks. | 06:19.35 |
| Robin_Watts | So, tor8, fz_predict_tif... | 09:20.44 |
| | You'd prefer it if I just memset out to 0 to start with? | 09:20.56 |
| tor8 | Robin_Watts: yeah. | 09:21.04 |
| Robin_Watts | I agree that would be faster/nicer. | 09:21.17 |
| | memset(out, 0, len) ? | 09:21.30 |
| tor8 | let me read the predictor code again to make sure. | 09:22.50 |
| Robin_Watts | no, len is bytes in, I believe. | 09:23.05 |
| tor8 | len is the size of the input buffer | 09:23.16 |
| Robin_Watts | and fz_predict_tiff always reads/writes a fixed amount, ignoring n. | 09:23.51 |
| tor8 | yeah, I'm having trouble remembering how this is supposed to work :( | 09:24.06 |
| | ah, yes. state->in and state->out are scanline sized buffers | 09:24.22 |
| Robin_Watts | ah, ok. | 09:24.52 |
| tor8 | and it fills state->in before calling the predict tiff/png function | 09:25.05 |
| | then empties state->out before calling it again | 09:25.38 |
| Robin_Watts | One of the changes customer 394 has made throughout mupdf is to reverse a lot of for loops, apparently. So they all count down. | 09:26.32 |
| tor8 | memset(out, 0, stride) | 09:26.33 |
| Robin_Watts | Do I have stride available? | 09:26.45 |
| | state->stride - I do. | 09:27.23 |
| tor8 | state->stride is available | 09:27.23 |
| | I don't like reverse for loops. I always get off by one errors on the exit condition :( | 09:28.13 |
| | or on the start... | 09:28.24 |
| Robin_Watts | for (i= 0; i < end; i++) is always equivalent to for (i=end; i > 0; i--) | 09:29.11 |
| tor8 | I don't believe you. | 09:29.35 |
| | first one i has values 0 through end-1, the other one 1 through end | 09:29.54 |
| Robin_Watts | (except that i goes the other way, yes) | 09:30.01 |
| tor8 | i = end; while (--i > 0) {} would be equivalent | 09:30.32 |
| Robin_Watts | the advantage is that 'end' is only evaluated once, and that under ARM (and other archs) we get the test against zero for free. | 09:30.51 |
| tor8 | no it wouldn't forget that. still too early for me. | 09:30.52 |
| | Robin_Watts: yeah, one less register needed for the loop comparison | 09:31.24 |
| Robin_Watts | for (i=end-1; i >=0; i--) goes through the correct values. | 09:31.29 |
| tor8 | Robin_Watts: #define FOR(i, end) is something I want but really don't want at the same time :) | 09:32.24 |
| Robin_Watts | tor8: Ah. Another issue they have is for certifcation (and I didn't know this)... | 09:32.45 |
| | For aviation (and other) products they need to be certified. | 09:32.57 |
| tor8 | Robin_Watts: for inner plotting loops, I'm okay with changing the loop direction | 09:33.04 |
| Robin_Watts | There are certification costs that apparently depend at least partly on "the numbers of decisions made". | 09:33.29 |
| tor8 | but for anything outside the "draw" module, I'm less happy | 09:33.33 |
| Robin_Watts | so apparently macros cost more than inlines. | 09:33.43 |
| tor8 | Robin_Watts: a branching metric? | 09:34.04 |
| Robin_Watts | I think so. | 09:34.12 |
| tor8 | well, I prefer inlines over macros in general but macros have the benefit of not being bound to specific types (like MAX, ABS, etc) | 09:34.38 |
| Robin_Watts | yeah. | 09:35.09 |
| | They are going to love fz_try/fz_catch :( | 09:35.18 |
| tor8 | are you sure they're going to be happy about setjmp? | 09:35.27 |
| | yeah, that. | 09:35.30 |
| Robin_Watts | That's only just occurred to me. | 09:35.45 |
| tor8 | Robin_Watts: well, maybe now that we have scavenging malloc, maybe they'd be okay with aborting if the scavenging malloc fails ;) | 09:36.10 |
| | or we should just suffer the pain and be annoyingly obnoxious about passing error codes :( | 09:36.46 |
| Robin_Watts | Updated tiff predictor patch pushed. | 09:37.04 |
| tor8 | or redesign certain bits to never use dynamic allocation | 09:37.06 |
| Robin_Watts | Lots of patches on my master branch - I forget which ones you've passed. | 09:37.50 |
| | possibly none of them. | 09:38.10 |
| tor8 | did sebras review "Fix bug in fz_write_buffer_bits"? | 09:38.33 |
| Robin_Watts | I don't think so. | 09:38.51 |
| tor8 | Robin_Watts: the other three on top LGTM | 09:38.55 |
| Robin_Watts | But I wrote some test code this time (also in that review) | 09:39.08 |
| sebras | tor8: no I haven't. sorry. | 09:39.37 |
| | I might do it tonight unless you feel like doing it. | 09:39.50 |
| tor8 | okay, I just remember you talking about it then :) | 09:39.50 |
| sebras | tor8: yes, I aimed to review it, but then I ended up paying my mother a visit instead... | 09:40.20 |
| tor8 | it's bit voodoo, my brain hurts :( | 09:40.34 |
| sebras | tor8: I know. drawing on paper was necessary for me to understand it. | 09:40.53 |
| | also I have to admit that there were some variable names that might be improved. it took some time for me to understand "shift" for instance. | 09:41.27 |
| Robin_Watts | It's the amount to shift by? | 09:42.16 |
| | OK, I've rebased so that that patch is on the top of the pile so I can push the rest. | 09:42.54 |
| sebras | Robin_Watts: yes, but what amount is that. it's the bits it need to be shifted by but taking unused bits into account. | 09:43.12 |
| | Robin_Watts: maybe I was just feeling a bit daft that evening but it really did take some time for me to figure out. :) | 09:43.42 |
| Robin_Watts | It's the amount val needs to be shifted by to get it in the right position to be inserted into the existing data byte. | 09:44.05 |
| | Let me add some more comments. | 09:44.54 |
| sebras | Robin_Watts: maybe the most important is whether val is supposed to always have the bits that will be inserted next at its most significant end. | 09:46.09 |
| | Robin_Watts: I think that's the case, but I'm not sure. | 09:46.22 |
| Robin_Watts | val never changes throughout the function. | 09:46.39 |
| | so that's absolutely not true. | 09:47.15 |
| | Updated version with more comments pushed for sebras to look at at his leisure. | 09:53.04 |
| sebras | Robin_Watts: ok, sorry for the inconvenience. :) | 09:55.01 |
| Robin_Watts | no, it makes sense to get it right. Otherwise I'll look back at it in 2 years and go.. eh? | 09:55.25 |
| sebras | Robin_Watts: now I've skimmed through your updated patch. oh I'm so happy! and it's not even friday! :) | 10:45.38 |
| paulgardiner | Robin_Watts: ping | 11:11.47 |
| Robin_Watts | pong | 11:27.11 |
| paulgardiner | clusterpush instructions: need ghostpdl.git checkout. How huge is that? | 11:32.43 |
| | Or can I use the stuff from the BD | 11:33.13 |
| | ? | 11:33.14 |
| | Ah pcl pdl. | 11:33.42 |
| | Silly me | 11:33.51 |
| Robin_Watts | You don't need a ghostpdl.git checkout. | 11:38.04 |
| | Let me phone you. Give me 5 mins. | 11:38.12 |
| paulgardiner | ok | 11:38.28 |
| | tor8: ping | 12:10.46 |
| tor8 | hi paul | 12:10.54 |
| paulgardiner | Hi. I want to look at the validation stuff today, but there's some uncertaintities about the best form for the api | 12:11.46 |
| tor8 | for mjs export or for interactive use? | 12:12.10 |
| paulgardiner | I've already added the concept an 'interactive' interface and widget objects. You can ask for the fz_interactive interface of a document and then use it to send in events and mess with widgets | 12:13.58 |
| | There's also a way to enumerate annotations which works directly from a document object | 12:14.29 |
| | We need to decide best how to unify them. | 12:14.45 |
| tor8 | right | 12:15.35 |
| paulgardiner | A widget is a special type of annotation, so it would be natural to have a method to turn annotations into widgets, or maybe drop widget as a separate concept | 12:15.38 |
| tor8 | how about hyperlinks? | 12:15.58 |
| paulgardiner | Or we should maybe have a separate widget enumeration | 12:16.11 |
| | Are they a type of annotation? | 12:16.35 |
| tor8 | yes | 12:16.57 |
| paulgardiner | Do otther than pdfs have them? | 12:17.13 |
| tor8 | XPS has hyperlinks, but nothing else | 12:17.24 |
| paulgardiner | Right. So annotation enumeration should be from a document rather than from an interactive interface, or XPS should also supply an interactive interface | 12:18.29 |
| | The first of those options is already the case | 12:18.42 |
| tor8 | I think the second option is a better design though. hyperlinks are interactive features :) | 12:19.17 |
| paulgardiner | True | 12:19.26 |
| tor8 | the question is more one of how much special consideration we give the different types | 12:19.39 |
| | whether to make a 'mega'-annotation object, or split them into distinct types | 12:20.03 |
| | such as link, widget, static appearance thingy that we don't really touch | 12:20.20 |
| paulgardiner | There is possibly a case for a separate widget enumeration because often one would be just interested in them | 12:21.05 |
| tor8 | we could separate them by how they behave with callbacks or by creating separate types and separate enumerators | 12:21.20 |
| paulgardiner | Currently we have separate types, but an enumerator for only one of them | 12:21.56 |
| tor8 | if we imagine a dumb no-js viewer, I reckon we wouldn't care about interactive forms but we still want to follow hyper links and render the appearance streams | 12:22.00 |
| paulgardiner | Yes. | 12:22.54 |
| tor8 | the link stuff is currently already a bit messy (with the link destination struct), so if you want to go ahead and ignore links feel free | 12:23.16 |
| | otherwise I think having both links and widgets with separate enumerators from fz_interactive is the way to go | 12:23.40 |
| | or links as a specific widget type, which we can special case in the viewers that don't do full widgets | 12:24.05 |
| | what makes a normal annotation different from a widget? | 12:24.43 |
| paulgardiner | So for now, I could just add an enumeration mechanism for widgets and add new methods to the widget object for interrogating validation info? | 12:25.28 |
| tor8 | that sounds reasonable | 12:25.53 |
| paulgardiner | Ok great. Ah just hold off for Robin to look at what we've discussed. He might have some thoughts that haven't occured to us yet. | 12:26.39 |
| | The stuff we talked about yesterday concerning different string encodings: it all seems pretty clear now. I'd be quite keen to have a go at using the existing fonts and reversing the tounicode function - just to see if it worked. | 12:28.07 |
| | I think for the initial release, I could get away assuming everything is ascii other than the strings coming back from javascript. | 12:29.06 |
| | I'd just need to cover the case of generating appearance streams from the result of a JS formatting action. If there are any top-bit set chars convert from UTF8 to the font encoding. | 12:30.24 |
| Robin_Watts | (sorry, on skype with a customer) | 12:30.45 |
| paulgardiner | Need to do it all properly eventually, but the above would cover many cases. | 12:30.59 |
| Robin_Watts | Ok, reading logs | 12:33.37 |
| | My personal feeling for the neatest design would be to unify links and annotations. | 12:35.17 |
| | Then have a single enumerator for them. | 12:35.36 |
| | and to have a 'type' as part of that enumerator (STATIC, LINK, TEXT WIDGET, COMBO BOX etc) | 12:36.10 |
| | and to have a function to map from an annotation pointer to a 'text widget' type etc. | 12:36.48 |
| malc_ | pdf_jsimp_v8.cpp:337 sire? i know most of you are british and all, but that's pushing it | 12:37.05 |
| paulgardiner | Maybe. That's certainly how PDF handles them internally, but on the other hand I think it may be quite likely that the app will mostly handle them in separate activitis | 12:37.24 |
| Robin_Watts | That blows pauls nice separation into a separate fz_interactive thing out of the water though. | 12:37.36 |
| | malc_: hehe. I think it's a typo for "side" :) | 12:38.51 |
| paulgardiner | malc_: :-) I'm struggling to figure out what word it should be. | 12:38.52 |
| tor8 | client parent object, obviously ;) | 12:39.18 |
| paulgardiner | ah. client-side object I think, | 12:39.36 |
| malc_ | Robin_Watts: i thought side too, but the sentence is strange still | 12:39.54 |
| Robin_Watts | malc_: Why? | 12:40.06 |
| paulgardiner | Oh yeah. 'parent' :-) | 12:40.12 |
| malc_ | Robin_Watts: cause i'm bloody illiterate russkie probably | 12:40.27 |
| Robin_Watts | The issue, AIUI, is that v8 objects can get garbage collected at arbitrary times. | 12:40.37 |
| | when they go away that can cause the last reference to an object in our app (on the "client side") to go away. | 12:41.20 |
| | So to prevent leaks the client side object needs to be destructed too. | 12:41.38 |
| paulgardiner | Yes. | 12:41.49 |
| | Well more that you'd like to get rid of the client-side as soon as possible | 12:42.07 |
| | You could hang on to them until the doc object is destructed | 12:42.37 |
| Robin_Watts | malc_: So far this morning I've spoken to Russians, Swedes and Romanians, all of whose English is better than mine :) | 12:42.51 |
| | Thank God for paulgardiner. He's from the west country, so doesn't really speak English :) | 12:43.29 |
| | And with that, it's lunchtime. bbs. | 12:44.00 |
| malc_ | Robin_Watts: ;) | 12:44.05 |
| paulgardiner | We use very expressive grunts | 12:44.31 |
| malc_ | paulgardiner: west country =? | 12:46.00 |
| paulgardiner | Part of the uk where people work the land in long white baggy smocks and chew pieces of straw. | 12:47.50 |
| malc_ | paulgardiner: sounds more like south of us, but i'll trust your word on it | 12:50.26 |
| paulgardiner | tor8: In the light of Robin's last thoughts, maybe I should update the fz_annot enumeration methods to take an fz_interactive in place of a fz_document, and provide a method to turn an fz_annot into an fz_widget (giving NULL if the annot isn't a widget). How does that sound? | 12:55.19 |
| tor8 | paulgardiner: so in essence subclassing annot -> widget and doing a down cast? | 12:57.16 |
| paulgardiner | Yeah | 12:57.30 |
| tor8 | I agree with the first part, moving the annot to interactive | 12:57.35 |
| | not sure about sub classing though | 12:57.41 |
| paulgardiner | Or I could drop fz_widget entirely in favourt of fz_annot | 12:58.05 |
| | I already have a class structure in fz_widget and fz_widget_text | 12:58.44 |
| | Maybe I should lose the lot. | 12:58.52 |
| tor8 | if I were doing it I'd start with two enumerators, but then I'm allergic to object oriented inheritance hierarchies | 12:59.17 |
| paulgardiner | But it does control which methods can be applied on the basis of type | 12:59.23 |
| | I'm not against two enumerations. | 13:00.06 |
| tor8 | separate enumerators helps the xps case, where only a subset of the annotation types exist | 13:00.23 |
| | not a deal breaker or anything, but it seems cleaner to me | 13:00.38 |
| paulgardiner | So a third enumeration for hyperlinks? | 13:01.06 |
| tor8 | yeah. at least for starters. unless robin vehemently opposes the idea. | 13:01.28 |
| paulgardiner | :-) | 13:01.36 |
| | Ok. Let's go with that for now. Nothing's cast in stone | 13:02.20 |
| Robin_Watts | back. | 13:25.55 |
| | I *like* object orientation, on the whole, but I'm happy to defer to tor8 here. | 13:26.26 |
| paulgardiner | Robin_Watts: my bmpcmp results were slightly odd. One clearly showed the results of the changes I'd made, but others showed numbers replaced by NaN as | 13:29.44 |
| Robin_Watts | I'm just looking now :) | 13:29.58 |
| | What number ? | 13:30.02 |
| paulgardiner | e.g. 43 | 13:30.58 |
| | 56 | 13:31.41 |
| Robin_Watts | and if you run that file manually and enter the same stuff you get different results ? | 13:31.52 |
| paulgardiner | NaN's are correct, but I was expecting the original bmp to show it too. | 13:32.54 |
| Robin_Watts | oh, right. | 13:33.23 |
| paulgardiner | The change that introduced NaNs everywhere was the one you committed the other day | 13:33.53 |
| Robin_Watts | if you back up one change and rebuild, and retest do you see NaNs there? | 13:34.04 |
| paulgardiner | I'll do that test. It's hard to imagine I wont. The change is just to do with appearance stream generation. It doesn't affect calculation | 13:36.30 |
| Robin_Watts | Try backing up 1 step, then "git cluster bmpcmp" that | 13:37.15 |
| paulgardiner | Oh right yeah | 13:37.41 |
| Robin_Watts | If all is well, you shouldn't see any differences. | 13:37.44 |
| | If you do see differences, then we have a problem. | 13:37.54 |
| paulgardiner | I don't need to alter paul/forms on casper, right> Just locally? | 13:40.46 |
| Robin_Watts | yeah. | 13:41.01 |
| | git cluster works purely with what is in your working directory. | 13:41.22 |
| paulgardiner | Robin_Watts: also having trouble reproducing the segvs on windows. I've tried debug and momento builds. | 13:52.12 |
| Robin_Watts | paulgardiner: All the cluster machines are 64bit linux. | 13:52.41 |
| | so it's possible it's a linux only (or a 64bit vs 32bit) thing. | 13:53.09 |
| | Let me try to reproduce it on peeves. | 13:53.22 |
| paulgardiner | I have 32bit linux I can try | 13:53.28 |
| Robin_Watts | pdf/pdf_jsimp_v8.cpp: In function âchar* pdf_jsimp_execute_cpp(pdf_jsimp*, char*)â: | 13:56.32 |
| | pdf/pdf_jsimp_v8.cpp:397: warning: deprecated conversion from string constant to âchar*â | 13:56.34 |
| | pdf/pdf_jsimp_v8.cpp: In function âchar* pdf_jsimp_execute_count_cpp(pdf_jsimp*, char*, int)â: | 13:56.36 |
| | pdf/pdf_jsimp_v8.cpp:409: warning: deprecated conversion from string constant to âchar*â | 13:56.38 |
| | The first segv is probably my fault, so ignore that one. | 13:58.20 |
| | I can reproduce the second one on 64bit linux though. | 14:00.39 |
| | <unknown>:0: Uncaught ReferenceError: AFSpecial_Format is not defined | 14:01.21 |
| | <unknown>:836: Uncaught TypeError: Cannot read property 'length' of null | 14:01.30 |
| | Two of the first, lots of the second, big pause... then SEGV. | 14:01.50 |
| | #0 ___printf_fp (fp=0x7fffffffd500, info=0x7fffffffd400, | 14:02.20 |
| | args=<value optimized out>) at printf_fp.c:1248 | 14:02.22 |
| | #1 0x00007ffff70ee745 in _IO_vfprintf_internal (s=0x7fffffffd500, | 14:02.23 |
| | format=<value optimized out>, ap=0x7fffffffd640) at vfprintf.c:1613 | 14:02.25 |
| | #2 0x00007ffff7111849 in __IO_vsprintf ( | 14:02.27 |
| | string=0x7ffeb7bf2233 <Address 0x7ffeb7bf2233 out of bounds>, | 14:02.28 |
| | format=0xd4e698 "%f %f Td\n", args=0x7fffffffd640) at iovsprintf.c:43 | 14:02.30 |
| | #3 0x000000000041ffb3 in fz_buffer_printf (ctx=0x12eef00, buffer=0x150ac60, | 14:02.31 |
| | fmt=0xd4e698 "%f %f Td\n") at fitz/stm_buffer.c:186 | 14:02.33 |
| | #4 0x0000000000435c3e in fzbuf_print_text_word (ctx=0x12eef00, | 14:02.35 |
| | fzbuf=0x150ac60, x=0, y=0, text=0x177ed30 "85 Lor", count=0) | 14:02.36 |
| | at pdf/pdf_form.c:715 | 14:02.37 |
| | #5 0x00000000004360a2 in create_text_appearance (doc=0x1304470, | 14:02.39 |
| | bbox=0x13c52d8, oldtm=0x0, info=0x7fffffffd930, text=0x177ed30 "85 Lor") | 14:02.41 |
| | at pdf/pdf_form.c:798 | 14:02.42 |
| | #6 0x0000000000437937 in update_text_appearance (doc=0x1304470, | 14:02.44 |
| | obj=0x13602f0, eventValue=0x0) at pdf/pdf_form.c:1187 | 14:02.46 |
| | #7 0x0000000000438d7d in pdf_update_appearance (doc=0x1304470, obj=0x13602f0) | 14:02.47 |
| | at pdf/pdf_form.c:1486 | 14:02.49 |
| | #8 0x0000000000465b4e in pdf_load_annots (xref=0x1304470, annots=0x13564a0, | 14:02.50 |
| | page_ctm=...) at pdf/pdf_annot.c:370 | 14:02.52 |
| | #9 0x00000000008a46b0 in pdf_load_page (xref=0x1304470, number=0) | 14:02.53 |
| | at pdf/pdf_page.c:351 | 14:02.55 |
| | buffer->len is -819367389 | 14:03.44 |
| | cap = 918432564. I think you must be putting an infinite amount into that buffer, and it grows and grows... and on a 64bit machine, it's overflowing an int ? | 14:06.43 |
| | yeah, exactly the same for the second SEGV. | 14:16.57 |
| | bbox has a width of 2.94 in that case :) | 14:17.35 |
| paulgardiner | Great! Nice bit of mental debugging. | 14:18.19 |
| | I'll sort out a fix. Would you push that last commit? | 14:19.55 |
| Robin_Watts | sure. | 14:20.30 |
| paulgardiner | ta | 14:20.35 |
| Robin_Watts | Done. | 14:21.47 |
| paulgardiner | thanks | 14:21.54 |
| Robin_Watts | The stored mujstest-v9 binary on peeves is looking to be brand new. | 14:24.55 |
| | -v8 even | 14:25.06 |
| | so I hope it is correctly storing them. | 14:25.16 |
| tor8 | kens: ping. | 14:39.46 |
| kens | tor8 pong, sorry for slwo reply | 14:45.21 |
| tor8 | kens: you worked on the text rendering modes for pdf write so I thought I'd pick your brain | 14:46.44 |
| kens | Got to find it first :-) | 14:46.53 |
| tor8 | more specifically fill+stroked rendering. I thought I'd take a stab at fixing style simulations in ghostxps | 14:47.15 |
| kens | Hmm, OK hwo can I help ? | 14:47.36 |
| tor8 | gs_settextrenderingmode doesn't seem to have any effect... | 14:48.39 |
| kens | Isn't that only a pass through for pdfwrite ? | 14:48.53 |
| tor8 | that's my question :) | 14:49.02 |
| kens | I htought the PDF interpreter takes two different paths | 14:49.14 |
| | One way preserves the text rednering mode by settign .textrendermode and just drawing the text | 14:49.34 |
| tor8 | if there's something I need to do specifically to get the text processing to do fill+stroke and not mess up pdfwrite output | 14:49.42 |
| kens | The other way draws the text as many times as are required in differet styles | 14:49.48 |
| | Wow, this was a long time ago.... | 14:50.03 |
| tor8 | oh, so the interpreter has to know if it's connected to pdfwrite and do different things? | 14:50.17 |
| | if (pdfwrite) set text rendering mode and draw once; else draw fill then draw stroke; | 14:50.41 |
| kens | There's a device thingy that says if the device wants text rendering modes (I *think*) | 14:50.41 |
| | Let me try and find it, one minute | 14:50.51 |
| | PreserveTrMode is what does the switch in the PDF itnerpreter | 14:51.29 |
| | in pdf_ops.ps | 14:51.34 |
| chrisl | tor8: I thought you were leaving at the least the bold until I'd got freetype in there? | 14:52.12 |
| kens | Yes if you look at setshowstate in pdf_ops.ps you can see it doing different stuff | 14:52.18 |
| tor8 | chrisl: figured I could make a quick hack as a distraction by just doing fill+stroke | 14:52.34 |
| kens | currentdevice 1 dict dup /PreserveTrMode dup put .getdeviceparams | 14:52.48 |
| | dup type /booleantype eq not {cleartomark //false}{3 1 roll cleartomark}ifelse | 14:52.48 |
| | { | 14:52.48 |
| | pdfwrite_textrenderingprocs TextRenderingMode get | 14:52.48 |
| | } | 14:52.48 |
| | { | 14:52.49 |
| | TextRenderingMode 0 eq | 14:52.49 |
| | etc | 14:53.02 |
| tor8 | chrisl: looking at the spec the style simulations are attached to the text drawing operation and not the font object | 14:53.03 |
| chrisl | tor8: we probably need that to do that for pdfwrite/ps2write anyway, now I think about it..... | 14:53.32 |
| kens | tor8 you need to call the C equivalent of .settextrenderingmode | 14:53.59 |
| kens | goes to look for that | 14:54.19 |
| chrisl | kens: that won't work for rendering, though | 14:54.30 |
| kens | chrisl, no it won't | 14:54.48 |
| | But I thought tor8 was asking for pdfwrite | 14:55.01 |
| tor8 | kens: I'm asking for both :) | 14:55.16 |
| kens | OK wel lwhat you said above is braodly correct | 14:55.26 |
| tor8 | but primarily for pdfwrite since I knew there are some workarounds | 14:55.30 |
| | kens: I have the .settextrenderingmode call in C (it just sets a flag in the pgs) | 14:55.48 |
| kens | If the device has a property of 'PreserveTrMode' then we set text rendering mode and daw the text. Otherwise we twiddle with it to draw stroke, stroke+fill, etc. | 14:55.59 |
| | tor8 yes, that will be OK for pdfwrite, won't do anything for rendering | 14:56.46 |
| | tor8 should be an int not a flag | 14:57.07 |
| | 0->7 (or whoever many modes thare are, I forget) | 14:57.22 |
| tor8 | kens: sadly I think it won't work at all at the moment since I'm doing the rendering as a charpath. any tricks to get the text enumerator to do stroking automatically? | 14:57.22 |
| kens | tor8 thre's a heuristic in the pdfwrite code to spot a charpath | 14:57.42 |
| | and try to turn the PS: (text) charpath gsave fill grestore stroke into a tr mode | 14:58.29 |
| tor8 | kens: well, the good news is -- setting the render mode in C and doing a plain text show produces the expected pdf output :) | 14:58.51 |
| kens | That's a decent start | 14:59.04 |
| chrisl | wonders why we're still giving out patches for 8.71....... | 14:59.12 |
| kens | For all render modes ? | 14:59.14 |
| tor8 | now to get the rendering to match... | 14:59.16 |
| | kens: for the stroked render mode at least | 14:59.24 |
| kens | rendering is harder :-( | 14:59.24 |
| | What modes does XPS support ? | 14:59.36 |
| chrisl | If you've already got a path for the glyph, if should trivial to add a stroke as well as a fill | 15:00.10 |
| tor8 | kens: none, I'm abusing fill+stroke to do artificial bold | 15:01.55 |
| kens | tor8 aha ! | 15:02.06 |
| | Well as chrisl says that one should be easy. | 15:02.23 |
| chrisl | tor8: don't forget to set strokewidth to a sensible value (and back again) | 15:03.37 |
| kens | Have to go print some stuff, back in a minute | 15:05.04 |
| tor8 | chrisl: already done. 2% of the font size according to the xps spec (widen the strokes by 1% of the em size) | 15:05.39 |
| chrisl | tor8: good - I just remember it hadn't been done in FAPI, and it caused me some confusion....... | 15:06.25 |
| tor8 | chrisl: and now I'm wishing for a gs_fill_and_stroke function... | 15:06.50 |
| Robin_Watts | tor8: Such a thing is problematic. | 15:07.07 |
| | because of transparency. | 15:07.11 |
| chrisl | tor8: so, we don't use the glyph cache at all for XPS? | 15:07.23 |
| Robin_Watts | to implement it properly we'd have to push a knockout group, render both, then pop the knockout group. | 15:07.40 |
| tor8 | chrisl: only for plain filled text | 15:07.43 |
| chrisl | tor8: right, I see | 15:07.52 |
| Robin_Watts | mvrhel wrote that bit in PS thankfully. | 15:07.54 |
| tor8 | chrisl: for the artificial bold I'm doing char paths (if you have another approach I'm all ears), as well as when using text as a clip mask | 15:08.10 |
| chrisl | tor8: the PCL interp does boldening on the bitmap - I'm not convinced it's very good, but it's likely rarely used there | 15:09.16 |
| tor8 | chrisl: the XPS spec reads as if they expect fill+stroke and didn't consider the case of transparency | 15:09.59 |
| | kens: sadly, the charpath heuristic doesn't bite. if I charpath, gsave, fill, grestore, stroke it dumps the text as plain paths | 15:11.01 |
| chrisl | tor8: do you need the gsave/grestore? Can't you just hold onto the path and send it for marking operations? | 15:12.44 |
| tor8 | chrisl: not with the way I create the paths in xps ... gs_moveto/lineto | 15:14.22 |
| | I'm admittedly a n00b at gs programming :) | 15:14.48 |
| chrisl | You might be able to grab the current path from the graphics state - gsave/grestore is expensive enough to avoid, if possible..... | 15:15.43 |
| tor8 | I just followed what pdf_ops.ps did for fill+stroke | 15:15.47 |
| chrisl | Yeh, the current path is opaque inside the graphics state for PS, but it should be available at the C level | 15:16.50 |
| | I guess it's not that important - performance probably isn't high on your list in this case! | 15:17.40 |
| Robin_Watts | tor8: A patch on robin/master for you when you get a chance - no hurry. | 15:18.23 |
| kens | tor8 its designed to work with pretty much exactly the PostScript stream I gave you, so it may well not trigger from other events. | 15:18.57 |
| tor8 | kens: right. so, any way to quickly detect from C if the device wants Tr (ie is pdfwrite)? | 15:19.29 |
| | the PreserveTrMode setting | 15:19.37 |
| kens | tor8 yes, this is why ray argued for doing it with device properties, its available in PS and C. | 15:19.58 |
| | I just can't remember how to do it in C | 15:20.07 |
| | OK its a device param.... | 15:22.14 |
| | tor8 here's an example, its from zfunc4.c, check_psc_function: | 15:23.29 |
| | gs_c_param_list_write(&list, i_ctx_p->pgs->device->memory); | 15:23.29 |
| | code = gs_getdeviceparams(i_ctx_p->pgs->device, (gs_param_list *)&list); | 15:23.29 |
| | if (code < 0) | 15:23.29 |
| | return code; | 15:23.29 |
| | gs_c_param_list_read(&list); | 15:23.29 |
| | code = param_read_bool((gs_param_list *)&list, | 15:23.29 |
| | "AllowPSRepeatFunctions", | 15:23.30 |
| | &AllowRepeat); | 15:23.30 |
| | if (code < 0) | 15:23.31 |
| | return code; | 15:23.31 |
| | gs_c_param_list_release(&list); | 15:23.32 |
| Robin_Watts | I bet the release should be before the if (code < 0) return code really. | 15:24.05 |
| kens | Robin_Watts : you may well be correct | 15:24.15 |
| | and possibly before the first 'if (code < 0)' tioo | 15:24.40 |
| | But I'm not totally familiar with this structure, and it is locally allocated on the heap | 15:25.03 |
| Robin_Watts | but it probably contains pointers to stuff that's not. | 15:25.24 |
| kens | It may work out OK in PostScript (and this is the PS interpreter) | 15:25.28 |
| | because of garbnage collection and stuff | 15:25.42 |
| Robin_Watts | but, the gs style seems not to be to care too much in the case of an error. | 15:25.50 |
| kens | It seems to be unusual to encoutner this outside of a device. | 15:26.34 |
| | The C list seem s to use it though | 15:26.50 |
| | If you want to open a bug report against that I'll fix it when I get back. I haven't got time to run the tests this afternoon | 15:28.45 |
| | tor8 is that enough for you ? | 15:29.05 |
| tor8 | kens: thanks, I got it working now! | 15:29.13 |
| kens | cool | 15:29.58 |
| Robin_Watts | kens: Have a nice holiday. Where are you going ? | 15:30.15 |
| kens | New York, apparently its going to be hot :-( | 15:30.41 |
| Robin_Watts | urm... yes. | 15:31.01 |
| kens | talking about 37 degrees on Saturday | 15:31.14 |
| | I may just go nocturnal | 15:31.22 |
| Robin_Watts | NY is massively hot in the summer months. Everyone there with money heads out to the coast. | 15:31.25 |
| kens | Well its a scheduling thing. | 15:31.51 |
| Robin_Watts | Have you been before? | 15:32.38 |
| kens | Been promising Melanie for years we'd take her when holidays co-incided with trips. Hasn't happened. She's finished GCSE's so we wanted to go away before school holidays start, and obviously before term starts at 6th form | 15:32.39 |
| | Robin_Watts : yes, twice, once with Artifex | 15:32.51 |
| Robin_Watts | Well, if you want recommendations for touristy things to do, just say. | 15:33.39 |
| kens | Melanie seems mostly interested in shopping :-( | 15:33.50 |
| Robin_Watts | Like Helen then. She was largely thwarted by the fact that she went away with 3 blokes :) | 15:34.16 |
| kens | We'll probably do the Empire State, Rockefeller centre, liberty island | 15:34.26 |
| | Maybe Ellis Island (I've never been there) and possibly USS Intrepid, though I hear the space shuhttle isn't on view yet, and I've been there before | 15:34.58 |
| Robin_Watts | all worthwhile (but get to liberty island early - prebook tickets). Ellis island was better than liberty island in my view (can get them on the same tour). | 15:35.29 |
| | For Rockerfeller centre, prebook tickets too to avoid queueing. | 15:35.49 |
| kens | Robin_Watts : the one time I went to liberty island I saw the queses... | 15:35.49 |
| | Yep, did that last time, can do it online in the US | 15:35.59 |
| Robin_Watts | Standing on the brooklyn bridge at sundown was my highlight. | 15:36.15 |
| | I suspect for liberty island you may be smartest to book now (i.e. well ahead of time). | 15:36.45 |
| kens | Well, I'm not too sure if we'll do more than walk round the island | 15:37.01 |
| | I'm not relaly hugely interested in climbing the statue | 15:37.15 |
| Robin_Watts | I didn't get to go inside, but paulgardiner did. I regret that. | 15:37.26 |
| | Ellis Island has shades of Alcatraz about it. | 15:37.52 |
| kens | Last time I looked you had to book weeks in advance, and you still get to join a queue when you arrive | 15:37.57 |
| Robin_Watts | kens: Absolutely, yes :( | 15:38.09 |
| | Grand Central was nice (just like the movies) | 15:38.20 |
| kens | Yes, that's true, I'd forgotten about that | 15:38.37 |
| paulgardiner | I'd go to New York again just for the breakfasts | 15:39.05 |
| Robin_Watts | We did a boat cruise too, from intrepid, around the battery and up to the UN and back, as the sun went down. Enjoyed that. | 15:39.43 |
| kens | Hmm, at the moment there are still tickets for thursday and friday | 15:39.51 |
| | Robin_Watts : statue of liberty crown and pedestal/museum is closed until October 21012 for renovation | 15:41.53 |
| Robin_Watts | kens: Right, so you can't go inside. Saves some queuing :) | 15:42.20 |
| kens | Saves any debate :-) | 15:42.30 |
| | harbour trips are readily available, so we will just get one when we arrive | 15:42.50 |
| Robin_Watts | If I'd had more time I would have liked to ride the Statten Island Ferry too. | 15:44.48 |
| kens | Hmm, isn't there an amusement park too ? | 15:45.03 |
| | battery island ? Or am I thinking of something else | 15:45.13 |
| Robin_Watts | no, you're right, I think. | 15:45.31 |
| | Coney Island | 15:45.46 |
| kens | THat's the one | 15:46.19 |
| | Used to have brothels on it as I recall | 15:46.29 |
| Robin_Watts | Opposite side of the water to staten Island | 15:46.53 |
| | I bow to your superior knowledge in this area. | 15:47.05 |
| kens | I seem to remember seeing a documentary abou tit | 15:47.17 |
| | Again, its hazy so I could be wrong | 15:47.26 |
| chrisl | There was a hotel/brothel in a giant elephant - I think that was Coney Island..... | 15:47.59 |
| Robin_Watts | As I remember, the Verranazo bridge is a very large suspension bridge. You can see it from the south of manhattan looking past the SoL. | 15:48.04 |
| | That joins Staten Island to Brooklyn (where coney island is) | 15:48.20 |
| | chrisl: You're right: http://en.wikipedia.org/wiki/Elephantine_Colossus | 16:09.16 |
| chrisl | Robin_Watts: ah! Amazing the things I remember from QI..... :-) | 16:09.40 |
| kens | :-) | 16:09.47 |
| | OK I'm off now, see you all next week. | 16:28.42 |
| chrisl | Have fun! | 16:28.49 |
| Robin_Watts | tor8: Are you interested in files that trigger the "font size too large" thing? | 16:45.07 |
| tor8 | Robin_Watts: yeah, I was planning on tackling that one soon | 16:45.22 |
| Robin_Watts | Is there a bug to track that ? | 16:45.34 |
| | 693114 | 16:46.46 |
| | Oh, no colonials today, of course. | 17:16.12 |
| | Do we have anyone in the company that speaks openjpeg well enough to bug hunt in it? | 17:17.47 |
| | normal_590.pdf SEGVs under both mupdf and gs in openjpeg. | 17:18.08 |
| | normal_625.pdf has a j2k in it that fails to decode under openjpeg. | 17:23.31 |
| | Do we ever see jbig2 images wider than 65535 ? | 18:04.10 |
| henrys | kens:don't forget times square. Too bad you couldn't go in June for the Belmont, my daughter is also a "horse" person and it was one of her favorite trips we ever took. | 18:30.24 |
| | for the logs next week. | 18:30.46 |
| | Robin_Watts:feel free to make it bountiable for shelley. | 18:33.50 |
| Robin_Watts | The jbig2 one is solved; it's fixed in the latest jbig2dec already. | 18:34.14 |
| | Does shelly mess with openjpeg too ? | 18:34.21 |
| henrys | no but I think there are similarly independent of gs and mupdf to be good things for outside folks to work on. | 18:35.08 |
| Robin_Watts | right. except the files I have that crash them are 'private' ones, I think. | 18:35.31 |
| henrys | I think he's good with private attachments isn't he? | 18:35.55 |
| | I'm pretty sure he is. | 18:36.06 |
| Robin_Watts | yes, shelly is. | 18:36.08 |
| henrys | anyway whatever you think best, I am heading out for a while, probably won't see you until tomorrow. | 18:44.39 |
| Robin_Watts | have fun | 19:07.58 |
| | tor8: More fun and exciting patches for you. | 19:13.21 |
| sebras | Robin_Watts: ok. I've worked myself through fz_write_buffer_bits() now. finally I'm confident. :) | 20:22.25 |
| | Robin_Watts: in 0b2ee96 you test against 10 and 13, but in pdf/*.c all tests are against \n and \r. also isn't this a case where fz_peek_byte() is useful? | 20:27.38 |
| Robin_Watts | almost certainly. | 20:27.59 |
| | I'll redo that patch, thanks. | 20:28.06 |
| sebras | Robin_Watts: fz_peek_byte() will do the fz_fill_buffer() for you implicitly. | 20:28.28 |
| | tor8: good morning tor! | 20:28.59 |
| tor8 | sebras: good evening sebastian. | 20:29.37 |
| sebras | Robin_Watts: in e83086d CLAMP(pdf_to_real(val), 0.0f, 1.0f)? or you want with certainty to avoid multiple calls to pdf_to_real()? | 20:31.39 |
| Robin_Watts | macros are bad. Actually, did I forget to make that one inline? | 20:32.20 |
| sebras | Robin_Watts: you did. | 20:32.28 |
| | Robin_Watts: well, CLAMP and friends are used in lots of places. wouldn't all of them have the same issue? do we want to have local static innline clamp() min(), max(), abs() implementations in all files where those macros are used? | 20:33.45 |
| Robin_Watts | sebras: We've just had some feedback from a customer (a customer that we hope will be a BIG customer) that macros are bad, and floating point performance is an issue. | 20:34.53 |
| | hence it's doubly important for us to avoid things like CLAMP. | 20:35.15 |
| | but yes, we should address all of them, not just one at a time. | 20:35.30 |
| | We should make a plan and follow through (that's why Brian Boytano'd do.) | 20:35.50 |
| sebras | Robin_Watts: Brian? | 20:36.05 |
| Robin_Watts | sebras: South Park: The Movie. | 20:36.21 |
| sebras | Robin_Watts: alright. I can see why this would be a problem for an ARM without fp-support. | 20:36.32 |
| | Robin_Watts tor8: silly-fix on sebras/master | 20:39.28 |
| tor8 | Robin_Watts: pdfwrite? do you mean pdfclean or pdf_write_document? | 20:43.31 |
| Robin_Watts | pdf_write.c | 20:43.57 |
| tor8 | right | 20:44.15 |
| sebras | ugh. moving debug-functions to a separate files would indeed expose e.g. PS function details in fitz-internal.h | 20:44.44 |
| tor8 | sebras: I don't see a lot of value in putting them in separate files | 20:45.14 |
| sebras | _and_ debug() seems to be fairly well integral in fz_store_type used by fitz/res_store.c. :-/ | 20:45.16 |
| tor8 | rather guard them with #ifdef DEBUG then | 20:45.21 |
| sebras | tor8: yey, ifdef. | 20:45.30 |
| tor8 | Robin_Watts: not really happy about clamp01(). the other patches on your master LGTM | 20:46.22 |
| Robin_Watts | tor8: OK, so what would you prefer to clamp01 ? | 20:46.42 |
| | explicit code? | 20:46.52 |
| tor8 | fz_clampf(x, 0, 1) | 20:46.53 |
| | fz_clamp() actually | 20:47.01 |
| Robin_Watts | Where that's a new function we right ? | 20:47.08 |
| | write | 20:47.13 |
| tor8 | make that, abs, min, max as static inline for floats in the header | 20:47.15 |
| | maybe integer versions if we need | 20:47.26 |
| | should reduce the number of macros | 20:47.32 |
| Robin_Watts | ok. | 20:47.35 |
| tor8 | sound okay to you? | 20:47.43 |
| Robin_Watts | sounds reasonable, sure. | 20:47.55 |
| sebras | tor8: CLAMP is used for ints everywhere (as your probably know). | 20:47.57 |
| tor8 | sebras: then fz_clampi(x, min, max) for ints | 20:48.18 |
| | I can't remember which macro is used on what type | 20:48.28 |
| | well, we can keep CLAMP in the apps. in draw/*.c we use it mostly with fixed point or ints | 20:49.14 |
| sebras | tor8: how about moving the macro-versions to pdfapp.h then? | 20:49.45 |
| tor8 | sebras: pdf/*.c uses mostly floats, so it's a varied lot | 20:49.47 |
| | or just make int and float versions and ditch the macro | 20:50.05 |
| sebras | tor8: as long as the functions are in fitz.h then no problem. if we stick them in fitz-internal.h then the apps would have issues. | 20:50.36 |
| | tor8: oh. I have entirely missed 6294585 | 20:56.51 |
| | and yes, that is a sha1. | 20:57.01 |
| | tor8: sebras/master? | 20:59.37 |
| | Robin_Watts: and yes, given 6294585 I can see why adding a hexdump for fz_buffer makes no sense whatsoever. | 21:00.19 |
| | tor8: well, 8e3d711 seems consistent enough, but I'm still puzzled as how to ft_italic/ft_bold will come to be set after this patch. but that might be the whole point of it... | 21:24.50 |
| tor8 | sebras: they won't... | 21:25.35 |
| sebras | tor8: ok, and then that's the point? | 21:25.59 |
| tor8 | but getting the right glyph in the wrong style and a consistent behaviour is better than inconsistent workarounds for specific fonts and files | 21:26.19 |
| | the input is broken; it relies on system fonts that don't exist and with weird custom encodings (like Symbol) | 21:26.57 |
| sebras | right, now I remember a vs. alpha | 21:27.42 |
| | tor8: d7ba71b seems ok. not sure what xpsref says though. | 21:29.26 |
| tor8 | 20 degree shear on italic, embolden fonts by fattening the strokes by 1% of em size, and increase advance width by 2% | 21:30.08 |
| | and shift the origin by 1% of em size (which FT_Embolden_Stroke does implicitly) | 21:30.29 |
| sebras | tor8: silly-patch is back. | 21:31.32 |
| tor8 | sebras: trailing whitespace? | 21:32.13 |
| sebras | tor8: y. | 21:32.19 |
| tor8 | okay | 21:32.35 |
| sebras | hadn't it been in the public interfaces I probably would care less. ;) | 21:32.46 |
| tor8 | sebras: I plan on running a whitespace cleanup pass and git stripspace when we merge the forms branch. nudge nudge. ;) | 21:33.20 |
| sebras | tor8: about the debugging stuff. note that I do ifndef out the store printing as well. | 21:33.21 |
| tor8 | sebras: is that a problem? | 21:44.57 |
| sebras | tor8: not in my opinion, just not sure if that is desired. | 21:52.24 |
| | tor8: for the logs -- I updated my debug-function patch as I missed pdf_print_*()... also I rearranged the headers a bit so that all fz_print_*() and pdf_print_*() appear last in each section. Moreover I createa minor patch that converts all usage of pdf_print_obj (which is from no own only avaiable in debug-builds) to pdf_fprintf_obj in all our apps. | 22:40.50 |
| | so have a look at sebras/master again, bitte please qing. | 22:41.51 |
| | Forward 1 day (to 2012/07/05)>>> | |
IRC Logs