| | <<<Back 1 day (to 2016/03/15) | 20160316 |
| tor8 | Robin_Watts: morning. have you looked at the code various compilers generate for do/while compared with switch? | 10:17.25 |
| | gcc without optimizations generates exactly the same asm out for both, so I think we're good on the gcc front | 10:17.43 |
| Robin_Watts | I have not looked. | 10:18.46 |
| | I am still undecided on whether the last change is a good idea or not. | 10:19.14 |
| tor8 | I suspect it's more prone to running afoul of compiler madness | 10:19.36 |
| | or just compiler dumbness, when generating code for switch | 10:19.52 |
| Robin_Watts | A continue within an fz_try() will mean that the fz_always and fz_catch are not run. | 10:19.55 |
| tor8 | oh, right! | 10:20.13 |
| Robin_Watts | which will lead to the exception stack getting out of sync. So I reckon drop that last commit, and just go with yours. | 10:20.28 |
| | Are you happy with all my commits? | 10:20.49 |
| | If so, just push all yours, and we're good. | 10:20.56 |
| tor8 | I'd say we're better off adding a code checking script that looks for break/continue/return between try and catch | 10:21.03 |
| Robin_Watts | break is fine. It's continue and return that are problematic. | 10:21.26 |
| | but let's not worry about it for now. | 10:21.44 |
| tor8 | Robin_Watts: will push, stuff looked good last night when I looked through it. | 10:21.54 |
| Robin_Watts | cool. | 10:21.59 |
| | So, did Fred fix the java stuff? | 10:22.08 |
| tor8 | Robin_Watts: I see nothing on his repos. | 10:26.09 |
| | Robin_Watts: so ... I updated the URW fonts and ran a bmpcmp | 10:26.27 |
| | hundreds of pages of diffs ... is there a way to tell bmpcmp to ignore small diffs? | 10:26.45 |
| | mvrhel (for the logs): pdf_copy_direct shouldn't be necessary (or could just be implemented with pdf_keep_obj) since null, int, real, string and name objects are immutable (and not bound to a document) | 10:31.19 |
| chrisl | tor8: I take it you just manually renamed all the font files? Or changed the mappings in the code? | 10:32.21 |
| tor8 | mvrhel: I wouldn't try to take care of the page tree parent pointer at all; there are lots of other places where there are page pointer stuff that also needs to be taken care of. | 10:32.25 |
| | chrisl: changed the mappings in the code | 10:32.31 |
| chrisl | I'm getting pretty hacked off with the way the file names (and font names!!) randomly change with each release... | 10:33.13 |
| tor8 | chrisl: the metrics for individual oddity glyphs keep randomly changing as well... | 10:33.35 |
| | but the new version did fix the t-cedilla glyph | 10:33.51 |
| Robin_Watts | tor8: Yes. | 10:34.16 |
| | bmpcmp -w3 tells it to ignore any changes within a 3x3 window. | 10:34.32 |
| chrisl | The metrics haven't been such an issue since it's usually been ones only accessed from PDF, where the spacing tends to be explicit - but yes, that's a pain, too | 10:34.44 |
| Robin_Watts | bmpcmp -t32 tells it to ignore any changes where the pixel value is within 32 of the last one (out of 255 obviously) | 10:35.10 |
| tor8 | chrisl: if only it weren't for base14 fonts having optional Widths | 10:35.21 |
| | Robin_Watts: let me try with -w3 and see what happens | 10:35.39 |
| | that should pick up any major glyph differences and hopefully not pick up slight outline diffs | 10:36.00 |
| chrisl | tor8: true.... I did say "less of" and not "not an issue"..... | 10:36.34 |
| tor8 | mvrhel: I don't see why you need pdf_copy_compressed_stream; if you copy the raw stream (pdf_load_raw_stream) and copy over the dictionary entries all should be good | 10:36.56 |
| | the compressed buffers are for use with fz_image that can decompress images on the fly | 10:37.11 |
| chrisl | Well, I think I'll hold off doing stuff with the fonts until you are happy with them..... | 10:37.36 |
| tor8 | chrisl: still, the base set of glyphs in the pdf standard encoding look stable enough :) | 10:37.38 |
| | mvrhel: pdfgraft_main is missing | 10:39.07 |
| chrisl | tor8: well, the damned well should be after all this time! | 10:40.32 |
| tor8 | mvrhel: when checking for the source number, pdf_is_indirect is a better test than checking if pdf_to_num is 0 | 10:43.38 |
| Robin_Watts | tor8: So MuPDF stacks up pretty well against gs, except when asked to do CMYK stuff. I've just twigged why that might be... | 11:08.08 |
| | Our central paint routines don't unroll for the CMYK case. I might have a quick look at that. | 11:08.43 |
| | tor8: 1 tiny commit on robin/master | 11:13.21 |
| tor8 | Robin_Watts: LGTM | 11:14.34 |
| Robin_Watts | Ta. | 11:14.41 |
| tor8 | hm; I guess optimizing compilers have been tweaked a lot since I wrote that code | 11:14.56 |
| | it was designed to let the optimizing compilers of the day to automatically specialize the loops when inlining | 11:15.10 |
| | but only if we have actual subfunctions for the various number-of-components | 11:15.26 |
| | it might improve speed if we add fz_paint_solid_color_5, etc | 11:15.58 |
| Robin_Watts | tor8: Yes, that's my plan. | 11:16.27 |
| | Going to do a profile or two to verify that is where the time is being lost. | 11:16.41 |
| tor8 | hm, it looks like my optimized levels of stuff has been rewritten a few times :) | 11:16.54 |
| Robin_Watts | attempts to looks innocent... | 11:17.09 |
| tor8 | ah, it's still there for fz_paint_glyph_solid | 11:17.29 |
| | fz_pain_glyph_solid calls fz_paint_glyph_solid_N in a switch | 11:17.48 |
| | to allow inlining with specialized code | 11:17.57 |
| Robin_Watts | Yes, it's a great system. I like it, and I've adopted it elsewhere. | 11:18.14 |
| tor8 | though I suspect the new paint_glyph_solid_N exceeds the threshold for inlining now that it deals with runlength compressed data | 11:19.08 |
| | it's worth adding a simple case 5: in the fz_paint_span etc switchers and measure | 11:20.22 |
| | chrisl: bah, the dingbats font has borked the encodings or something else... the new one doesn't work with mupdf | 14:29.49 |
| | chrisl: I'm only testing with the CFF extracted from the OTF, mind you | 14:30.10 |
| chrisl | tor8: I problems with the encodings in the last release..... | 14:30.47 |
| | tor8: I assume that's D050000L? | 14:35.15 |
| tor8 | chrisl: yes. | 14:36.03 |
| chrisl | Well, the Type 1 has the same encoding as the old one, I think. | 14:37.06 |
| | Don't know about the glyph order, though | 14:37.37 |
| tor8 | yeah, I'm wondering if the embedded CFF is just wrong. need to debug some more. | 14:37.50 |
| | the glyph names look like they match up, but the encoding subtable is blank :/ | 14:41.23 |
| | chrisl: have you got a useful t1-to-cff conversion tool? | 14:41.56 |
| kens | Ghostscript :-) | 14:42.15 |
| tor8 | fontforge reinterprets a lot of stuff and has pretty crap cff output | 14:42.16 |
| chrisl | I just used fontforge, which I wasn't too impressed with | 14:42.21 |
| tor8 | the truetypes are a *lot* bigger... the glyf table is twice the size of the corresponding cff | 14:42.52 |
| chrisl | Huh, when I load the OTF in Ghostscript, the encoding has one "real" name, and the rest are /.notdef - that seems bad! | 14:43.48 |
| kens | chrisl Another Cairo classic: | 14:43.59 |
| | http://stackoverflow.com/questions/36037460/why-does-ghostscript-replace-fontnames-to-cairofont | 14:43.59 |
| tor8 | chrisl: with my cff disasm tool, the 'encoding' subtable is empty | 14:44.38 |
| chrisl | tor8: Yeh, I suspect gs is adding a name, just so it's valid | 14:45.18 |
| | kens: wtf??? | 14:45.42 |
| kens | Classic isn't it ? It refers to the original font name in the PDF file, leaves all the boiler plaet and other names untouched in the type 1, but changes the FontName ion the type 1. Who thought that was a smart idea ? | 14:46.23 |
| | I had trouble figuring out why pdfwrite was apparently changing the font name.... | 14:46.54 |
| chrisl | tor8: possibly the Adobe tools would make a decent fist of converting type 1 to CFF, but I'd be temped to chuck this back at URW - we're paying for this stuff, after all | 14:48.53 |
| tor8 | chrisl: I'm guessing their font tools 'optimize' the otf output by skipping the cff tables that are duplicated in the sfnt | 14:50.50 |
| chrisl | tor8: well, then, the OTFs aren't much good for us.... | 14:51.29 |
| tor8 | not really, no. gs just ignores the SFNT wrapper for otf fonts doesn't it? | 14:51.54 |
| chrisl | It does, yes | 14:52.03 |
| | That needs to change, but not going to happen soon | 14:52.28 |
| | tor8: Try this one? http://ghostscript.com/~chrisl/D050000L.cff | 15:07.18 |
| tor8 | chrisl: how did you generate that? | 15:12.28 |
| | I've just managed to get AFDKO to build enough to get me the 'tx' tool that can convert to CFF | 15:12.42 |
| chrisl | tor8: using the Adobe FDK tc tool | 15:12.54 |
| | tx tool | 15:12.58 |
| tor8 | chrisl: ah :) | 15:13.18 |
| | the encoding table is there! | 15:13.38 |
| chrisl | At a glance it looks reasonably sane, as well | 15:14.00 |
| | tor8: file names thing is a ball-ache though - I specifically asked for a filename -> URW name -> industry name mapping, and we haven't got that | 15:17.46 |
| tor8 | the mappings are missing the industry name | 15:25.17 |
| | they only look to have the old gibberish-number -> font name -> file name mappings | 15:25.33 |
| chrisl | tor8: the xlsx file has the industry name mappings, but at least some of the URW names don't match the names in the font files | 15:26.39 |
| tor8 | chrisl: looks like I'll be able to use the .t1 fonts converted to cff with tx at least | 15:26.51 |
| HenryStiles | chrisl: make a bug assigned to me. | 15:26.52 |
| chrisl | HenryStiles: is one bug with my complaints okay? And if we're doing that, maybe we should wait until we see if tor8 finds further issues? | 15:30.56 |
| mvrhel_laptop | tor8: I fixed the things you mentioned. I am going to add in any needed try, always, catch stuff and chase down memory leaks today. | 15:32.14 |
| | tor8: Someplace the parent objects have to be handled. That is still in there for now. | 15:32.43 |
| HenryStiles | chrisl, tor8 : sure | 15:33.09 |
| Robin_Watts | tor8: 1 more commit on robin/master for your consideration. | 15:34.17 |
| tor8 | mvrhel_laptop: that'll be up to the caller to deal with. we considered copying pages by creating a new page object and grafting only the relevant sub-entries from the source page dictionary | 15:53.23 |
| Robin_Watts | mvrhel_laptop: If you are going to be leak hunting, grab the latest stuff from golden, cos the memento in there has been polished a bit. | 15:54.28 |
| mvrhel_laptop | Robin_Watts: ok thanks | 15:55.41 |
| | tor8: ok I will move it into the tool part | 15:56.01 |
| Robin_Watts | tor8: Updated commit online. This gets a clean clusterpush. Let me know how massively it offends you. | 15:57.52 |
| tor8 | Robin_Watts: no need for two levels of macros for the name mangling | 16:25.19 |
| | in fact, no need for any levels of macros at all, ## works just fine outside of macros too | 16:25.36 |
| | it's just stringification that's messy | 16:25.43 |
| Robin_Watts | tor8: Wouldn't work without that. | 16:25.47 |
| | No, stringification is easy, cos "a" "b" is "ab" at the language level. | 16:26.14 |
| | I tried it direct, then with 1 layer of macros, then with 2 :) | 16:26.28 |
| tor8 | stringification as in turning FOO(bar) into "bar" | 16:26.34 |
| Robin_Watts | If you can prove me wrong, I'll be happy. | 16:26.43 |
| tor8 | #define FUN in mupdf_native.c is only one level | 16:27.39 |
| | you might need spaces around them? | 16:27.46 |
| Robin_Watts | The things in FUN aren't themselves defines. | 16:28.25 |
| tor8 | ah. | 16:28.36 |
| | I'll play with it later, time for dinner | 16:28.49 |
| Robin_Watts | cool. | 16:28.54 |
| tor8 | #if defined(N) seems overly cautious | 16:29.19 |
| Robin_Watts | tor8: The generic N case has N not being defined. | 16:31.17 |
| | Forward 1 day (to 2016/03/17)>>> | |
IRC Logs