| | <<<Back 1 day (to 2012/11/29) | 2012/11/30 |
| chrisl | kens: did you get what needed about that truetype font yesterday? | 09:02.50 |
| kens | chrisl, I'mstill looking into it | 09:03.00 |
| | Been diverted to look at XML and Doc Info | 09:03.12 |
| | ANd the horrendous code Igor wrote for it | 09:03.22 |
| chrisl | It looks like length of loca > num glyphs is okay, but length of loca < num glyphs is ng | 09:03.49 |
| kens | As I said there's a specific check in the code which is supposed ot make sure of that, but I haven't been back into it ti check why its not working | 09:04.38 |
| | Its on my todo list for the day, but the UTF encoding is looking like being rather more of a worms nest than I expected | 09:05.13 |
| chrisl | That's fine, I only mention it because, parenthetically, I just stumbled across a crash with "that other font library"(tm) which is related to the loca table being too long. | 09:06.09 |
| kens | Huh, interesting :-) | 09:06.23 |
| | When I fix whatever the problem is the loca length should be correct, so at least we won't have that problem | 09:06.45 |
| chrisl | In this case I was bemused because in gs the crash happened in a totally different place to their demo app with this font. Then I remembered, we fix such loca tables at interpretation time. The crash in gs was in the TTF hinting in "that other lib" | 09:10.27 |
| kens | So even though the loca table was fixed it still crashed ? :-O | 09:10.55 |
| chrisl | Yeh, but the blame is really with the font. The bytecode references contour point index (something like) 1834750000..... | 09:12.26 |
| kens | OMG! | 09:12.36 |
| | Sounds like a totally broken font, I hope it wasn't produced by pdfwrite | 09:12.52 |
| chrisl | I doubt it - I can check in a while (running tests just now). Amazingly, for once, the "obvious" solution worked - tell it to do TTF error checking, and we get a sensible "point out of bounds" error :-) | 09:14.31 |
| kens | :-) | 09:14.43 |
| | chrisl fancy a new car : | 09:16.23 |
| | http://uk.reuters.com/article/2012/11/30/us-batmobile-auction-idUKBRE8AT05220121130 | 09:16.24 |
| chrisl | kens: don't you think I have enough trouble with the two I already have??? Besides, I'd rather have the Tim Burton Batmobile.... | 09:18.20 |
| kens | :-) | 09:18.28 |
| | I'd rather have the DB5 they mention at the end | 09:18.47 |
| | But 4.6 million is a bit out of my league ;-) | 09:18.58 |
| chrisl | Well, if I also get my hands on "Clark Gable's personal 1955 Mercedes-Benz 300SL Gullwing Coupe" we can recreate the car chase from the Goldfinger book ;-) | 09:19.57 |
| kens | Hmm was that a Mercedes ? | 09:20.28 |
| | Its been a very long tims ince I read that one | 09:20.42 |
| chrisl | I *think*, in the book, the car chase from London to the coast was a Mercedes 300SL vs Bond's Bentley "special". I don't think it was a 300SL Gullwing, though..... | 09:22.03 |
| kens | Oh yeah that's right, Fleming wrote a Bentley as Bond's car, I'd forgotten that | 09:22.39 |
| chrisl | Or, actually, maybe that was Thunderball - it's a while since I read them, too! | 09:22.59 |
| kens | Hmm, OK I see what Igor was up to now, but he was focused on PostScript intput, and missed an important case in PDF input (or pdfmark). | 09:37.20 |
| chrisl | I guess that is understandable - at the time, I suppose, only Postscript input was really supported..... | 09:39.01 |
| kens | No, I think PDF input was allowed too, and he totally missed the DOCINFO pdfmark | 09:39.47 |
| | From my POV I am going to have to create a PDFDocEncoding to UTF-16 lookup table. | 09:40.20 |
| chrisl | Ugh :-( | 09:41.32 |
| kens | There's no alternative, there's no sensible relationship. OTOH I only have to worry about values > 0x7f | 09:42.09 |
| Robin_Watts | tor8: ping | 11:25.48 |
| tor8 | Robin_Watts: pong. | 11:26.19 |
| Robin_Watts | So, these patches. | 11:26.32 |
| | want to highlight the areas you're unhappy with? | 11:26.40 |
| | I'll change the fz_buffer abuse to be a more explicit dynamically allocated int array. | 11:27.33 |
| tor8 | Robin_Watts: why not just a linked list of pointers stored on the stack? | 11:28.11 |
| | Robin_Watts: unhappy with the signed/unsigned int casting | 11:28.20 |
| Robin_Watts | tor8: Linked list of pointers might lead to stack overflow ? | 11:28.36 |
| tor8 | Robin_Watts: how so? | 11:29.01 |
| | Robin_Watts: not any more than recursion would otherwise do | 11:29.11 |
| | Robin_Watts: or you might not understand what I mean...? | 11:29.38 |
| Robin_Watts | tor8: I understand what you mean. | 11:29.53 |
| | the problem is it's not 1 pointer per call to the function. | 11:30.02 |
| | There is a while in the function. | 11:30.36 |
| | so there are n per function. | 11:30.44 |
| | hence allocating on the stack is hard. | 11:30.59 |
| tor8 | Robin_Watts: oh, right. you already un-recursed the function. | 11:32.28 |
| | I wonder if not putting the recursion back might be sensible given that we now stop infinite recursion | 11:32.48 |
| Robin_Watts | Hmm. I much prefer it without the recursion. | 11:39.40 |
| tor8 | Robin_Watts: alright. at least let's do it without fz_buffer then. | 11:39.58 |
| Robin_Watts | dong it without fz_buffer is certainly possible. I'll do that. | 11:40.11 |
| tor8 | agh. sometimes I just want to make and use macros for dynamically grown arrays. | 11:40.14 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=70e18ba1458ed62f46a5da879a889b776b4deb38 | 11:40.25 |
| | So, I'm happy with the LZW changes. | 11:40.35 |
| | The skip_input_data in the jpeg code is "safer". | 11:41.14 |
| | Though if we tell it to skip 1000 bytes and it only has 80, then we'll actually only skip 80. Not sure that ever happens though. | 11:41.41 |
| tor8 | Robin_Watts: pdf_* hunks LGTM, still reviewing the fitz ones | 11:41.58 |
| Robin_Watts | I think the error handling in fz_load_jpeg is an improvement. | 11:42.05 |
| tor8 | LZW is fine | 11:42.07 |
| | + if ((size_t)num_bytes > src->bytes_in_buffer) | 11:42.14 |
| | + num_bytes = (long)src->bytes_in_buffer; | 11:42.15 |
| | worries me | 11:42.16 |
| Robin_Watts | (but then I would. cos I rewrote zenikos patch) | 11:42.35 |
| tor8 | as long as the error handling passes all tests, I don't have an opinion. It's certainly been fragile enough in the past. | 11:42.58 |
| | don't like the casts in the png, that should be fixed properly | 11:43.21 |
| | tiff looks fine | 11:43.28 |
| | Robin_Watts: oh, but this jpeg is the whole-image-at-a-time version. the error handling in the stream based one was the one with lots of subtle bugs. | 11:45.12 |
| Robin_Watts | The cmap changes produce lots of warnings, and having looked at the cmap files, there do indeed appear to be code ranges outside the 0...65535 range. | 11:46.12 |
| tor8 | Robin_Watts: right. so the jpeg skip_input_data ... we should never hit that if unless there's a bug in libjpeg | 11:46.55 |
| Robin_Watts | tor8: We are never asked to skip more bytes than we have in our buffer? | 11:47.21 |
| tor8 | nope, because we always have the complete file in our buffer | 11:47.40 |
| Robin_Watts | http://bugs.ghostscript.com/attachment.cgi?id=9098 | 11:48.03 |
| tor8 | see filt_dctd.c for comparison, where we have a while loop to read more data if we're asked to skip more than we have | 11:48.16 |
| Robin_Watts | That's the original patch from zeniko. I wonder if I cocked up... | 11:48.28 |
| | I changed his patch to be simpler. | 11:48.33 |
| | yeah, I think he's trying to cope with 32/64bit ness. | 11:49.21 |
| tor8 | Robin_Watts: I wonder if he has a test case for this or is going by MSVC signed/unsigned warnings | 11:49.24 |
| | and libjpeg stupidity by having 'long' in the api | 11:49.37 |
| | right, so anyway, it's fine but the (long) cast is useless and should go | 11:50.40 |
| Robin_Watts | Maybe we should do: size_t skip = (size_t)long; if (skip > 0 && skip > src->bytes_in_buffer) skip = src->bytes_in_buffer; then work with size_t. | 11:51.15 |
| | The idea being that size_t can be 64bit. | 11:51.32 |
| | and long might be 32. | 11:51.58 |
| tor8 | long is 64-bit on 64-bit windows innit? and size_t is 32. | 11:52.00 |
| Robin_Watts | No, long is 32 on windows always. | 11:52.14 |
| | size_t is related to ptrdiff_t isn't it? So 64 bit? | 11:52.32 |
| tor8 | Robin_Watts: right. then what you said. | 11:53.01 |
| Robin_Watts | OK. So I cocked his patch up. I'll make a better version. | 11:53.17 |
| tor8 | bytes_in_buffer is size_t so we should convert num_bytes to size_t and then just use that | 11:53.41 |
| | so yeah, size_t skip = num_bytes; ... what you have in your patch without the casts | 11:54.02 |
| Robin_Watts | So... that should just leave the png stuff. | 11:54.21 |
| tor8 | Robin_Watts: could you split the png stuff to a separate commit? | 11:54.50 |
| Robin_Watts | Will do. | 11:54.56 |
| tor8 | back to the cmap stuff before I forget | 11:55.07 |
| | the input cmap data has mappings > 65535, but we prune those out during parsing (and conversion) | 11:55.29 |
| Robin_Watts | Having run this code yesterday, I can tell you that that function is definitely called with low = 8ea1a1a1 etc. | 11:56.05 |
| tor8 | I have (had somewhere) a patch to make use of them (they're all surrogate pairs) but it's kind of pointless since none of our fonts have any of those glyphs | 11:56.13 |
| Robin_Watts | I have to confess to being completely lost as to the cmap stuff :) | 11:56.47 |
| tor8 | hm, that's odd. can you toss me the file? | 11:57.13 |
| Robin_Watts | which file? | 11:57.27 |
| tor8 | does it happen on the CMap resources we compile? | 11:57.30 |
| Robin_Watts | yes. | 11:57.33 |
| tor8 | or a PDF file in the wild? | 11:57.41 |
| Robin_Watts | The ones we compile. | 11:57.47 |
| tor8 | oh. rats. let me investigate that one, so take that out of the commit as well | 11:57.53 |
| Robin_Watts | OK. | 11:57.58 |
| | I'll leave the pdf_cmap_parse stuff in, and remove the pdf_cmap.c stuff ? | 12:01.24 |
| | tor8: OK, separated versions pushed to my repo. | 12:06.58 |
| tor8 | Robin_Watts: right you are. cmaps/japan/Hojo-EUC-H has input ranges far outside the 16-bit limits | 12:10.42 |
| | Robin_Watts: shall we take this opportunity to bloat the cmap data by using ints instead of unsigned shorts, and get support for surrogate pairs? | 12:11.23 |
| | (or throw out the cmaps that have these ranges, and hope no-one uses them) | 12:11.50 |
| Robin_Watts | tor8: I'd be reluctant to bloat the data personally. | 12:12.11 |
| | I'm sure there must be a smarter approach. | 12:12.24 |
| | Hmm. Possibly we should just split each cmap into 2; the current table (with everything packed nicely into 64bits) and a 'long' table with stuff packed into 4 ints instead. | 12:16.17 |
| | That keeps the overall compactness (cos 99% of the stuff fits into the nice table) and gets us the outliers fairly simply. What do you think? | 12:16.59 |
| tor8 | http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commitdiff;h=514f248296d8769247d8bcda2901931299c639be;hp=6c0e38f0e19ef50a7951f082981fabd49f4bee9f | 12:17.05 |
| | yeah, that's probably worth doing | 12:17.15 |
| | that commit gets the basics, but bloats precompiled data by about 500K | 12:17.30 |
| Robin_Watts | ouch. | 12:17.46 |
| tor8 | yeah. ouch. | 12:17.51 |
| | depending on how many values there are >64K limit, we could probably get away with a simple 4+4 byte sorted lookup table | 12:19.05 |
| | (none of the range stuff) | 12:19.14 |
| Robin_Watts | Ah, true. | 12:19.21 |
| | Are there pathological cmaps out there? | 12:19.31 |
| tor8 | I doubt it | 12:19.39 |
| | not that'd use those ranges anyway | 12:19.46 |
| | because we need to support input and output values > 64k | 12:20.09 |
| Robin_Watts | Maybe modify the code to print how many entries there are in the top ranges, then do a clean rebuild? | 12:20.27 |
| tor8 | input for the samples listed here, and output for the ToUnicode maps | 12:20.30 |
| | so anything that exceeds those gets punted to a big fat list that is sorted and appended, and searched first or last | 12:21.55 |
| Robin_Watts | searched last, I'd guess. | 12:22.15 |
| tor8 | probably, yes. I'm sure the current code will split a range if a value ends up missing | 12:22.31 |
| | the cmap range "optimiser" is a bit funky | 12:22.47 |
| | but care can be taken that we can search it last anyway | 12:23.05 |
| Robin_Watts | From what I saw yesterday, there were lots of 255 sized ranges being inserted in the stratospheric regions. | 12:23.20 |
| | So I'd worry that without the range stuff, the list might end up larger than we'd like. | 12:23.45 |
| | hence my suggestion for the quick test. | 12:24.11 |
| tor8 | Robin_Watts: depends, if it's not a contiguous range... | 12:24.17 |
| | but yeah, we should examine the data better. let me rig that up. | 12:24.30 |
| | Robin_Watts: results are in: there's a *ton* of table entries that have output mappings > 64k in the ToUnicode maps | 12:29.50 |
| | and only one that has stratospheric range mappings, Hojo-EUC-H | 12:30.07 |
| | agh. my bad. forgot to test negative ints... | 12:32.51 |
| | Robin_Watts: okay, so a lot of 94 entry ranges | 12:35.19 |
| | Robin_Watts: so the extra table would have to be 12 bytes, not 8 | 12:37.50 |
| | (might be getting slightly off results here, due to how I already split things into range and table lookups separately) | 12:38.30 |
| Robin_Watts | I guess the question is, what would give us least memory used/fastest searching. | 12:38.36 |
| | Do we have a simple 'dumb' list of codes, or do we just duplicate the existing range stuff up to 32bits. | 12:39.05 |
| | My instinct would be that the latter is faster/smaller, but I'm prepared to be wrong. | 12:39.31 |
| tor8 | Robin_Watts: the UCS2 mappings have one-to-many mappings | 12:42.24 |
| | that's the bit that makes things complicated | 12:42.37 |
| | of course, I doubt much of our other code actually handles that case | 12:42.52 |
| Robin_Watts | tor8: There is an argument that says if we don't support it, then remove it from the tables at parse time. | 12:44.35 |
| tor8 | Robin_Watts: right, so we do. nvm. | 12:44.35 |
| Robin_Watts | Oh, we do handle it? Better. | 12:44.51 |
| tor8 | for tounicode text extraction, we save the many-to-one mappings in the fz_text struct | 12:44.52 |
| | Robin_Watts: we might be able to strip down the sizes if we have multiple separate searches instead of baking them all into one | 12:46.00 |
| | well, probably not. | 12:46.20 |
| | (we could get rid of the flags entry is all) | 12:46.45 |
| Robin_Watts | My memory was that the current table was fairly well packed... | 12:46.54 |
| | the flags are just 2 bits of one of the fields. | 12:47.03 |
| tor8 | yeah, exactly, so not much gained there | 12:47.13 |
| Robin_Watts | so the cost for that is any 2<<16 byte wide ranges get split to be 4 2<<14 byte ranges. Not sure there are enough of them to worry about. | 12:47.49 |
| tor8 | Robin_Watts: so, there are 11 one-to-many mappings that have 32-bit values | 12:49.43 |
| | so we can't reasonably skip one-to-many for the 32-bit case | 12:49.56 |
| | Robin_Watts: those splits never happen on our input data | 12:51.04 |
| | so that code may very well be completely untested :) | 12:51.31 |
| Robin_Watts | best kind :) | 12:53.10 |
| tor8 | the offset field can stay 16-bit | 12:53.58 |
| kens | chrisl is KozukaB-ILEmbed.pdf a new test file do you know ? | 12:55.11 |
| chrisl | kens: Not that I'm aware of | 12:55.36 |
| tor8 | Robin_Watts: so we can get away with having only the table lookup be ints | 12:55.39 |
| kens | Hmm, odd. | 12:55.42 |
| Robin_Watts | tor8: right. | 12:56.03 |
| | tor8: patches updated. cluster test running. gotta pop to the post office. back in 10 mins. | 12:56.30 |
| tor8 | Robin_Watts: with another bit in the extent_flags, we can extend the enum to PDF_CMAP_TABLE32 | 12:56.32 |
| chrisl | kens: I have it here, so it's defintely not been added in the last 3 weeks or so | 12:56.43 |
| Robin_Watts | so 3 bits rather than 4 ? | 12:56.51 |
| kens | Hmm, its giving me errors, and I really can't think that my code has changed it. | 12:57.06 |
| tor8 | Robin_Watts: 3 bits rather than 2, leaving 13 bits for the extent | 12:57.18 |
| chrisl | kens: is this the XML stuff? | 12:57.39 |
| kens | Yes, I changed the code, and that is the only file that looks dubious | 12:57.59 |
| | Given that GS doesn't even read the XML I can't think why it would be a problem | 12:58.18 |
| chrisl | Are the differences just with pdfwrite, or do they happen with raster output, too? | 12:58.53 |
| Robin_Watts | tor8: nice. | 12:59.06 |
| kens | its 'errors' and only with the pdfwrite produced PDF file | 12:59.11 |
| | I guess I'm going to have to look at it :-( | 12:59.35 |
| | I think I'll stash my changes and see what a cleaqn build does | 13:00.23 |
| chrisl | It may have some multibyte encoded stuff in there - the author field seems to be gibberish..... | 13:00.42 |
| tor8 | Robin_Watts: hm, I need to think more about this. the input ranges still need to support astronomic values for some | 13:02.41 |
| Robin_Watts | tor8: tests passed. So I reckon these ones are ready to go... | 13:29.55 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=a6b0a8273f2eb15fd5924501b6ad03e30f2c8d0a | 13:30.07 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=5c5a13b31da451e47fe2df48aacf1d00377aaf64 | 13:30.19 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=980e2932579e3ede636297b49baf12ad1bc8b2a7 | 13:30.35 |
| kens | chrisl Hmm, well it should work OK< the odd ting is that GS fails with it, because we *ignore* the XML | 13:31.51 |
| chrisl | kens: huh? It worked when I tried it...... | 13:32.30 |
| kens | failed on cluster :-( | 13:32.40 |
| chrisl | With the master code? | 13:33.43 |
| kens | wwwwclean results coming in | 13:33.43 |
| | waiting for email | 13:33.53 |
| | clean build is OK, guess I have some more work | 13:36.55 |
| Robin_Watts | tor8: And number 4: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=62320204bf806686dd07d27d8110670914a874ca | 13:50.28 |
| tor8 | Robin_Watts: gbot is that for xobject streams so they don't break the parent stream? | 13:50.56 |
| Robin_Watts | Yes. | 13:51.01 |
| tor8 | right. LGTM the batch. | 13:51.37 |
| Robin_Watts | Zenikos patch insisted that xobjects could never pop further than they should. | 13:51.41 |
| tor8 | yeah. that makes sense. | 13:51.49 |
| Robin_Watts | My patch is a slight modification where I insist that we always pop exactly the right amount. | 13:51.59 |
| | tor8: Thanks. | 13:52.03 |
| tor8 | I'll mull over the cmap this weekend and come up with a better solution hopefully. | 13:52.05 |
| Robin_Watts | ok, so that just leaves the png stuff. | 13:52.38 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=6fd61fdce3d7fc713555ee9d6b503401a8cdc1f3 | 13:52.56 |
| tor8 | I think I'll try an approach that has 3 separate lookup tables, for one-to-one, range-to-range and one-to-many cases | 13:52.57 |
| | Robin_Watts: int everywhere, or unsigned int everywhere, IMO. for the PNG patch. | 13:53.46 |
| | is it because 'total' coming in is an int that he casts everything? | 13:54.40 |
| Robin_Watts | I think so. | 13:55.08 |
| | png_read_ihdr expects size to be an int. | 13:56.27 |
| | And in fact all the png_read_ things. | 13:57.18 |
| tor8 | I'm thinking that "int size" in the struct must be an error | 13:57.23 |
| | and also the data size arguments | 13:58.28 |
| Robin_Watts | I fear we should: unsigned int usize = getuint(p); Then check that for overflow before putting that down into an int size. | 13:58.44 |
| | I doubt we're going to get it down to fewer casts than he has there :( | 13:58.58 |
| | The casts are all, (as far as I can tell) to square the fact that size is read as a uint, and used as an int. | 14:00.04 |
| tor8 | well, I'm happy to change all the uses to unsigned | 14:00.35 |
| Robin_Watts | The PNG lib's interface is fixed, so we're stuck with an int there. And we are pretty much stuck reading a uint. | 14:00.38 |
| tor8 | Robin_Watts: we don't use libpng | 14:00.49 |
| Robin_Watts | Oh! It's us. | 14:00.57 |
| | Sorry. | 14:01.01 |
| tor8 | It's all us :) | 14:01.05 |
| Robin_Watts | Right, well, I'll try pushing uint's through all the way after lunch then. | 14:01.15 |
| tor8 | I didn't want to drag in yet another third party library dependency :) | 14:01.16 |
| | and especially not one with as crufty code and API as libpng | 14:01.36 |
| Robin_Watts | ok, lunchtime. bbs. thanks. | 14:01.40 |
| tor8 | Robin_Watts: I'll be AFK most of the rest of the day, but I will check in occasionally. feel free to drop me an sms if you have any urgent questions. | 14:02.26 |
| kens | chrisl I see the Unicode problem now, it seems that there was a bug in the original code that's never been triggered (presumably because nobody uses UTF-16 in docinfo) | 14:58.06 |
| | THe code assumes that a UTF-16 -> UTF-8 conversion will occupy no more bytes than the original UTF-16, which is false, it cna occupy up to 2 times that. | 14:58.39 |
| chrisl | Ooops! | 15:01.28 |
| kens | well thre's overrun protection in the conversion code, but we weren't handling the error very well either | 15:01.59 |
| mvrhel_laptop | henrys_mac are you there? | 15:12.36 |
| henrys_mac | I am | 15:12.53 |
| mvrhel_laptop | did you see the email from Stefan? | 15:13.11 |
| henrys_mac | yes I would point him to the snapshot link on git.ghostscript.com | 15:13.31 |
| mvrhel_laptop | ok. I am very flustered with this. | 15:14.09 |
| henrys_mac | respond and tell him that and copy in Marcos who'll take it from there if that doesn't work for him. | 15:14.31 |
| mvrhel_laptop | ok | 15:15.07 |
| henrys_mac | marcosw has excellent code delivery kung fu | 15:15.43 |
| mvrhel_laptop | yes | 15:15.47 |
| chrisl | henrys_mac: do you think there is any problem moving our customers that use "that other font library" to version 6.2 for the next release? Or do you think I should get the 5.x code working, too? | 15:16.28 |
| henrys_mac | 6.2 is fine are you sure it works though - I didn't see a commit for our line printer customization in the third party code. | 15:17.32 |
| | but I might have missed it | 15:17.40 |
| mvrhel_laptop | so the snapshot link to the far right of the commit is the entire tree tar.gz henrys? | 15:17.51 |
| henrys_mac | mvrhel_laptop: why not? | 15:18.16 |
| mvrhel_laptop | just checking | 15:18.22 |
| | it seems to be. | 15:18.28 |
| | I have never used the link | 15:18.31 |
| chrisl | henrys_mac: I *believe* I ported all the Artifex changes from the 5.x code tree, but I could be wrong. Do we have a file which tests that? | 15:19.07 |
| henrys_mac | well the line printer font wouldn't work which would break lots of stuff - did you do a bit compare? | 15:20.12 |
| | 6.2 vs 5.x | 15:20.43 |
| | ? | 15:20.46 |
| chrisl | No I couldn't get the 5.x code to work, and I didn't feel like spending a lot of time working out why when I was about to replace it all. | 15:21.31 |
| henrys_mac | I've switched to Colloquy for IRC if it does something obnoxious let me know. | 15:21.33 |
| | chrisl: that really is a problem. We can't upgrade without a compare. | 15:22.40 |
| kens | Well chrisl compared 6.2 (non FAPI) with 6.2 (FAPI) I assume ? | 15:23.19 |
| henrys_mac | chrisl: norbert won't like that ;-( | 15:23.21 |
| chrisl | How sure are we that the 5.x code was right? | 15:23.32 |
| kens | Presumably osmeone has previously done a 5 vs 6.2 comparison ? | 15:23.40 |
| | Or have we never shipped 6.2 to a customer ? | 15:23.51 |
| henrys_mac | norbert ships with it. | 15:24.08 |
| chrisl | kens: only on PS/PDF - 6.2 I never tried with PCL/PXL | 15:24.09 |
| kens | Do we have *any* comparison with 6.2 and PCL ? | 15:24.49 |
| chrisl | 6.2 vs AFS vs FT | 15:25.19 |
| kens | Or are we currently shipping different versions to customers and hoping they worj teh same ? | 15:25.19 |
| henrys_mac | a fuzzy against free type is fine. But we have to do some QA right? | 15:25.19 |
| kens | Sorry I meant comparison of 6.2 and 5.x | 15:26.11 |
| chrisl | No, no 6.2 vs 5.x with PCL | 15:26.38 |
| kens | I guess we never shipped anything except 5 then | 15:26.58 |
| chrisl | No, never | 15:27.08 |
| kens | OK that makes more sense | 15:27.14 |
| mvrhel_laptop | email sent henrys_mac but I had to bite my tounge | 15:27.56 |
| | ok. bbiab have to get kids out the door | 15:28.08 |
| chrisl | henrys_mac: plulp.c is in the 6.2 tree, and gets picked up by the pcl build. | 15:28.08 |
| henrys_mac | chrisl:okay, what about a fuzzy agains ads? possible? | 15:28.37 |
| chrisl | henrys_mac: ads? | 15:29.02 |
| norbertj | hello henrys_mac | 15:29.02 |
| henrys_mac | ah he was listening in. | 15:29.09 |
| kens | afs maybe ? | 15:29.12 |
| | which chrisl has done I think | 15:29.29 |
| norbertj | just noticed your conversation. We still ship with 5.x (if you mean the fontrasterizer). | 15:29.34 |
| henrys_mac | norbertj:we are going to update to 6.x and are working on a test plan. | 15:30.26 |
| norbertj | I also just filed abug 693478, it's from a customer. | 15:31.07 |
| | a downloadfont (OCRB) not being selected. | 15:31.35 |
| chrisl | henrys_mac: I'll have another stab at getting the "old skool" 5.x code to build so I can do a comparison | 15:31.42 |
| henrys_mac | chrisl:seems right. | 15:32.02 |
| | norbertj:I just made a font selection change not more than a few minutes ago. | 15:32.42 |
| | norbertj:unfortunately it does not address your new problem. | 15:36.47 |
| norbertj | henrys_mac: You seem to be Lucky Luke (comic figure in Europe, who shoots faster than his shadow). | 15:38.22 |
| | you can cancel my bug, it is solved with this fix. ;) | 15:38.33 |
| henrys_mac | norbertj:nope it is still broken. If the font is unbound the scoring is correct for symbol must be something else. | 15:39.24 |
| norbertj | henrys_mac: perhaps in the check_support(), it sets the score[score_symbol_set] not correct I think. | 15:42.06 |
| henrys_mac | norbertj:when chrisl integrates the ufst 6 stuff will you be able to run it through your regression tests - it would be good to know about any problems early? | 15:42.13 |
| norbertj | Will have to check with Marten if we have an UFST 6.0 here. | 15:42.56 |
| henrys_mac | norbertj:I'll have a look. What a mess I imagine family selection was the first thing axed when they did PCLXL | 15:43.12 |
| norbertj | If we have, I'll be happy to test. | 15:43.21 |
| henrys_mac | norbertj:great | 15:43.36 |
| | wow I was looking at some of these prices ⦠visual studio ultimate is crazy expensive. | 15:49.49 |
| Robin_Watts | henrys_mac: Yeah. Bonkers isn't it? | 15:50.09 |
| norbertj | going home. | 15:51.07 |
| henrys_mac | I was reading about some interesting agile programming stuff they have built in for testing and wanted to give it a go, but I'm not paying that much⦠nuts | 15:51.37 |
| Robin_Watts | Why not make do with 2010 edition. A snip at... 18000UKP... http://www.amazon.co.uk/Microsoft-Visual-Studio-2010-Ultimate/dp/B0038KNER0/ref=sr_1_14?ie=UTF8&qid=1354290654&sr=8-14 | 15:51.56 |
| henrys_mac | I mention norbert on irc and he reports a bug, I'll have to stop doing that. | 15:53.09 |
| | humph I'm having a problem with the current snapshot, maybe a mac problem:tar: copyfile unpack (ghostpdl-bb97932/gs/lcms2/Projects/mac/LittleCMS/.DS_Store) failed: File exists | 16:06.55 |
| Robin_Watts | Why is .DS_Store checked in? | 16:11.30 |
| | oh, might have been part of the original lcms stuff. | 16:13.04 |
| | henrys_mac: You're downloading a snapshot from the web? | 16:13.32 |
| | Is that file in the snapshot twice or something ? | 16:13.41 |
| henrys_mac | yes, it could also be a mac bug creating the .DS_Store when creating the directory then revisit ing the dir. Let me check. | 16:14.19 |
| | have to download again because I've already uncompressed it. | 16:15.07 |
| Robin_Watts | So that dir contains .DS_Store and ._.DS_Store | 16:16.15 |
| | How are you decompressing? | 16:17.31 |
| | tar -zxvf snapshot.tgz ? | 16:17.45 |
| | or some gui thing ? | 16:17.52 |
| henrys_mac | I'm using tar - those files should be removed. | 16:18.23 |
| | bbiab | 16:19.30 |
| Robin_Watts | So, we have a bug with MuPDF where part of a PDF is appearing too faint. It looks like an image rotated by about 10 degrees is coming out too faintly. | 16:19.39 |
| | It turns out that each line in the image is a separate image, which is plotted separately. | 16:20.02 |
| | That doesn't present MuPDF a problem. | 16:20.08 |
| | What causes the problem is that each one of these lines is contained in a clipping path. | 16:20.34 |
| | MuPDF renders the clipping paths as as greyscale masks, and then clips the images through that. | 16:21.11 |
| | because the paths are thing, the masks end up as being lots of grey pixels, and so the image comes out faint. | 16:21.37 |
| henrys_mac | Robin_Watts: can you remove those files or should we report it upstream? Can't unpack the code seems like a serious problem. | 17:03.04 |
| Robin_Watts | henrys_mac: We could certainly remove those files from our distribution. | 17:03.35 |
| | henrys_cat: Done. | 17:09.45 |
| kens | henrys_cat ? | 17:33.15 |
| Robin_Watts | 80s kids TV show. http://www.youtube.com/watch?v=-hI1thHw4OU | 17:34.27 |
| kens | I remember it, I was just wondering if it was what you meant..... | 17:34.46 |
| henrys_mac | I should make it my official IRC moniker | 17:55.03 |
| TylerE | What changed color-wise between 8.x and 9.x? I'm converting CMYK pdfs to RGB jpeg, and on a linux machine with 8.7 the colors are correct, but on an os x machine with 9.06 colors are too dark and over-saturated. Exact same command line on both machines | 18:56.40 |
| saper | tylerE: there is (some) support for color profiles now afair | 19:06.13 |
| TylerE | saper: That's great in theory | 19:09.55 |
| | but it appears the old method did exactly what I wanted ;( | 19:10.03 |
| | and the defaults are now different | 19:10.08 |
| kens | TylerE in the long term you need to investigate ICC profiles, and select appropriate profiles for your conversion. THis is why the change was made, the colour management is *much* more flexible and fits in with professional workflows | 19:34.08 |
| | In the short ter, tytr -dUseFastCOlor | 19:34.19 |
| | D'oh klet me retype that | 19:34.28 |
| | In the short term, try -dUseFastColor | 19:34.41 |
| TylerE | thanks lemme try that | 19:35.47 |
| | ok so this is interesting | 19:37.02 |
| | I rand it with that | 19:37.05 |
| | and the colors areâ¦.exactly the same | 19:37.13 |
| | let me imgur one | 19:37.26 |
| kens | Was that 'are' or 'aren''t', and the same as what ? | 19:37.52 |
| | afk for a few minutes | 19:38.42 |
| TylerE | so here's what it should look like: | 19:40.42 |
| | http://bit.ly/GCneP4 | 19:40.43 |
| | and here's what I'm getting out of ghostscript 9 | 19:40.51 |
| | http://imgur.com/pRrPI | 19:40.55 |
| kens | WHich version exactly are you using ? | 19:48.21 |
| | and is that with -dUseFastColor ? | 19:48.36 |
| | OK I'mm away for the next 90 minutes or so, I'll read the logs when I get back | 20:00.59 |
| ajp | looking for some pointers. I'm running gs pdfwrite to reduce PDF file sizes but when I do I lose the last %25 of and PDF I touch with the script | 20:08.07 |
| | anyone seen this before? | 20:08.18 |
| | any* | 20:08.30 |
| | any gs pros in here I can ask a Q? | 20:11.23 |
| | nufin? | 20:23.52 |
| | So I have this script i'm trying to get workinghttp://pastebin.com/aWQ2WB9v | 20:38.46 |
| | and it won't output PDFs correctly | 20:39.25 |
| | hi | 20:45.17 |
| mvrhel_laptop | TylerE did you get your color issue resolved? | 20:48.56 |
| ajp | I'm trying to get GS to reduce my PDF size but I'm getting bad output files (%25 of it is blank white)check out my script: http://pastebin.com/aWQ2WB9v | 20:51.28 |
| | if you dont mind helping me :D | 20:51.46 |
| TylerE | mvrhel: no luck so far | 20:53.03 |
| ajp | mvrhel_laptop TylerE: either of you know the pdfwrite function? | 20:53.33 |
| mvrhel_laptop | TylerE: what is the command line you are running? | 21:09.41 |
| | and this is 9.06? | 21:09.46 |
| ajp | bash 10.04 | 21:11.21 |
| | er ubuntu 10.04 | 21:11.37 |
| | bash shell | 21:11.42 |
| mvrhel_laptop | ajp: that question was for Tyler E | 21:14.22 |
| | ajp to do pdfwrite use -sDEVICE=pdfwrite | 21:14.42 |
| | in the command line | 21:14.48 |
| | bbiab | 21:17.31 |
| ajp | Oh. You can see my script in the link above; I am using -sDEVICE=pdfwrite but my output PDF file is missing parts | 21:21.12 |
| mvrhel_laptop | ajp: if you believe the rendering is wrong, then open a bug at bugs.ghostscript.com attach the file and included the command line | 21:49.26 |
| ray_laptop | hi, scott-san | 22:44.56 |
| scott-san | Hi Ray | 22:46.32 |
| ray_laptop | yay. Scott! | 22:46.44 |
| scott-san | Robin_Watts: Are you there? | 22:47.23 |
| | Forward 1 day (to 2012/12/01)>>> | |
IRC Logs