| | <<<Back 1 day (to 2011/12/13) | 2011/12/14 |
| chrisl | kens: I think the problem is slightly different to what I put in the e-mail - pdfwrite (I think) gets the "right" font, but *something* seems to be hanging around from the original loading - I'm experimenting now. | 08:08.31 |
| kens | You are ahead of me, I'm still reading last nights IRC logs. | 08:08.51 |
| | I may ask you some dumb questions i na minute | 08:09.01 |
| | OK I've hacked zchar_set_cache so that it executes the CDevProc, I now get properly spaced text, but the wrong glyphs again. | 08:19.13 |
| | Which test file are you suing chrisl ? | 08:21.16 |
| chrisl | I've been using Bug692320.pdf | 08:22.29 |
| kens | OK. I tried using thrane.pdf and most of the text goes missing. | 08:22.44 |
| | 692320 is a bit complex and takes a long time to process | 08:22.59 |
| chrisl | I'm only processing the first page - I'll switch to thrane.pdf | 08:23.23 |
| kens | No don't do that, I'm not sure what's going on there, but it has 2 missing fonts. | 08:23.41 |
| | Just cracked open the PDF file and most of the text really is missing, don't know why. | 08:24.44 |
| chrisl | I'd expect thrane.pdf to work because it seems to use Identity ordering, which is what the default fallback uses initially | 08:24.59 |
| kens | The inital part of the text works, but then it just stops. Odd. | 08:25.21 |
| | The aring glyph is wrong too :-) | 08:25.34 |
| | But I think that's excusable | 08:25.45 |
| chrisl | What I found with Bug692320.pdf was that if I changed the default fallback record to load the font with Korea1 ordering, the pdfwrite output is "correct" | 08:26.05 |
| kens | OK, what difference does that make to the output file ? | 08:26.27 |
| | Does it change the CIDs in the text ? | 08:26.39 |
| | BTW thrane.pdf has most of the text missing with rendering too | 08:26.53 |
| | So its not a pdfwrite problem. | 08:26.59 |
| | Looks like it throws an error for some reason. | 08:27.16 |
| chrisl | thrane.pdf works for me, to rendering, at least | 08:28.35 |
| kens | Really ? Maybe I'm missing somethign else | 08:28.47 |
| | Of course I have a hack instead of a proper fix for the CDevProc issue. | 08:29.11 |
| chrisl | So, maybe I should commit my CDevProc change, then | 08:29.30 |
| kens | I think it would be a good idea. | 08:29.37 |
| | Even the wrong glyphs is better than the error we throw | 08:29.51 |
| chrisl | Okay, I need to revise your comment, then I'll do so | 08:29.55 |
| kens | OK. | 08:30.01 |
| chrisl | Actually, I should cluster test it first...... | 08:32.26 |
| kens | :-) | 08:32.33 |
| chrisl | kens: In the interim, should I send you a patch? | 08:38.13 |
| kens | Yes please. | 08:38.23 |
| | I'm just making a reduced file | 08:38.29 |
| chrisl | On its way. TBH, I'm wondering if a different approach to creating the substitute might be better........ | 08:40.15 |
| kens | Without knowing what the problem is, its hard to tell | 08:40.31 |
| | OK patch is here | 08:41.27 |
| chrisl | Well, based on my experiments, as I said, it looks like if I load the CIDFont substitute with the expected ordering from the start, pdfwrite is happy with it - something about *redefining* the CIDFont is the problem. | 08:41.41 |
| kens | Which is interesting. | 08:42.03 |
| chrisl | So, I'm wondering if a better solution would be to manipulate the CIDFont resource .map dictionary to include a mapping on the fly | 08:43.41 |
| kens | It would make my life easier I guess, but I don't really know enough to comment | 08:44.09 |
| chrisl | Well, I had rather assumed that you could redefine CIDFonts with the same abandon as you can fonts. I still think it ought to work..... | 08:45.24 |
| kens | CIDFont handling in pdfwrite is way more complex.... | 08:46.18 |
| chrisl | I guess what I'm saying is: has my code exposed a bug/limitation in pdfwrite, or am I doing things ought not to be done...... | 08:46.37 |
| kens | I think manipulating a CIDFont after you've loaded it is probably bad, but whether tis legal is a different question | 08:47.15 |
| chrisl | Well, I'm doing it "properly" in that I don't mess with the font in place, I create a brand new dictionary with only the "base" entries, and then do defineresource | 08:48.26 |
| kens | That sounds like it should be OK. | 08:49.03 |
| chrisl | I'd think that creating a new dictionary without things like the FID would sever any link to "internal data" that might confuse things. | 08:50.30 |
| kens | OK simplified test file on its way to you. | 08:50.59 |
| | brb | 08:51.02 |
| | chrisl how do you modify the record to use Korean ordering ? | 08:58.24 |
| chrisl | Erm, in gs_cidfm.ps there's a default definition of the CIDFallBack mapping | 09:01.22 |
| kens | OK | 09:01.31 |
| chrisl | If you search for /CSI [(Identity) 0] and replace the "Identity" with the ordering you want to test | 09:02.14 |
| kens | Yes got that | 09:02.26 |
| | Indeed, that looks fine. | 09:03.18 |
| | Hmm, we get a completely different CIDToGIDMap in the output | 09:04.16 |
| | And a different subset font. | 09:04.54 |
| | So it looks like we end up doign something differetn with CIDs. The 'incorrect' one is using an Identity mapping. | 09:05.48 |
| | Which is sort of suspicious. | 09:05.58 |
| chrisl | Well, as you saw, I normally load the base CID fallback with Identity and then (I thought!) create a new CIDFont with the appropriate CIDSystemInfo | 09:09.41 |
| kens | Yes, it looks like the Identity is persisting though, as you suspected. I'm trying to track it down. | 09:10.08 |
| | Its not taking the path I expected. | 09:10.15 |
| | OK found it where the map is created at least | 09:11.40 |
| | Quelle surprise, the cidtogid mapping is filled in in scan_camp_text | 09:15.04 |
| | We seem to be picking up the mapping from teh descendant font. | 09:15.41 |
| | It uses z11_CIDMap_proc to get a GID given a CID. | 09:16.29 |
| chrisl | Surely that must work, or rendering would be wrong? | 09:17.01 |
| kens | I don't know, I can check in a minute, but I'm by no means certain that rendering uses this path | 09:17.28 |
| | Notes to self: With Korea1 mapping, CID 0x495-> GID 0x582b | 09:18.32 |
| chrisl | Okay, CDevProc change pushed | 09:19.09 |
| kens | With Identity mapping CID 0x495-> GID 0x495 | 09:19.35 |
| | Rendering does not exercise that code path. | 09:20.11 |
| | Which is why it works. | 09:20.17 |
| | chrisl it looks like you aren't attaching the correct CIDMap to the descendant font, I have no idea where that would be done though. | 09:21.01 |
| | I'm thinking this is part of the font substitution process. | 09:21.18 |
| chrisl | OKay, let me have a poke around at it. | 09:22.28 |
| kens | Could be the Decoding resource perhaps ? Looks like you are making the font with an Identity Decoding, and it needs to be done with a Korea1 Decoding. Don't understand why this would work for rendering though. Surely we must get the correct GID somehow. | 09:31.04 |
| chrisl | That's what I was thinking. None of the procedures for building the CIDMap are "openly" available, they're all hidden in the resource remapping cr*p | 09:39.13 |
| kens | Yes, I did dig into this once, long ago.... | 09:39.28 |
| | It does look like the CIDMap is wrong if the Identity CSI is used though, and tht seems to be the source of teh problem for pdfwrite. What I *don't* understand is how rendering works. | 09:40.12 |
| chrisl | Let me investigate messing with the .map dictionary on the fly, that might save some pollution of the resource dictionaries as well | 09:41.29 |
| kens | OK I'll be going out in an hour, let me knwo if you want to bounce ideas off, or have me investigate what pdfwrite is up to. | 09:42.07 |
| chrisl | I figure I should have an answer about changing .map on the fly by the time you get back from riding - I'll let you know...... | 09:43.21 |
| kens | Thanks. | 09:43.31 |
| kens | realises he's actually going out in 40 minutes. Time flies... | 09:44.16 |
| chrisl | kens: it *looks* like manipulating the .map dictionary on the fly will work | 10:09.50 |
| kens | That sounds good. presumably that gives us a correct CIDMap | 10:10.09 |
| chrisl | Yes, because we go straight creating the faux CIDfont with the correct CSI data, we never load the font with "dummy" settings | 10:11.17 |
| kens | OK, that sounds like a better approach if tis feasible | 10:11.35 |
| | Still seeing problems with thrane.pdf so I'm doing a clean and rebuild | 10:12.13 |
| | OK thrane.pdf is fine now (except for the aring glyph and some spacing weirdness) , must have been some residual flakiness. | 10:21.08 |
| | Works for pdfwrite too. | 10:21.14 |
| chrisl | Well, that's about a good as I'd expect. I need to tidy up the code I've got for this, and test it more - but I think I need coffee first! | 10:22.57 |
| kens | The spacing is just caused by glyphs being different widths. | 10:23.20 |
| | The aring is 'well, its a best guess' I think. | 10:23.31 |
| | Its probably as good as can be expected when the font is missing | 10:23.52 |
| chrisl | Very probably, DroidSansFallBack isn't "complete" | 10:24.15 |
| kens | So now, instead of 'I get an error, Ghostscript crashed' We'll get 'it doesn't look the same as Acrobat'.... | 10:24.27 |
| | I need to dash, be back later. | 10:25.12 |
| chrisl | Okay | 10:25.16 |
| Robin_Watts | tor8: ping | 13:27.35 |
| | So, I've got some code changes underway here, and i thought I should discuss the direction I'm going with it with you. | 13:28.24 |
| tor8 | Robin_Watts: good (late) morning | 13:28.43 |
| Robin_Watts | Every storable item now starts with an fz_storable structure. | 13:28.56 |
| | This structure contains a reference count, the drop function, and a pointer to the 'fz_item' which corresponds to it (NULL if it's not in the store) | 13:29.38 |
| | All fz_keep/fz_drop of storable items ends up using that ref count. | 13:30.09 |
| | The store is now fz_store rather than pdf_store. | 13:30.42 |
| tor8 | I thought you were going to rename it to cache :) | 13:31.04 |
| Robin_Watts | Maybe later :) | 13:31.16 |
| tor8 | alright :) | 13:32.13 |
| Robin_Watts | At the moment the store is split into two, the ones indexed by an indirect object, and the ones that aren't. | 13:32.20 |
| tor8 | for XPS we'll want indexed by a string/filename | 13:32.39 |
| Robin_Watts | ok, will need to think about that. | 13:33.11 |
| tor8 | I guess we could turn that into a number easily enough though | 13:33.12 |
| Robin_Watts | I'd like to extend the linked list through ALL the objects. | 13:33.33 |
| tor8 | but that's a bit of an ugly hack | 13:33.42 |
| Robin_Watts | (both the ones in the hash table, and the ones that aren't) | 13:33.43 |
| tor8 | which linked list? | 13:33.55 |
| Robin_Watts | The ones that aren't indexed by an indirect object are held in a linked list | 13:34.16 |
| tor8 | ah, right! | 13:34.27 |
| Robin_Watts | I want to make that doubly linked (so removals given an object take constant time) | 13:34.51 |
| | and I want to use it in an LRU style (so that uses of objects pull them to the top of the list) | 13:35.33 |
| | and I want to extend that through the hashed objects too. | 13:35.47 |
| | So when we run out of memory, we can bin items off the end of the list. | 13:36.08 |
| tor8 | right. so if I understand what you're trying to achieve: hashtable for fast lookups, double linked list for LRU. | 13:36.16 |
| Robin_Watts | yes. | 13:36.23 |
| | Ideally, I'd like ALL items to be hashed and all to be on the LRU. | 13:36.36 |
| tor8 | which hashtable implementation are you using? | 13:37.03 |
| Robin_Watts | To do that it means we'd have to find a way of generating a hash from non-indirect objects. | 13:37.05 |
| | I haven't changed the hashtable implementation. | 13:37.18 |
| tor8 | we could have a 'hash' function in fz_storable | 13:37.27 |
| | right, so you're using the fz_hashtable | 13:37.35 |
| Robin_Watts | It's the key that needs to be hashed. | 13:37.40 |
| | not the value. | 13:37.44 |
| | storable things are values. | 13:37.50 |
| tor8 | content addressed storage ;) | 13:38.00 |
| | I mean we can put the key, or make one up, in the storable struct | 13:38.18 |
| Robin_Watts | One wrinkle to this is that for some of the storable things (colorspaces, cmaps, etc) we have 'static' ones too. | 13:38.53 |
| tor8 | I'm thinking we could do like git for non-indirect-reference type objects | 13:39.00 |
| Robin_Watts | tor8: you mean SHA1 them? (or something like that) | 13:39.18 |
| tor8 | yeah, in the absence of an indirect object number which is a fairly unique identifier, checksum the data | 13:39.38 |
| Robin_Watts | tor8: That seems reasonable; what gives me pause there is what happens if we have << /Foo 1 /Bar 2 >> and << /Bar 2 /Foo 1 >> | 13:40.19 |
| | Do those come out as equivalent ? | 13:40.44 |
| tor8 | depends a bit on whether we expect everything to be uniquely identified in the store. I'm assuming it would. | 13:40.54 |
| | in the old pdf_store implementation those would be different | 13:41.24 |
| Robin_Watts | My worry is that someone might try to look up something from the store with the first of those, and not find it because it was inserted with the second one. | 13:41.32 |
| tor8 | but if the data is the same, there's no harm in finding a duplicate | 13:41.49 |
| Robin_Watts | well, if we go the 'simple' hash making route, then we'd be no worse off. | 13:42.02 |
| tor8 | my main worry with any invent-a-key scheme is getting false positives -- finding an object that isn't the one you wanted | 13:42.37 |
| Robin_Watts | tor8: well, we'd have to check the key, right? | 13:43.05 |
| | no one should assume in any hash scheme that we won't get collisions. | 13:43.27 |
| tor8 | yeah, but if we invent keys, what if we end up with the same key for two different objects | 13:43.29 |
| | the hash scheme for the hashtable is not important, that's just an optimization :) | 13:43.43 |
| | (maybe we mean different things with 'key' here) | 13:44.15 |
| Robin_Watts | We have a 'key' to use to look up. We hash that to get a hash value. | 13:44.42 |
| tor8 | yes. | 13:44.57 |
| Robin_Watts | The hash value gets us quickly to a value. We check the key against the key stored with the value to see if it's the same one. | 13:45.16 |
| tor8 | yes. | 13:45.35 |
| Robin_Watts | If it is, we've found it, if not, we look at the next one in the same 'bin' (or linear probe etc) | 13:45.38 |
| | so hash collisions are inefficient, but not fatal. | 13:45.49 |
| tor8 | my concern is with generating the key that is used to test for object equivalence | 13:45.51 |
| | in the indirect reference or xps filename case, it's not an issue | 13:46.03 |
| | but if we make one up for generic fz_obj objects ... we could land in hot water depending on how you do it | 13:46.39 |
| Robin_Watts | The key *is* the generic fz_obj. | 13:46.54 |
| tor8 | okay. so you're just talking about getting a hash value out of that! | 13:47.11 |
| Robin_Watts | It's just we need a smart.... yes. | 13:47.18 |
| tor8 | I still haven't had my coffeine :) | 13:47.24 |
| Robin_Watts | If we want to cope with xps filenames as well, then either we need to shoehorn xps filenames into fz_objs (yuck!) | 13:47.51 |
| | or we need to make a more generic key type. | 13:48.07 |
| | something that can encapsulate both fz_obj and the xps things. | 13:48.48 |
| | For now, I'll just try and make something work with pdf. | 13:49.02 |
| | 2 other problems: | 13:50.24 |
| tor8 | get it working with pdf first, it shouldn't be too hard to change the hashing to work with filenames (or inodes or zipfile indexes) later. | 13:50.32 |
| Robin_Watts | 1) I need code to establish the 'size' of the storable things. (So I can watch the size of the store, and dump stuff if it gets too big) | 13:51.01 |
| | 2) The 'static' versions of storable things (colospaces, cmaps etc) are tricksy hobbitses. | 13:51.32 |
| tor8 | I saw your question about #2 yesterday. I expected that we wouldn't store them at all. | 13:52.10 |
| | another question: where is the fz_store? is it hidden in the context, or visible to the code that uses it? | 13:52.42 |
| | because ... what happens if you store one object in two stores | 13:52.53 |
| Robin_Watts | Well, suppose we read a colorspace out of a file (say a Lab one), and we don't cope with that, so we go on and read the alternate, and end up with a DeviceRGB. | 13:53.11 |
| | That will still be stored, right? | 13:53.17 |
| tor8 | let me look :) | 13:53.25 |
| | it may very well be | 13:53.31 |
| Robin_Watts | Key to this idea is that every item only gets stored in a single store at a time. | 13:54.16 |
| | (every storable structure only has one item pointer!) | 13:54.30 |
| tor8 | hmmm. I think I see what I did there. I just refuse to touch the refcount of static objects. | 13:54.42 |
| | so yeah, tricky hobbitses indeed. | 13:55.01 |
| Robin_Watts | yeah. | 13:55.03 |
| | So my plan was to allow static items to be put in the store, but never update the store pointer for them. | 13:55.30 |
| tor8 | and I guess it wouldn't make sense to keep the fz_storable struct separate from the thing being stored, as a link between the resource and the store | 13:55.47 |
| Robin_Watts | That means they can be inserted and removed manually from the store just fine, but they will never be evicted automatically. | 13:56.05 |
| tor8 | which would let us put things in multiple stores (by making a linked list from the resource to the storable-info) | 13:56.18 |
| Robin_Watts | (which probably makes sense as evicting them can never save memory) | 13:56.22 |
| tor8 | but that defeats the point of it, I think | 13:56.26 |
| Robin_Watts | tor8: When I coded the caching scheme for my previous employer, I had exactly that. | 13:56.48 |
| | I had a separate 'cache_entry' struct, and eviction would throw away the contents of the cache_entry, without destroying the cache_entry itself. | 13:57.29 |
| tor8 | let me see if I understood that correctly: you'd insert them into the hash and list, but not update the resource->storable.item that points back to the hash/list? | 13:57.29 |
| Robin_Watts | Yes. | 13:57.40 |
| tor8 | remind me again, why do we need the storeable.item pointer back into the list? | 13:58.38 |
| Robin_Watts | (but the cache_entry scheme means that we don't get the nice transparent handling of things by using the standard reference counting - we'd need to move to explicit cache handling, and that would complicate the code) | 13:58.39 |
| | tor8: For when we fz_drop(ctx, obj); | 13:59.23 |
| tor8 | ah, right! | 13:59.30 |
| | which is not a problem with the static ones. | 13:59.38 |
| | I get it :) | 13:59.40 |
| | sounds like a reasonable approach. | 13:59.48 |
| Robin_Watts | yeah. I *think* it all works out. | 14:00.02 |
| | So I'll keep bashing at this today. | 14:00.14 |
| | after lunch :) | 14:00.18 |
| tor8 | I don't spot anything obvious either. | 14:00.23 |
| Robin_Watts | cool. | 14:00.27 |
| tor8 | just as a digression, I did implement an LRU for the glyph cache once | 14:00.57 |
| Robin_Watts | what does it use now ? | 14:01.16 |
| tor8 | but since I had some weird ideas about packing the glyph data tightly in a cache buffer | 14:01.18 |
| | it just performed worse than if I just threw the whole cache away when it filled up... | 14:01.39 |
| Robin_Watts | Another potential idea for future is to have a 'shuffle' entry for stored things. | 14:01.59 |
| tor8 | and that's what it still does today. zapped when full. so there's another task if you want to battle it :) | 14:02.02 |
| | I think I wanted to avoid doing separate mallocs for each glyph bitmap | 14:02.17 |
| Robin_Watts | which reallocs things to allow them to shift in memory and avoid sandbars. | 14:02.24 |
| tor8 | but in retrospect, that would be so much easier | 14:02.25 |
| Robin_Watts | tor8: yeah. Another day, another battle. :) | 14:02.43 |
| | boss is calling me for lunch. bbs. | 14:02.55 |
| tor8 | okay. send my regards. | 14:03.08 |
| gegooo | Hi, I tried to decode halftone JBIG2 files with jbig2dec but only generic and text regions were decoded. Someone here who knows about halftone support of jbig2dec? | 14:23.38 |
| | I wrote a EMail months ago but the mailinglist seems (nearly) dead (http://ghostscript.com/pipermail/jbig2-dev/2011-August/000125.html) | 14:25.24 |
| chrisl | gegooo: it doesn't support halftone regions: http://bugs.ghostscript.com/show_bug.cgi?id=691247 | 14:25.38 |
| gegooo | Aha. Thank you. Didn't know that jbig2dec has a bugzilla. (it is not linked by http://jbig2dec.sourceforge.net/) | 14:28.47 |
| chrisl | gegooo: I think the sourceforge page is a bit dead, to be honest | 14:29.56 |
| gegooo | Are there any efforts to implement halftones? Are patches for halftone implementation welcome? | 14:34.11 |
| chrisl | gegooo: I'm not aware of any efforts currently going on, patches are welcome (we'd prefer the copyright assigned to Artifex). There is already a patch in bugzilla, but it appears incomplete/faulty - and is well out of date with the current code. | 14:36.19 |
| | gegooo: if you check back in a couple of hours, the current owner of that code is henrys, he can probably give you more definitive answers | 14:37.06 |
| gegooo | ok. Thank you. | 14:37.28 |
| chrisl | np | 14:37.43 |
| kens | chrisl, sorry I'm late, did you get anywhere with the mapping thing ? | 15:38.04 |
| chrisl | kens: yes, I think I've got it working - just ironing out the error handling | 15:38.55 |
| kens | Sounds great. | 15:39.05 |
| | I forgot I had a lunch engagement.... | 15:39.17 |
| chrisl | If you're interested, you can look at my latest bmpcmp to see the pdfwrite output I get not | 15:39.37 |
| kens | Will do. | 15:39.47 |
| chrisl | Not a problem - I keep thinking of another error I need to handle, or another "something" I need to validate to be safe | 15:40.21 |
| kens | Hmm, that first set of diffs is odd. THe scond one look great | 15:40.38 |
| | So just the two files showing differences. | 15:41.17 |
| chrisl | Yes, the first file, I'm not sure - it seems to be showing differences in things that aren't text (as well as the text). | 15:43.22 |
| kens | Yes, some of it seems to be subtle grey scale differences. Weird. | 15:43.42 |
| | Is that file usually indeterminate do you remember ? The name is familiar.... | 15:44.04 |
| chrisl | I don't remember, but *only* in one set of halftoned output | 15:44.28 |
| kens | Strange. | 15:44.51 |
| chrisl | Yes, it is listed as having previous problems in the delta readout, so it does seem to be an indetermism | 15:46.30 |
| kens | No reason to worry about it then, that's good. | 15:46.56 |
| chrisl | Yep, and all my test files "work" as expected. | 15:47.28 |
| kens | Great, sounds like a good result all over. | 15:47.57 |
| chrisl | Now my final problem is if we reach the very final fallback of the ArtifexBullet CIDFont, the pdfwrite output is largely emtpy, whilst the rendered output has the intended bullets. | 15:48.46 |
| kens | Hmm, strange, I'm inclined not toworry, but do you want me to take a look ? | 15:49.18 |
| chrisl | I think it's the same issue, but as I've got ArtifexBullet as a real CIDFont. | 15:50.00 |
| | Oops, wrong key | 15:50.15 |
| | Anyway, I just load ArtifexBullet with the Identity ordering, and let the chips fall where they may - we only have one glyph in it, so ordering *shouldn't* be very important | 15:51.06 |
| kens | Absolutely. | 15:51.17 |
| | Have you opened the PDF with Acrobat or GS or both ? | 15:51.29 |
| chrisl | Actually, with this setup, only evince, let me try GS and Acro | 15:52.05 |
| kens | I would, it may be eliding /.notdef | 15:52.19 |
| | Or somethign similar | 15:52.24 |
| chrisl | Odd, opening it in GS shows bullets, but not as many as I'd expect...... | 15:53.16 |
| | The Acrobat display is "peppered" with bullets, similar to the GS output, so I think it's about as good as you might expect for such a "fallback for a fallback" position | 15:55.24 |
| kens | Yeah, sounds reasonable to me. | 15:55.37 |
| chrisl | I've also added command line options and environment variables which allow the path to, and the file name of the fallback font to be changed from the default. | 15:56.54 |
| kens | Sounds very comprehensive. | 15:57.07 |
| chrisl | It occurred to me that most Linux dists are now already shipping DroidSandsFallback.ttf, so they'll probably want it to straight forward to direct GS at their existing copy. | 15:58.20 |
| kens | Yes, that makes sense. | 15:58.56 |
| chrisl | Ironically, after all that, the substitution code has actually ended up shorter and simpler :-) | 15:59.39 |
| kens | Well worh tit hten.... :-) | 15:59.54 |
| chrisl | With all the changes I've done, I'm going to do another clusterpush before I commit | 16:00.50 |
| kens | OK, I'll go back to the problem list | 16:01.08 |
| chrisl | I've even updated Use.htm - how very dedicated of me....... | 16:01.51 |
| kens | It all looks good to me, are you goign to commit it now ? | 16:24.38 |
| chrisl | Yes, just writing up the commit comment now | 16:28.14 |
| kens | Great, it'll be good to get that done. | 16:32.33 |
| chrisl | There, pushed..... | 16:34.31 |
| kens | Excellent, congratulations on getting that done! | 16:34.50 |
| chrisl | Thanks - it would have been much quicker if not for that crazy resource remapping nonsense! | 16:35.29 |
| kens | Yeah, I'm fairly sure that was causing the CIDMap problem. | 16:35.56 |
| chrisl | It makes sense to have the "helper procedures" for each subcase not global in scope, but to hide them completely just seems deranged! | 16:36.58 |
| kens | :-) | 16:37.08 |
| kens | is off | 17:28.14 |
| | Goodnight all. | 17:28.18 |
| Robin_Watts | Night kens | 17:28.25 |
| chrisl | night | 17:28.27 |
| Robin_Watts | tor8: Nothing else uses fz_hash currently, right? | 17:28.35 |
| | oh, rats, yes. | 17:29.23 |
| tor8 | the glyph cache I believe | 17:29.41 |
| | and the colorspace memoization | 17:30.13 |
| mvrhel_laptop | hi marcosw: I was wondering if you did the run of plank with the color halftone turned on? | 17:57.00 |
| henrys | mvrhel_laptop:I tested usefastcolor - I verified it is getting the identity link in the debugger - and as expected it does speed up files. Maybe Marcos can run the performance suite. | 18:18.10 |
| mvrhel_laptop | ok | 18:18.24 |
| | good | 18:18.27 |
| | waiting at SLC airport for scott to arrive | 18:23.59 |
| | at least they have free wifi | 18:24.07 |
| | unlike the miami airport | 18:24.11 |
| henrys | yeah we have it too at denver - sit through an ad first though. | 18:25.32 |
| gegooo | Hi henrys, I interested in halftone support for jbig2dec. Are there any efforts in implementing? | 18:26.19 |
| | sorry: I am interested in ... | 18:26.55 |
| henrys | hello gegoo somebody is working on jbig2 now but I don't know if he wants to take that on. | 18:27.30 |
| | is this a bountiable bug? | 18:27.37 |
| | oh are you interested in doing it or having it? | 18:28.19 |
| Robin_Watts | From what gegooo said earlier, both, I think. | 18:29.29 |
| | (he specifically asked if we'd be interested in patches to do it) | 18:29.43 |
| gegooo | I am coding for GNU PDF and I think it would nice to support this. | 18:29.46 |
| henrys | anything we put into jbig2dec has to have GPL and Artifex copyright is that a problem? | 18:31.33 |
| gegooo | yes, both | 18:31.34 |
| henrys | I assume the former is not | 18:31.52 |
| gegooo | no, I don't think this is a problem | 18:32.02 |
| henrys | well we will certainly integrate patches you provide. Do you have any wild PDF files that use the halftoning? | 18:33.43 |
| | we have a consultant working on jbig2 and he may be interested in looking at it also. We are less inclined to look at it without real world PDF examples. | 18:35.28 |
| | mvrhel_laptop:I assume scott is all geared up with mupdf on the ipad? | 18:36.42 |
| Robin_Watts | henrys: We set him up at the meeting, so he was good to go then. | 18:37.08 |
| mvrhel_laptop | I hope so. He did send me the presentation though so I have it on my laptop | 18:37.22 |
| Robin_Watts | He's been in contact with me since about putting the standard Artifex presentation powerpoint thing onto mupdf on his ipad too. | 18:37.40 |
| henrys | Robin_Watts:oh I didn't know it got completed at the meeting. | 18:37.44 |
| mvrhel_laptop | Robin_Watts: ok. that is what he sent me in case he can't get it to work on his ipad | 18:38.14 |
| Robin_Watts | mvrhel_laptop: Ah. He may arrive and ask you to put it on for him then :) | 18:38.29 |
| | mvrhel_laptop: Do you have iTunes on that laptop ? | 18:38.44 |
| mvrhel_laptop | no | 18:38.47 |
| | too many updates.... | 18:38.52 |
| | all the time | 18:39.00 |
| Robin_Watts | Ah. You'll need iTunes to be able to put the file on. | 18:39.01 |
| mvrhel_laptop | well we will just run the presentation from my machine then | 18:39.19 |
| Robin_Watts | ok. I do think it would be worth us getting it sorted for him at some point though. | 18:39.46 |
| mvrhel_laptop | yes | 18:39.51 |
| Robin_Watts | because if someone asks what he's using for the presentation, it'd be nice for him to be able to say "Oh, that's our other product..." :) | 18:40.21 |
| gegooo | henrys: *was looking* in a bunch of JBIG2 containing wikimedia PDFs ... no one found yet. | 18:40.40 |
| | with halftones | 18:40.54 |
| henrys | gegooo if you do find one let me know and we can create a bug at bugs.ghostscript.com | 18:41.27 |
| Robin_Watts | Bug 691230 has one. | 18:41.50 |
| henrys | oh | 18:42.18 |
| Robin_Watts | Do we have the ubc test suite? that has 2 more in supposedly (but they don't count as wild files :) ) | 18:42.41 |
| henrys | that's good enough for P2 bountiable anyway maybe shelly will have a look. | 18:44.37 |
| Robin_Watts | http://vark.mine.nu/cheezer.14 | 18:47.54 |
| henrys | I rarely use FF anymore, chrome mostly | 18:49.58 |
| Robin_Watts | Yeah, I've defected too. | 18:50.13 |
| | "I don't know if the blame is so easy to place. It is kind of like watching one fat guy explain to another why they can't sit on the same bench." | 18:50.43 |
| mvrhel_laptop | ok. miles is here. ttyl | 18:54.35 |
| henrys | chrisl:the sooner the better for dropping in the original urw fonts. | 18:58.43 |
| Robin_Watts | tor8: http://ghostscript.com/~robin/0001-Work-in-progress-rework-pdf_store.patch | 19:11.06 |
| | That's what I've got so far. Seems to work without any problems. | 19:11.26 |
| | Currently I'm not setting a top limit on the store size though. | 19:11.45 |
| | I'm thinking that the store should move to be part of the context, so the malloc stuff can scavenge from it as required. | 19:12.07 |
| Robin_Watts | pops to shop. back in 5 mins. | 19:12.16 |
| tor8 | the fz_drop_*_imp could be called fz_free_* but I like the _imp suffix so you don't call it by accident. | 19:17.00 |
| | did you forget fitz/base_store.c ? | 19:17.23 |
| Robin_Watts | Ahem. | 19:18.00 |
| | Look again now. | 19:18.11 |
| tor8 | and I agree that the fz_store should be part of the context eventually. but it can be created/destroyed inside the pdf_new_xref / free_xref calls since it's function pointer based and not hard linked. | 19:18.21 |
| Robin_Watts | (haven't left yet, relacing shoes) | 19:18.23 |
| tor8 | also: fz_keep/drop ... how about fz_keep_resource or fz_keep_storable? | 19:18.55 |
| Robin_Watts | Is there a green way to recycle old trainers? | 19:18.58 |
| | fz_keep_storable would be my preference. | 19:19.06 |
| tor8 | you also forgot the FZ_ prefix on the INIT_STORABLE macro :) | 19:19.47 |
| | could you s/rc/refs/ to please me? | 19:21.28 |
| Robin_Watts | sure. | 19:21.38 |
| tor8 | Robin_Watts: as you can see, I can only nitpick on the names which means I approve of the patch in general | 19:21.44 |
| Robin_Watts | :) | 19:22.05 |
| | ok, really off now. will do those tweaks when I get back. | 19:22.16 |
| chrisl | henrys: I'll do the font switch over tomorrow - I want to double check the file names before committing them | 19:28.03 |
| henrys | thanks | 19:28.41 |
| Robin_Watts | tor8: Part of the reason I want the store to be in the context, is so it can be inited with the context. | 19:30.54 |
| | which seems the most reasonable place to be setting a "max" amount of memory. | 19:31.16 |
| tor8 | Robin_Watts: yeah. I also think the context is the right place for it. | 19:33.41 |
| Robin_Watts | tor8: If I move to using fz_free_*_imp, rather than fz_drop_*_imp, I should rename all the 'drop' things to be 'free' things. | 19:49.56 |
| tor8 | I call things that have reference counting drop, and things that don't free | 19:51.18 |
| | helps me not confuse what is refcounted and what is not | 19:51.40 |
| Robin_Watts | tor8: Right, so I'm not proposing changing fz_drop_colorspace etc. | 20:10.38 |
| | I'm saying that the 'drop' function provided to fz_store should be a 'free' function. | 20:10.55 |
| tor8 | oh, right! | 20:37.26 |
| | Robin_Watts: ^ | 20:37.31 |
| Robin_Watts | New patch up with those changes. | 20:38.19 |
| | Going to move store into context now. | 20:38.26 |
| | Hmm. I can't email to gs-devel@ghostscript.com | 21:53.02 |
| | I'm told there is no such mailbox. | 21:53.12 |
| | chrisl: It's not a bug. | 21:56.30 |
| | w.r.t beebes email. | 21:56.43 |
| | The code in question is protected by #ifdef HAVE_SSE2, and he's passing -DHAVE_SSE2 to the compiler, hence he gets what he asked for. | 21:57.17 |
| | If the autogen stuff is incorrectly setting HAVE_SSE2 that's a bug. | 21:57.28 |
| | But I suspect he's abusing it and not autogenning with the same compiler. | 21:57.50 |
| | so he deserves what he gets. | 21:57.59 |
| chrisl | Robin_Watts: it's not protected by HAVE_SSE2, perhaps it should be | 22:03.51 |
| Robin_Watts | is too. | 22:03.59 |
| | Line 130, of gx_thresh.c ? | 22:04.49 |
| chrisl | Line 288 | 22:05.07 |
| | gxht_thresh.c | 22:05.27 |
| Robin_Watts | That's a warning. | 22:05.31 |
| | The error is on line 130 | 22:05.36 |
| chrisl | Oh, right, wrong thing! Too late for me! | 22:06.07 |
| Robin_Watts | Still can't get mail to send. Oh well. | 22:07.16 |
| chrisl | Sorry, I wanted Nelson to report stuff to bugzilla - sending it to gs-devel is b*gger all use these days | 22:07.46 |
| | I think that makes it clear I'm too tired to be useful - I'm going to bed...... | 22:09.23 |
| | Forward 1 day (to 2011/12/15)>>> | |
IRC Logs