| | <<<Back 1 day (to 2011/10/27) | 2011/10/28 |
| arthurf | tor8: I read the logs - and just confirmed that I can build something from Xcode 3 to my iPad. Looks like I'm too late though for tonight. I'll login before work tomorrow and see if you're there. My iPad needs charging anyway. :) | 02:11.45 |
| | Can build from Xcode 4 to my iPad (running 4.3.3) as well. | 03:04.01 |
| ray_laptop | finally pushed the (initial) implementation of the serialnumber -- at least the gp_ hooks are there and it _might_ get something unique on Windows (from the registry) | 05:15.50 |
| | I wish there was something on linux, but I don't think there is. The OS doesn't have a license key (obviously) and the 'cpuid' cpu s/n is apparently not implemented in modern chips. OS/X _might_ be doable. | 05:17.32 |
| | since the hooks are there, we can leave the DRM up to our customers (they may already have something anyway). | 05:18.26 |
| | closed bug 692615 (serialnumber) | 05:35.31 |
| Robin_Watts | guarantees us a mild winter by buying a snow shovel. | 09:49.25 |
| kens | I'm still waiting for my snow shovel, for the same reasons. | 10:07.05 |
| | Where did you get yours ? Nobody locally has them in stock at the moment | 10:07.38 |
| Robin_Watts | svp.co.uk | 10:11.15 |
| kens | Thanks | 10:11.24 |
| Robin_Watts | but viking direct does them too. | 10:11.25 |
| | Carriage is steep at svp. | 10:11.40 |
| kens | Well, maybe I'll wit untilt he local garden centre stocks them | 10:12.09 |
| | Err wait until | 10:12.57 |
| Robin_Watts | It's amazing the thoughts that occur to you when starved of oxygen (i.e. running). I've just realised that the binary representation of x*x = the binary representation of x with 0's interleaved. | 11:34.52 |
| | I'm sure that will be useful at some point :) | 11:34.59 |
| | actually, it's complete bollocks. Told you I was starved of oxygen. | 11:36.00 |
| | Woo Hoo! | 13:02.29 |
| | I twigged another bit I'd forgotten to ARM code. | 13:02.38 |
| | Now down to .22 of a second from .43 :) | 13:02.48 |
| kens | big improvement | 13:02.57 |
| Robin_Watts | tor8: ping? | 13:49.36 |
| tor8 | Robin_Watts: pong. | 13:49.44 |
| Robin_Watts | I've just pushed a commit to my repo with the ARM changes in. | 13:49.54 |
| | If it doubles rendering speed on the iphone too, that'll be nice :) | 13:50.07 |
| tor8 | it crashes on my test file in release build :( | 13:50.37 |
| | not your code, just a regular build | 13:50.54 |
| | I've been messing with icons and a "How To Sync Files with iTunes" document today | 13:51.38 |
| | if you've got a better name for that document, I'm all ears | 13:51.49 |
| henrys | just can't get these guys to update their code ;-( | 13:52.57 |
| Robin_Watts | tor8: Bugger. Can you get any debug out of a release build? | 13:53.10 |
| | (i.e. can you print to a backchannel that's visible in Xcode or something?) | 13:53.29 |
| tor8 | Robin_Watts: it took me a while to figure out how to even run release builds with Xcode 4 | 13:53.49 |
| Robin_Watts | At least that way you can resort to printfs or something to figure out what bit of the code its crashing in. | 13:54.01 |
| tor8 | Robin_Watts: the crash is inside pdf_lex() which makes no sense at all :( | 14:02.02 |
| Robin_Watts | :( | 14:02.52 |
| tor8 | time to tweak the flags so I combine -O and -g for release builds of the lib | 14:03.09 |
| | and hope the bug doesn't disappear | 14:03.13 |
| arthurf | tor8: Would you like me to try out the code tonight? I could help understand what the issue in Xcode 4 (presumably) is with pdf_lex(). | 14:08.52 |
| tor8 | arthurf: yeah, it should be in testable shape now. the code is in my user/tor/mupdf.git repo on the "ios" branch | 14:09.33 |
| arthurf | tor8: Okay - is there a specific PDF that causes this problem? Or will pretty much any do? | 14:10.12 |
| tor8 | arthurf, Robin_Watts: I have a hunch, I just saw this good old warning again... | 14:10.33 |
| | warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame. | 14:10.34 |
| arthurf | Maybe this might help -> http://stackoverflow.com/questions/3637714/warning-attempting-to-create-use-block-in-frame-variable-with-block-that-isnt | 14:11.52 |
| henrys | I do try to pick my battles carefully, but doing the artifex newsletter in PDF and not HTML seems a fight worth having. | 14:12.34 |
| tor8 | I've seen it before, it was related to reference counting and dispatch (multi-threading) code Blocks | 14:12.49 |
| arthurf | Looks ugly enough that I can't contribute over the next 5 minutes unfortunately. Requires a good chewing. | 14:16.09 |
| kens | henrys, seems reasonable | 14:16.42 |
| Robin_Watts | Playing devils advocate here... if you send people a newsletter in HTML it (presumably) opens in their mail readers automatically. | 14:17.35 |
| | If you send it as a PDF attachment, it's another step to open it - presumably many won't bother ? | 14:18.00 |
| kens | But they have GhostscriptMuPDF :-) | 14:18.30 |
| arthurf | Fortunately I have a relatively downlevel version of Xcode 4 (4.0.1) - if it is a tools problem - I might not see it which would be a good clue. I'll check it out tonight. Bye. | 14:22.23 |
| Robin_Watts | crumbs. Would you believe that bmpcmp swaps blue and red in its diffs ? | 14:22.23 |
| kens | I noticed that when I was doing the Tr stuff, I meant to mention it | 14:22.40 |
| henrys | Robin_Watts:it is near impossible to create a complex newsletter that is device independent with HTML and when things break - font substitution etc. everything looks like crap. | 14:27.10 |
| Robin_Watts | henrys: Now, that's true. | 14:27.55 |
| | If it's formatted and device independent, then PDF is the way to go. | 14:28.25 |
| henrys | part of is scott is signed up with a service and the html is particularly bad. | 14:28.29 |
| Robin_Watts | kens: But not all the time. Look at number 3 here: http://ghostscript.com/~regression/henrys/ | 14:28.50 |
| | The colors are correct. | 14:28.53 |
| kens | I don't recall exactly under what conditions it happens. Its not all, not even most | 14:29.29 |
| | At least for my tests. I think its just one fo the devices. | 14:29.49 |
| | pbmraw maybe ? | 14:30.00 |
| Robin_Watts | pbmraw = black and white. | 14:30.12 |
| kens | OK, so not that one ;-) | 14:30.19 |
| Robin_Watts | mvrhel2 pointed it out with ppmraw on xps. | 14:30.29 |
| | and indeed that's true. | 14:30.35 |
| kens | I was seeing it on PDF/PS | 14:30.55 |
| Robin_Watts | and I can make it locally go wrong with ppmraw on gs (from a pdf file) | 14:30.56 |
| | BUT... the example I point to is ppmraw too. | 14:31.10 |
| kens | Indeed.... | 14:31.18 |
| | Maybe its the source clour space that matters | 14:31.32 |
| Robin_Watts | henrys: How long ago did you last do a bmpcmp run? | 14:31.50 |
| | kens: The ppm output is fine. | 14:32.01 |
| henrys | a fairly long time ago I've been doing locals | 14:32.15 |
| Robin_Watts | So maybe it's something I've broken recently in bmpcmp. | 14:32.32 |
| kens | Miranda doesn't seem to like Robin_Watts's name.... Crashes when I tab compelte it | 14:33.28 |
| | I was sayign maybe its the souce colour space in the PDF | 14:33.42 |
| Robin_Watts | kens: Right, but the ppm output (as converted to png by imagemagick) is fine. | 14:34.15 |
| | So gs etc are producing the right thing. | 14:34.31 |
| kens | In that case, I hav no idea.... | 14:34.44 |
| Robin_Watts | And at the point at which bmpcmp gets to the data, it can't know about the source color space. | 14:34.47 |
| | It's bonkers :( | 14:34.50 |
| | OK, henrys last run dates from July 5th. | 14:35.23 |
| | Oh, I see it. | 14:37.05 |
| kens | Aha, single = in a test, that took a long time to spot.... | 14:41.14 |
| henrys | the switch from debugobj/gs to debugbin/gs can really foul you up when doing a bisect! | 15:03.47 |
| chrisl | kens: is your phone free? | 15:12.18 |
| kens | No, Stella is making a call. | 15:13.09 |
| chrisl | OKay-dokey..... | 15:13.19 |
| kens | She said she'd be finished 'soon' :-( | 15:13.22 |
| chrisl | No worries - I just thought it was time to put something on my phone bill for a change ;-) | 15:13.50 |
| kens | :-) | 15:13.57 |
| | On the plus side, I just checked La Carrerra and I see Miles and Marcos completed it. | 15:14.18 |
| chrisl | Oh, I thought it continued over the weekend - well done them! | 15:14.38 |
| kens | Site says 21-27th | 15:14.48 |
| | THey were 83 of 107 | 15:14.56 |
| chrisl | Not bad really, with some of the cars and drivers they up against | 15:15.47 |
| kens | Its the first time since I've been at Artifex that Miles has finished it I think | 15:16.07 |
| | So definitely a positive | 15:16.16 |
| | I think I might have to rewrite my code for finding blocks of text, its making my head hurt... | 15:17.37 |
| Robin_Watts | mvrhel2: Hey. | 15:31.23 |
| mvrhel2 | hi Robin_Watts | 15:31.29 |
| | I see you fixed the BGR issue | 15:31.35 |
| Robin_Watts | The bmpcmp color reversal is fixed. I broke it while speeding it up a while ago. | 15:31.38 |
| | I'm looking into the stroking thing now. | 15:31.50 |
| mvrhel2 | funny that no one noticed.. | 15:31.54 |
| Robin_Watts | Well, I've been using pamcmyk4 and plank - and pam reading was affected. It was only ppm. | 15:32.21 |
| | kens noticed but didn't say anything. | 15:32.33 |
| kens | I noticed the bmp[bmp but forgot to mention it | 15:32.34 |
| mvrhel2 | gotcha | 15:32.37 |
| Robin_Watts | s/affected/unaffected/ | 15:32.49 |
| kens | Phone is free chrisl | 15:32.55 |
| Robin_Watts | With the stroking thing, if you change the size of the page, the white lines move around. | 15:33.10 |
| chrisl | kens: okay, just a sec..... | 15:33.16 |
| mvrhel2 | Robin_Watts: yes | 15:37.44 |
| | also, it turns out that this is part of a pattern in another file | 15:37.57 |
| | at certain resolutions we end up with vertical lines too | 15:38.07 |
| | due to the strokes not going all the way | 15:38.18 |
| | but I assume if you fix one, the solution will fix the other | 15:38.32 |
| | at least that is my hope | 15:38.42 |
| ray_laptop | kens: did you or henry get my most recent improvement (fix) for 692618 to Gemma ? 97e6cda Fix bug 692618. Crash and Object not in any chunk error and VMerror. | 15:40.30 |
| | kens: this _should_ resolve the crashes. A VMerror is still possible if -dBufferSpace=500000000 is used (not what they were using) | 15:41.41 |
| | kens: and as far as I can tell, only the first file attached to the bug has the non-encodable color issue | 15:42.29 |
| henrys | ray_laptop:is the serial number problem something shelly could do for bounty? | 15:42.29 |
| ray_laptop | henrys: sure -- we still need the mac and linux/unix | 15:42.57 |
| kens | ray_laptop : no, they need binaries, and we haven't finished the bug yet | 15:43.10 |
| Robin_Watts | Finding a 'unique' serial number is far from easy. | 15:43.16 |
| | Paul needs to do it for glidos. He ends up taking a hardware fingerprint of the machine. | 15:43.37 |
| | and he only has to worry about windows machines. | 15:43.49 |
| ray_laptop | kens: I think we should get them to build their own. How hard have you pushed ? (and have you given them the link to VS C++ Express ?) | 15:44.06 |
| kens | I haven't pushed at all, its really a support issue. | 15:45.03 |
| ray_laptop | Robin_Watts: I figured that at least we have to hooks. Some people may just decide to store something in a file that they use to derive the serial number. If they hide it in with other data and don't label it then it can be pretty "hidden" | 15:46.22 |
| henrys | ray_laptop:that would seem to make more work for us - if they just want to use binaries they can get their fixes in February. | 15:46.38 |
| ray_laptop | s/have to/have the/ | 15:46.38 |
| | henrys: what 'more work' ? I'm NOT proposing that we ship them binaries | 15:47.15 |
| henrys | ray_laptop: would this also be used as an api to a dongle? | 15:47.28 |
| ray_laptop | henrys: customers could hook their 'gp_serialnumber' function to read from a dongle, yes | 15:48.03 |
| henrys | ray_laptop:the work of having a conversation with them, maybe your due to do support for a while ;-) | 15:48.27 |
| | s/your/you're | 15:48.38 |
| ray_laptop | henrys: well, unless you object, I don't mind sending the suggestion that they build their own binaries and the info on VS Express. (I've done that for many other customers in the past). | 15:49.32 |
| | IMHO, it's worth it to get them comfortable with the build process. And it's much "freindlier" now that there's a VS project and they don't have to type 'nmake' in a cmd prompt window | 15:50.43 |
| henrys | no objection here - but kens was dealing with them. | 15:50.49 |
| kens | I don't mind if Ray wants to take it on. | 15:51.02 |
| ray_laptop | kens: do you mind if I take it up with Gemma ? | 15:51.09 |
| | kens: thanks] | 15:51.20 |
| henrys | do you really want to say hey this crash is fixed but the file doesn't work? | 15:51.32 |
| ray_laptop | henrys: there were 4 files. 3 all work, and I will test the work around for the 'non-encodable colors' (using SeparationOrder param: If only a subset of the colorants for a file is desired then the separations to be output can be selected via the SeparationOrder device parameter. | 15:54.05 |
| | I've considered an enhancement to 'automagically' drop into a mode that re-does the file with less separations, but that will only work with PDF (not PS) -- and unless an important customer objects to the manual method, I wasn't going to tackle that | 15:57.33 |
| henrys | bisecting is still very slow I wonder if we shouldn't have a server full of binaries. | 16:00.18 |
| Robin_Watts | henrys: marcosw has exactly that. | 16:00.33 |
| mvrhel2 | being able to handle more spot colorants without the limitation of the color encoding method is something we should look at at some point | 16:00.37 |
| henrys | Robin_Watts:I would too if this were a regular job for me. | 16:01.12 |
| mvrhel2 | ray_laptop: I thought you were going to be able to fix this by having the pdf14 put image go directly to the tiffsep device | 16:01.24 |
| | for cmyk_spot case | 16:01.29 |
| | and fix the rect fill issue | 16:01.56 |
| ray_laptop | mvrhel2: Yes, for this particular file, we can use the put_image, but that's only used with transparency | 16:02.31 |
| mvrhel2 | right. but it is transparency that is causing the large increase in color combinations in this case I think | 16:03.00 |
| ray_laptop | mvrhel2: improving the performance by implementing the put_image in the sep devices still isn't a general fix for too many colorants -- it only works for this 1 problem file because the colors get generated during the 'blend' opearation. | 16:04.22 |
| mvrhel2 | I agree | 16:04.38 |
| ray_laptop | we are "hanging on by our fingernails" with the compressed_color approach. | 16:05.34 |
| mvrhel2 | yes | 16:05.38 |
| ray_laptop | mvrhel2: and I agree that we should think about how to support more colorants without having to encode/decode into a 64-bit value | 16:07.07 |
| Robin_Watts | ray_laptop: What's wrong with having to encode/decode into a 64bit value ? | 16:08.01 |
| ray_laptop | Robin_Watts: when you have 13 components, each of which is an 8-bit value ? | 16:08.34 |
| | Robin_Watts: not to mention the performance hit on the transparency logic that has to decode it back into the N components in order to paint with it. It KILLS gradient shading performance | 16:09.51 |
| Robin_Watts | I appreciate that a 64bit value is not enough to store all colors uncompressed. | 16:10.08 |
| | But you said "I agree that we should think about how to support more colorants without having to encode/decode into a 64-bit value", which I read as "if we move to encoding/decoding into a 64bit value that will solve the problem, but for a cost". I was enquiring as to what that cost was. | 16:10.54 |
| ray_laptop | shading is interpolating in N-component space and then has to encode the color, pass it into the pdf14 device as a 64-bit compressed color then pdf14 has to uncompress it | 16:11.00 |
| | Robin_Watts: sorry, what I meant was going to a scheme where colors can be larger than 64-bits | 16:11.51 |
| mvrhel2 | yes | 16:11.56 |
| Robin_Watts | AIUI, encode/decode color take a color and pack it into/out of an array of colorant values. That array is limited to being 8 long, right? | 16:12.35 |
| | hence we can only cope with 8 components before 'trickery' is required. | 16:13.10 |
| | If we knew in advance how many colorants there were for a given file, we could make a better partitioning of the space. | 16:13.39 |
| mvrhel2 | right. we probably need to go to a structure of some sort to handle a general situation | 16:13.41 |
| ray_laptop | Robin_Watts: no, the array size is GS_CLIENT_COLOR_MAX_COMPONENTS | 16:14.04 |
| Robin_Watts | ok... so where does the 64bit limit come into it ? | 16:14.59 |
| mvrhel2 | hehe. you guys are having trouble communicating | 16:15.12 |
| ray_laptop | Robin_Watts: that is currently 14, but users can build it larger if needed. | 16:15.15 |
| mvrhel2 | Robin_Watts: you are correct that we can go up to 8 components before we have to do something special (like the compressed color encoding) | 16:16.01 |
| | but compressed color encoding has its limits | 16:16.16 |
| ray_laptop | Robin_Watts: the 'compressed_color_encoding' (see gdevdevn.*) packs the N-components into a 64-bit number, but it can't cope with all combinations | 16:16.20 |
| | Robin_Watts: 8 components is (only) 4 separations and CMYK -- we've seen files with as many as 17 sepaarations | 16:17.05 |
| henrys | Robin_Watts:it looks like your commit 0496530 is reasonably independent, I'm going to send it to a patch to a customer to try out applied to 8.71 unless you know there are dependencies. | 16:18.17 |
| Robin_Watts | henrys: I believe it's safely standalone, yes. | 16:20.03 |
| ray_laptop | (anything more than 10 separations requires re-building) | 16:20.10 |
| Robin_Watts | I'm struggling to see the crossover between 64bit and the larger array. Grepping the source now. | 16:20.41 |
| ray_laptop | mvrhel2: all the device interface layers that take a 'gx_color_index' would have to be supplemented by versions that use the array of values | 16:22.08 |
| mvrhel2 | yes. this could be a messy affair | 16:22.40 |
| ray_laptop | then we'd have to modify the spot color devices to implement those functions. | 16:22.57 |
| mvrhel2 | right | 16:23.06 |
| Robin_Watts | Right. So encode_color packs the array into a 'gx_color_index', and the problem is that that is not expressive enough. Got there at last. | 16:23.10 |
| ray_laptop | mvrhel2: if it is done as an 'increment' on top of the existing devices (that are all more or less OK with the 64-bit color index) then it wouldn't cause as much chaos. | 16:23.58 |
| mvrhel2 | yes | 16:24.14 |
| ray_laptop | the issue is "how important is it". So far, the fingernails are holding (mostly). This is the first file I've seen that fails with the compressed encoding. | 16:25.14 |
| | and if the customer buys off on manually specifying SeparationOrder then we can hang on a bit longer | 16:25.59 |
| mvrhel2 | I would argue that this is the sort of thing that we do not want to have to fix under the gun | 16:26.57 |
| ray_laptop | henrys: maybe a topic for others to consider and put on our next agenda "how urgently, if at all, do we need > 64-bit color info" | 16:27.00 |
| Robin_Watts | reading the comments in gdevdevn.c... do we know in advance of encoding/decoding any colors how many colorants there are ? | 16:28.36 |
| mvrhel2 | ugh. this code is killing me | 16:28.46 |
| | cold | 16:28.48 |
| | ha | 16:28.50 |
| | that was an interesting slip | 16:29.04 |
| ray_laptop | mvrhel2: even your typing has a stuffy nose :-) | 16:29.17 |
| mvrhel2 | :) | 16:29.22 |
| | I am the last in the house to get it... | 16:29.47 |
| ray_laptop | mvrhel2: last cold I came down with, Zicam worked great. Only 1.5 days | 16:30.07 |
| mvrhel2 | oh. did Miles decide where we are having the december meeting | 16:30.13 |
| kens | not yet | 16:30.20 |
| Robin_Watts | I guess we must because the device must be opened by then. | 16:30.21 |
| ray_laptop | mvrhel2: I don't think so. | 16:30.25 |
| mvrhel2 | is that a Zinc supplement? | 16:30.25 |
| | Robin_Watts: we know the number of colorants but not the combinations | 16:30.51 |
| Robin_Watts | recommends "Contact" for colds. Doesn't cure the cold, just holds the symptoms at bay. | 16:30.53 |
| | Right. | 16:30.57 |
| ray_laptop | Robin_Watts: you know 'max_components' and 'num_components' | 16:31.10 |
| Robin_Watts | ray_laptop: What's the difference? | 16:31.23 |
| | The current encoding scheme is clever in that it allows full 8 bit combinations of up to 5 colorants. | 16:33.43 |
| | We could offer an alternative scheme that just represents every colorant in 4 bits. | 16:34.01 |
| ray_laptop | Robin_Watts: 4 bits! Yuck! Most of these customers are doing separation plates for high end presses | 16:39.42 |
| | I doubt they'd settle for 4-bit | 16:39.57 |
| mvrhel2 | yes. we need to support 8 bits for a general number of colorants. | 16:40.14 |
| ray_laptop | and we have had queries about 12-bit color for separations | 16:40.45 |
| | we told them "not yet" :-) | 16:41.05 |
| mvrhel2 | ah. yes. | 16:41.09 |
| Robin_Watts | if gx_color_index is a 64 bit beasty anyway, then it could silently be made into a pointer. | 16:41.22 |
| mvrhel2 | true | 16:41.37 |
| Robin_Watts | What's the largest number of actual color combinations we've ever seen? | 16:41.51 |
| mvrhel2 | pick any number and soon enough someone will come with one that is larger | 16:42.12 |
| henrys | the last direction we took was to use a struct see TEST_CINDEX_STRUCT in gxcindex.h | 16:42.26 |
| Robin_Watts | could keep a hash table of all the combinations we've ever seen, and return a pointer to indexes within that. | 16:42.57 |
| ray_laptop | Robin_Watts: I was wrong earlier. The array of 'cv' to encode is limited to GX_DEVICE_COLOR_MAX_COMPONENTS which is (ARCH_SIZEOF_GX_COLOR_INDEX * 8) = 64 | 16:43.17 |
| | Robin_Watts: I was wrong earlier. The array of 'cv' to encode is limited to GX_DEVICE_COLOR_MAX_COMPONENTS which is (ARCH_SIZEOF_GX_COLOR_INDEX * 8 ) = 64 | 16:43.25 |
| Robin_Watts | So we can have more in a device color than a client color ? | 16:44.26 |
| | I suspect that a hash table is probably the simplest sane way to go. | 16:45.46 |
| | For every color combination we are asked to encode, hash it then linear probe down a linked list of entries from that hash position to see if it exists. If it doesn't, then add a new one. Either way return the pointer to the entry we just added. | 16:47.18 |
| | If the number of entries in the table grows to large, double the size of the table, and reposition everything. The entries themselves (and hence the pointers) stay valid. | 16:48.07 |
| ray_laptop | Robin_Watts: pointers are problematic with the clist -- we'd have to write the list and pickle the pointers into offsets | 16:48.49 |
| Robin_Watts | If you want to improve the speed, we can use splay trees rather than linked lists. | 16:48.58 |
| | ray_laptop: Only if we want to be able to write the table to the clist. | 16:49.48 |
| mvrhel2 | I would think you would want to do that | 16:50.08 |
| Robin_Watts | The pointers never change - so if we can write a pointer to the clist, we are guaranteed it'll still be there when we read it out in a rendering thread. | 16:50.50 |
| | It's a problem for saved page, but that's all. | 16:51.05 |
| ray_laptop | phone call.... | 16:51.30 |
| henrys` | anybody know how an application can have exclusive use of a dll on windows? | 16:51.32 |
| ray_laptop | henrys: not me. | 16:52.25 |
| Robin_Watts | mvrhel2: OK. If I disable stroke adjustment, the problem goes away. | 16:52.55 |
| mvrhel2 | what is stroke adjustement? | 16:53.09 |
| | and how is it disabled | 16:53.14 |
| ray_laptop | Robin_Watts: the clist is desinged so that a clist can be read by a different process than the creator. Pointers are ILLEGAL | 16:53.15 |
| Robin_Watts | Guess what I need to understand next? :) | 16:53.20 |
| henrys` | I did find this http://msdn.microsoft.com/en-us/library/windows/desktop/aa375142(v=vs.85).aspx | 16:54.02 |
| Robin_Watts | ray_laptop: OK, so we don't use pointers, we use offsets into a set of chunks of memory. | 16:54.13 |
| ray_laptop | Robin_Watts: offsets are OK | 16:54.24 |
| Robin_Watts | The only way this runs us into problems is if there are too many combinations of different colors for us to have memory to represent. | 16:54.59 |
| kens | is off now, night all. | 16:56.04 |
| ray_laptop | bye kens | 16:56.13 |
| | Robin_Watts: that and the performance hit | 16:56.26 |
| Robin_Watts | ray_laptop: Right, but any compressed color scheme is going to suffer from a performance hit. | 16:56.50 |
| mvrhel2 | hmm. looks like this last XPS bug is a shading issue | 16:57.02 |
| | in the graphics library | 16:57.07 |
| ray_laptop | Robin_Watts: which is why I'd like to look at handling > 64 bits directly | 16:57.11 |
| mvrhel2 | I need to head out for a bit | 16:57.29 |
| | bbiaw | 16:57.31 |
| Robin_Watts | ray_laptop: Does C99 offer int128_t? | 16:57.44 |
| shnur | hi. i am trying to understand output of (mupdf) pdfdraw -tt and pdfdraw -x . are there any docs? particularly about font names? | 16:58.48 |
| ray_laptop | Robin_Watts: I don't know. | 17:01.10 |
| shnur | e.g. what does MMZAAW stand for in <span font="MMZAAW+CMR10" size="10.9091" wmode="0" eol="1"> | 17:01.19 |
| Robin_Watts | shnur: That's the name as read from the PDF file. | 17:01.34 |
| | When people embed fonts in PDF files there is no exact standard for how they pack the font name. | 17:02.09 |
| | As such, the best mupdf can do is parrot it out again. | 17:02.25 |
| | MSVC does NOT offer a 128 bit type, apparently. | 17:04.26 |
| shnur | aha, and thus there are no heuristics that tell me anything about the font from the part before the + ? I understand that the second part is the usual font name (where B usually stays for Bold etc) | 17:04.26 |
| Robin_Watts | shnur: Now heuristics, maybe. But I don't know them. Our expert on this would probably be kens, and he's just gone for the night. Try again in 15 hours :) | 17:05.26 |
| shnur | another question: what does matrix and trm mean in <fill_text font="LLOVFJ+CMMI6" wmode="0" colorspace="DeviceGray" color="0" matrix="1 0 0 1 0 0" trm="5.9776 0 0 5.9776" > | 17:05.37 |
| Robin_Watts | or 15 hours + the weekend :) | 17:05.42 |
| | trm = text rendering matrix | 17:05.55 |
| ray_laptop | Robin_Watts: we do know the spot colors on the page before we have to do "real" compressed encoding (we start with 64 components, but put_params changes that). See the comment in gdevdevn.c line 454 | 17:06.14 |
| | shnur: the MMZAAW+ syntax is an Adobe convention for naming font subsets. Thus this is a specific subset of CMR10 | 17:07.41 |
| | shnur: The FontDescriptor has some useful info | 17:08.15 |
| | shnur: see section 5.7 of the PDF spec. | 17:09.24 |
| | but many of these are optional (even if strongly recommended). FontFamily is one, but less common are FontWeight and FontStretch | 17:10.57 |
| shnur | aha, thanks | 17:11.29 |
| ray_laptop | ItallicAngle is usually present, and StemV StemH can be used to infer weight | 17:11.42 |
| | shnur: with gs you can use -dPDFDEBUG to dump a PDF as it's being interpreted and see the FontDescriptors. PDF also has a "Widths" array that is required and useful in font substiution | 17:13.08 |
| | mvrhel2: are you still here ? | 17:14.38 |
| shnur | ray_laptop: thanks! font substitution is part of what i want (is there any standard library to do that, btw?). | 17:14.54 |
| ray_laptop | mvrhel2: with the first file from bug 692618, I am not getting any non-encodable colors with my branch that changes the band_height | 17:15.37 |
| | shnur: I wish. | 17:15.42 |
| | shnur: I think every PDF interp has their own approach. | 17:16.15 |
| | mvrhel2: is this 'expected' ? | 17:16.36 |
| Robin_Watts | mvrhel2: Can you sanity check me here please? | 17:16.46 |
| | (after ray, sorry) | 17:16.53 |
| ray_laptop | Robin_Watts: no rush with me, but I don't know if mvrhel2 is really here. | 17:17.19 |
| Robin_Watts | ray_laptop: AIUI, the non-encodable colors are caused by gradient fills, right? | 17:17.29 |
| | Changing the bandheight will change the way the paths are chopped up, and hence may change the exact values of the colors we get because of the shadings, right? | 17:18.20 |
| ray_laptop | Robin_Watts: yes, gradient fills on to 'layers' in the transparency stack that then get 'blended' with some other layers building up colors with 11 out of 13 components non-zero | 17:18.37 |
| Robin_Watts | hence it's possible that permuting the bandheight will knock us in to/out of a failing state. | 17:18.41 |
| ray_laptop | Robin_Watts: "a failing state" ? | 17:19.03 |
| Robin_Watts | with one value of the band height, it might work, with another it might fail. | 17:19.28 |
| ray_laptop | Robin_Watts: but the compressed color list isn't created for each band. | 17:20.26 |
| Robin_Watts | Paths get chopped up differently with different bandheights, right ? | 17:20.45 |
| ray_laptop | Robin_Watts: actually, I may be wrong there. Maybe it _does_ get created during the rendering of each band | 17:21.50 |
| | Robin_Watts: in which case smaller bands would have (naturally) fewer overall combinations of colors | 17:22.27 |
| Robin_Watts | Correct me if I'm wrong here, but the clist 'chops' paths so that we have smaller 'per band' paths that are just big enough to cover each band ? | 17:22.45 |
| ray_laptop | Robin_Watts: yes, that is correct. | 17:23.02 |
| shnur | let me see the docs you suggested... | 17:23.39 |
| Robin_Watts | Right, so rather than having 1 large path that gets filled with a gradient, we have several smaller paths that get filled with gradients that should approximate the original. | 17:23.44 |
| ray_laptop | Robin_Watts: I don't think we do gradient filling during clist rendering | 17:24.28 |
| ray_laptop | goes to check... | 17:24.35 |
| | the shading code is so convoluted :-( | 17:24.48 |
| Robin_Watts | Oh. | 17:24.50 |
| | so the shading decomposition is done BEFORE clist rendering? | 17:25.09 |
| | well, in that case, it blows my argument out of the water. | 17:25.31 |
| ray_laptop | Robin_Watts: I need to check. There are _so_ many special cases | 17:25.44 |
| Robin_Watts | I hope you are right about the compressed color thing being done per band is right. | 17:26.14 |
| | If so, we can cope with almost any arbitrary number of combinations by simply shrinking the bandheight :) | 17:26.40 |
| | henrys: I have a question about 13 year old code again :) | 17:27.26 |
| ray_laptop | Robin_Watts: hmm. Doesn't quite make sense. The color(s) that can't be encoded are being hit in pdf14_cmykspot_put_image during clist writing. | 17:27.40 |
| Robin_Watts | rats. | 17:27.55 |
| ray_laptop | Robin_Watts: I've been around longer than that. | 17:27.56 |
| Robin_Watts | Well, this has henrys name on it :) | 17:28.05 |
| | but I suspect it's actually a mixture of authors; one of those huge commits again. | 17:28.26 |
| ray_laptop | Robin_Watts: might as well ask (but if it's PCL then it is all henrys) | 17:28.30 |
| Robin_Watts | grep the source for stroke_adjust and you'll see a few references to it. | 17:28.55 |
| ray_laptop | I actually started using gs in 1991 | 17:29.05 |
| Robin_Watts | I can see where it goes through the clist etc. | 17:29.18 |
| | and where it's set/unset from ps etc. | 17:29.25 |
| | but I can only see one line where it's actually used. | 17:29.36 |
| ray_laptop | Robin_Watts: OK. | 17:29.52 |
| Robin_Watts | That is 1190ish in gxstroke.c | 17:29.53 |
| | But the condition there makes no sense to me. | 17:30.20 |
| ray_laptop | Robin_Watts: right in 'adjust_stroke' | 17:30.43 |
| Robin_Watts | if (!stroked_adjust) return would make sense. | 17:30.48 |
| | if (plp->width.x != 0 && plp->width.y != 0) return would also make sense. | 17:31.12 |
| | the first one being; if stroke adjustment is turned off, then don't mess with it. | 17:31.30 |
| | the second one being (I think) if it's not a horizontal or vertical stroke, then don't mess with it. | 17:31.54 |
| henrys | on the phone with a customer... | 17:32.15 |
| Robin_Watts | But the conjunction of the two makes no sense. | 17:32.20 |
| | henrys: np. | 17:32.23 |
| | Surely we want the disjunction there? | 17:32.38 |
| ray_laptop | Robin_Watts: 'always_thin' (0 weight lines) are handled separately and always imaged (per Adobe spec). the width.x width.y can only both be 0.0 if the line is 0 weight | 17:35.04 |
| Robin_Watts | It's not checking for them both being 0. | 17:35.22 |
| | It's checking for them both being NON 0. | 17:35.36 |
| | AIUI, for a horizontal line, width.y !=0, width.x = 0. | 17:35.57 |
| | for a vertical line, width.y = 0, width.x != 0 | 17:36.08 |
| ray_laptop | Robin_Watts: oh, you are right. so if it is horizontal or vertical, then we don't adjust | 17:36.10 |
| shnur | ray_laptop: is there a way to get character widths, font family data etc with mupdf ? That is, I want to have the data about position, font, width etc of each character in a pdf file, in a form i can process ith regexps. I was not able to see how do that with gs -PDFDEBUG but i have not really looked yet. | 17:36.22 |
| Robin_Watts | Right. EXCEPT that's not what the current code does. | 17:36.23 |
| | The current code says: if (we aren't stroke adjusting AND it's diagonal) then bale | 17:36.49 |
| ray_laptop | shnur: I'm sure there is, but I don't muck with mupdf much. tor8 would be the one to ask | 17:36.52 |
| | Robin_Watts: ok, that makes sense. There is no reason to 'adjust' the starting pixel of a diagonal line | 17:37.54 |
| Robin_Watts | ie. we stroke adjust whenever stroke adjustment is turned on (regardless of the orientation of the line) or when the line is horizontal or vertical (regardless of the stroke_adjust param) | 17:37.55 |
| | I reckon the first && should be || | 17:38.11 |
| shnur | ok, thanks! i shall read the docs and come back when tor8 and kens are around. thanks for help! | 17:38.44 |
| ray_laptop | shnur: I don't think kens plays with mupdf, either (Robin_Watts does, but I don't know if he can help you) | 17:39.33 |
| Robin_Watts | ray_laptop, shnur: I fear that mupdf won't quite give you the output you want at the moment. | 17:40.07 |
| | but it's probably not that hard to add it. | 17:40.20 |
| shnur | i see..what tool would you suggest me to use , then ? | 17:42.35 |
| Robin_Watts | shnur: well, sorry, let me backtrack. | 17:43.22 |
| | You say "I want to have the data about position, font, width etc of each character in a pdf file" | 17:43.35 |
| | Well, mupdf gives you exactly that. | 17:43.50 |
| ray_laptop | Robin_Watts: I thought he also wanted the weight, italic, family name, etc. | 17:44.24 |
| Robin_Watts | it gives you the bbox for every occurence of every char, and the font its in. | 17:44.25 |
| | It doesn't give the extra information that ray_laptop just mentioned. | 17:44.43 |
| | But mupdf knows that information (or can get it easily) | 17:44.57 |
| shnur | yes, i do want to know the weight, italic, familiy name etc | 17:44.59 |
| Robin_Watts | It would be fairly easy to tweak the source to get that information and output that as well. | 17:45.21 |
| | The text output stuff in mupdf is still very new; if there is more information we could usefully be giving, we'll certainly consider it. | 17:45.49 |
| shnur | right. though i do not know much about PDF and fonts. | 17:46.02 |
| Robin_Watts | But it's not a huge priority at the moment as both tor8 and I are occupied elsewhere. | 17:46.04 |
| ray_laptop | Robin_Watts: that code appears to have come from Igor with commit 00d0d976 | 17:46.19 |
| Robin_Watts | but I'm sure we could talk you through making the modifications. | 17:46.21 |
| | The line in question seems to be henrys. 5fbdbaab | 17:46.56 |
| ray_laptop | Robin_Watts: I see (with git blame): 00d0d976 gs/src/gxstroke.c (Igor Melichev 2008-06-09 07:33:57 +0000 1187) if (!pis->stroke_adjust && | 17:47.46 |
| shnur | Robit_Watts: I am not sure I know enough to do that. But let us try: just give me some keywords or/and filename to look at. If I can see that I can do something, I'll come back with more questions. | 17:48.27 |
| Robin_Watts | ray_laptop: Bah. serves me right for using a gui tool. You're right. | 17:49.34 |
| henrys | I'm back | 17:53.38 |
| Robin_Watts | henrys: Are the logs enough, or would you like me to reiterate? | 17:57.59 |
| henrys | my speed read indicated it wasn't my fault so I went back to something else. | 17:58.47 |
| Robin_Watts | I'd like a sanity check from someone that I'm reading that line correctly. | 18:00.00 |
| | If stroke adjustment is turned off, we shouldn't be doing stroke adjustment, right? | 18:00.30 |
| | And we shouldn't ever be doing stroke adjustment on non horizontal/vertical lines, right ? | 18:00.51 |
| ray_laptop | ahh... I think I understand why the non-encodable color issue goes away. | 18:01.33 |
| henrys | reading the code .. | 18:01.36 |
| ray_laptop | but I won't interrupt now. I'll write it up and attach to the bug report. | 18:02.07 |
| | time to take lunches to my kids.... bbiaw | 18:02.30 |
| Robin_Watts | This leaves a separate issue, of whether stroke adjustment should be turned on for xps or not, but... | 18:03.21 |
| henrys | Robin_Watts:right || would seem like a better choice. | 18:03.23 |
| Robin_Watts | henrys: thanks. | 18:03.30 |
| | I'm cluster pushing that now. | 18:03.39 |
| henrys | can we just get rid of this crazy stuff that makes us recal demorgans or something when reading the code. split it into 2 steps. | 18:06.21 |
| | I guess it isn't that complicated. | 18:07.03 |
| | but it's surprising how much faster you can read something if a few connectives are pulled out. | 18:07.43 |
| Robin_Watts | henrys: I've used an exciting new software engineering technique, called a "comment". | 18:07.44 |
| henrys | ah the old "that which should not be trusted" technique | 18:08.13 |
| Robin_Watts | It's another point of contact. | 18:08.46 |
| | You get to check that your understanding of what it's doing matches the comment. | 18:09.06 |
| | and you get to check that the comment matches the code. | 18:09.13 |
| henrys | the || changes the sense of the second part right? | 18:10.45 |
| Robin_Watts | /* If stroke_adjustment is disabled, or this isn't a horizontal or | 18:11.00 |
| | * vertical line, then bale. */ | 18:11.02 |
| | if (!pis->stroke_adjust || (plp->width.x != 0 && plp->width.y != 0)) { | 18:11.04 |
| | dev->sgr.stroke_stored = false; | 18:11.06 |
| | return; /* don't adjust */ | 18:11.08 |
| | } | 18:11.10 |
| henrys | okay | 18:11.59 |
| Robin_Watts | mvrhel2: For when you return; I believe I've found a bug in the stroke_adjust code whereby it was adjusting strokes when it shouldn't have been. | 18:25.42 |
| | Even if I fix this, the example you give still goes wrong, because XPS has stroke adjustment enabled by default. Should it have? | 18:26.10 |
| | xps_imp_allocate_interp_instance calls gs_state_alloc(pmem) to setup the graphics state, and that sets stroke adjust. At any point after that you could turn it off with a call to gs_setstrokeadjust(ctx->pgs, false); | 18:27.49 |
| | I'm going to cook for a bit. I'll check back periodically in case mvrhel2 returns. | 18:28.48 |
| | 25000 diffs. Well, I'm not looking through 'em all. | 19:15.14 |
| | shnur: I'm not going to have time to give you pointers tonight, sorry. But at some point. | 19:16.44 |
| mvrhel2 | Robin_Watts: I guess I need to look to see what stroke_adjust does | 20:12.16 |
| | or can you tell me | 20:12.19 |
| | oh maybe I need to read above | 20:13.59 |
| | Robin_Watts: so I don't know if stroke_adjust should be on or off for XPS as I don't know what stroke adjust does. I do know that zero width lines should not be shown in XPS | 20:17.37 |
| | need to head into the school now..... | 20:17.48 |
| tor8 | shnur: fitz/dev_text.c fz_debug_text_span.* | 20:27.53 |
| | shnur: you may be interested in looking at the 'text' branch, which has newer more feature complete (but still beta quality) code | 20:28.23 |
| henrys | does anyone know what 9.04 with hot fixes is in the latest support message? | 21:14.54 |
| mvrhel2 | henrys: no idea | 23:07.36 |
| Robin_Watts | mvrhel2: ping? | 23:28.09 |
| | mvrhel2: Stroke Adjustment is a thing whereby horizontal and vertical lines are moved slightly so they render more 'evenly'. | 23:28.48 |
| | See section 7.5.2 of the PLRM. | 23:30.55 |
| | tor8, shnur: Sorry. I was assuming that shnur was looking at the text branch already... | 23:33.02 |
| domus | Hi, everybody. Can I ask a licensing question about a MuPDF product here or is that totally out of the question? | 23:52.56 |
| Robin_Watts | domus: We tend to refer people for licenses to our sales guy, but we may be able to help with the broad stokes. | 23:55.23 |
| domus | You're too kind. I have, of course, first contacted the sales guy at Artifex, asking about licensing costs, but the reply amazed me and left me baffled and without solution... | 23:56.27 |
| | I inquired about what it'd cost me to deploy the PDFDraw.exe application along with an application I wrote. | 23:57.26 |
| | I got the reply they were not able to handle licensing that was low volume. | 23:57.48 |
| | To whom does one turn with low volume licensing stuff in this case? | 23:58.20 |
| Robin_Watts | Well, low volume, high value we can do :) | 23:58.42 |
| domus | lol | 23:58.47 |
| | Can anyone give me some ballpark figure? | 23:58.57 |
| Robin_Watts | low volume, low value is the problem; it has to be worth getting the lawyers out of bed :) | 23:59.05 |
| | No. $$$ figures are something that we (well, me at least!) won't go near. That's Scott and Miles' territory. | 23:59.33 |
| | mupdf is available under the GPL. | 23:59.51 |
| | Forward 1 day (to 2011/10/29)>>> | |
IRC Logs