| | <<<Back 1 day (to 2015/08/05) | 20150806 |
| rayjj | henrys: so order preservation (I assume order of entry into the dictionary) is required, but not mentioned in the docs? And why isn't the binary tree code in the source? I see in comment 4 in bug 695568 you said "I know Norbert uses binary trees for the dictionary" | 00:03.23 |
| | henrys: I missed that obscure comment, but since I was able to replicate a slowdown I'm not sure that he is using anything that speeds up the dict access/search. This file defines 64K macros with incrementing keys | 00:05.33 |
| | henrys: in any case, is there an example file that requires a specific order of search? (as far as I can tell, you can't have two entries with the same key -- they are replaced) so access using the key will be unique. | 00:07.38 |
| | henrys: It may be that there is a font issue since pcl5ccet/25-13.BIN shows a difference, but that is the *only* difference in 75k tests from the regression run with the hash table code. | 00:13.28 |
| | henrys: at the very least, explanation of the requirement for search order and possibly norbert's binary tree should be in the code. | 00:15.28 |
| | henrys: there are extensive comments in the code about 'synonyms' all being "equivalent" and "commutative and transitive", but that relates to the value, *not* the key or the search order. | 00:18.36 |
| Robin_ | fredross-perry: Hey | 00:35.10 |
| fredross-perry | yo | 00:35.18 |
| Robin_ | I did some android stuff for separations. Let me try and find it. | 00:36.17 |
| | crap. I did it at home on my computer. I bet I pushed it to my repo on casper, and I've now overwritten it. | 00:42.33 |
| | My computer at home is turned off, so I can't get to it :( | 00:42.45 |
| rayjj | henrys: bug closed, *with* the patch attached in case norbert wants to have a look at it (no performance numbers are stated for his binary tree methods AFAIK, so this might be faster). In any case, I won't spend any time looking at relative performace of 9.06 vs 9.16 with the hash table code unless someone re-opens the bug (or opens a new bug) | 00:43.16 |
| Robin_ | I bet the commits are on ~robin/repos/mupdf.git on casper, but I can't see how to get to them. | 00:43.19 |
| rayjj | Robin_: you mean you don't recall the SHA ? ;-) | 00:45.17 |
| Robin_ | rayjj: We've discussed my memory before, right? :) | 00:45.43 |
| rayjj | Robin_: if we did, I've forgotten ;-) | 00:46.05 |
| Robin_ | fredross-perry: You might find a magic git command to pull them out. If not, sorry, it'll have to wait til I get back. | 00:48.28 |
| | I am being called away... | 00:48.34 |
| fredross-perry | That would explain. No worries. I thought I was losing my mind. But I found it, it was right here in the drawer. ;-) | 00:49.45 |
| rayjj | I'm on to digging into the cust 532 issue (that I hoped would have just gone away). Acrobat seems to totally ignore TilingType 1 -- I've constructed example files (sent to customer as well) that show the effect | 00:51.58 |
| henrys | sorry about the confusion rayjj the problem was assigned to you to confirm or refute a performance regression in the chunk allocator. I didn't think you'd get into the pldict.c stuff. | 01:29.32 |
| Robin_ | tor8: For the logs, do you know of any git magic to pull a commit out of a bare repo? If so, there are some android mupdf.c changes on ~robin/repos/mupdf.git that I did just before I left that would be useful to fred. | 03:15.19 |
| rayjj | henrys: given the dramatic performance improvement of the hash based pldict approach, and norbert's numbers (presumably with his binary search dict) the effort is probably not wasted. FWIW, the total chunk allocator percentage was less than one tenth the pl_dict stuff (according to the profiler -- which is still a bit questionable) | 03:37.32 |
| | henrys: as I said, I'm surprised that the improvement with the hashing was so large, since the profiler (if I'm decoding it correctly) had it as 15%, not 95% | 03:39.01 |
| | but for now, I'm focused on Len's/Phillip's issue | 03:39.19 |
| jogux | Robin_: fredrossperry: I suspect git fsck --full --no-reflogs --unreachable --lost-found | grep commit gets you part way there. that turns up an awfully long list though :-( | 08:24.59 |
| chrisl | kens: When you have a minute, can you cast an eye over: git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=5f03bedb | 09:24.53 |
| kens | 1 second | 09:25.19 |
| | wow quite a few changes | 09:26.12 |
| | chrisl all looks fie to me | 09:27.45 |
| | fine* | 09:27.49 |
| chrisl | kens: Thanks - it's not surprising there are quite a few misuses, given the interspersing of sfopen() and gp_fopen() calls :-( | 09:28.42 |
| kens | yeah I';m sure that's true | 09:29.05 |
| | chrisl your commit caused a number of seg faults :-( | 09:46.39 |
| chrisl | Huh? It didn't yesterday..... | 09:50.41 |
| kens | I'm only going by the cluster report | 09:54.29 |
| | Admittedly I can't see why it would cause seg faults either | 09:54.44 |
| chrisl | Well, the good news is that I can reproduce the crash | 09:55.48 |
| kens | Oh well that's something anyway | 09:56.04 |
| chrisl | Er, it's crashing in pdfwrite.... weird | 09:57.00 |
| kens | :-( | 09:57.10 |
| | I've been making changes there, fixing Coverity problems | 09:57.22 |
| | can you give me an example that fails ? | 09:57.48 |
| chrisl | svn/ghostscript/tests/Ghent_V3.0/051_Font_subset_PSnames_ident_x1a.pdf | 09:58.18 |
| kens | OK let me check here | 09:58.26 |
| chrisl | Crash is in assign_char_code() in gdevpdti.c | 09:58.36 |
| kens | THat sounds like it was me then | 09:58.46 |
| | Because I changed that | 09:58.52 |
| | But why didn't I get a cluster run error ? | 09:59.02 |
| | And it doesn't crash for me on Windows | 09:59.43 |
| | Do I need a specific command line ? | 09:59.58 |
| chrisl | I used: -sOutputFile=./tests_private__pdf__sumatra__693025_-_jbig2_memory_leak.pdf.ps.ppmraw.300.0.ps -sDEVICE=ps2write -r300 -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -dClusterJob -dJOBSERVER ../../svn/ghostscript/tests/Ghent_V3.0/051_Font_subset_PSnames_ident_x1a.pdf | 10:00.22 |
| kens | OK it could be that pbfs->open_font->rname is NULL that would do it | 10:00.43 |
| chrisl | It is | 10:00.51 |
| kens | OK I can fix that, but I still want to know why the cluster didnt' flag it as a problem for me | 10:01.14 |
| | Oh you're using ps2write, not pdfwrite | 10:02.05 |
| chrisl | Actually, pdfs->open_font is NULL | 10:03.45 |
| kens | That sounds bad. | 10:03.54 |
| | I thnk I need to rethink that change | 10:04.14 |
| | Huh, in fact I thnk I need to remove it altogether | 10:04.50 |
| | I think that's actually a Coverity false positive | 10:04.59 |
| | let me just try that on the cluster | 10:05.54 |
| chrisl | kens: If I reset to the commit *before* my sfopen() one, I still get the same crash | 10:06.10 |
| kens | Yeah you should, but weirdly I didn't | 10:06.21 |
| | 1 moment while I fix this | 10:06.50 |
| | and test it | 10:06.53 |
| chrisl | Ray had that oddity the other evening, too, with loads of files suddenly throwing errors | 10:07.33 |
| kens | THs is a genuine fault, it *should* have thrown errors, I think GMail may have eaten my cluster report | 10:07.59 |
| | And indeed, ther eit is in the spam folder :-( | 10:08.32 |
| | That's the srouce of the problem, I was doing a number of commits and didn't realise that one of the test mails had gone AWOL | 10:09.59 |
| | First time I've had GMail mark a cluster run as spam though | 10:10.16 |
| chrisl | And you latest commit doesn't build | 10:10.25 |
| kens | I fixed that at the same time | 10:10.37 |
| | Or at leats I will, when I'm sure this cluster test is OK | 10:11.07 |
| chrisl | Baffling..... | 10:11.24 |
| kens | Well my cluster email has vanished into the ether somewhere, but the dashboard report says its fine. | 10:20.55 |
| | So I'll do that commit now | 10:21.00 |
| | OK that should sort it out. Apologies for any confusion engendered. | 10:23.35 |
| chrisl | These things do happen | 10:24.20 |
| kens | Something somewhere has defintely eaten the report from my last cluster run :-( | 10:25.55 |
| tor8 | Robin_: git reflog or git fsck --unreachable | 10:45.11 |
| | Robin_: ah, jogux beat me to it. | 10:45.53 |
| jogux | :-) | 10:56.52 |
| user8271 | does anyone have experience with identify counting pages? | 12:55.25 |
| kens | No idea what you mean | 12:55.41 |
| user8271 | I use "identify -format %n pdf_file" to count the number of pages | 12:56.35 |
| | but with the latest version, instead of outputing number of pages in pdf, it outputs number of pages repeated by number of pages | 12:57.03 |
| kens | Nope, no clue. | 12:57.03 |
| | Perhaps you shoudl ask the maintainers of the identify utility | 12:57.16 |
| user8271 | version is 6.9.1-10 | 12:57.30 |
| | where do I find them? | 12:57.40 |
| kens | Other than 'not here' I have no idea | 12:57.50 |
| | Apparently its part of ImageMagick | 12:58.14 |
| | So I'd ask there | 12:58.19 |
| | They appear to have a forum here: | 12:59.38 |
| | http://www.imagemagick.org/discourse-server/ | 12:59.38 |
| user8271 | I thought it is part of ghostscript, but seems I was wrong. thank you! | 13:01.12 |
| kens | Defintely not part of Ghostscript, though it 'might' use it | 13:01.32 |
| henrys | oh I didn't know you could specify --depth with git clone, nice if you don't need all the history locally... | 14:33.12 |
| chrisl | I think it's a fairly recent addition | 14:34.12 |
| henrys | marcosw: we looked at this a while ago but it's back again. gs4txtwrite is hogging a CPU on casper, been going for at least a day... | 14:45.37 |
| kens | can we keep the input file this time please ? | 14:46.19 |
| chrisl | It's not clear it's going to be useful given the gs executable is ancient | 14:47.08 |
| kens | <</ManualFeed false>> setpagedevice statusdict begin 0 setpapertray end<</ManualFeed false>> setpagedevice statusdict begin 0 setpapertray end<</ManualFeed false>> setpagedevice statusdict begin 0 setpapertray end<</ManualFeed false>> setpagedevice statusdict begin 0 setpapertray endOh, well that won;t help certianly | 14:47.19 |
| | Bah stupid cut/paste | 14:47.27 |
| | Migh still be nce to look at it though | 14:47.54 |
| chrisl | Well, I've no idea where the input file is stored, and I doubt marcosw will know either | 14:48.28 |
| | The gs executable for that page dates from 2013 | 14:49.35 |
| kens | Oh dear :-( | 14:49.50 |
| | More coffee..... | 14:50.11 |
| henrys | do you want the file it is working on? | 14:50.14 |
| kens | If you can find it then yes, please | 14:50.31 |
| henrys | it's in your home on casper. It starts with CGItemp | 14:51.26 |
| | I was hoping marcosw would have some sort of alarm for processes running 100% for days that he uses with the cluster stuff... but not sure. | 14:53.13 |
| kens | OK I see the file, now lets try it out | 14:54.33 |
| henrys | here are the command lines running now on casper. Not sure why there are 2 and why one is sleeping: | 14:55.29 |
| | www-data 6118 0.0 0.0 2272 492 ? S Aug05 0:00 sh -c /usr/lib/cgi-bin/gs4txtwrite -sstdout=/dev/null -dBATCH -dNOPAUSE -sDEVICE=txtwrite -dSAFER -sOutputFile=- 2>/dev/null -dTextFormat=2 /var/tmp/CGItemp52879 | 14:55.31 |
| | www-data 6119 95.3 0.0 31436 1256 ? R Aug05 2007:43 /usr/lib/cgi-bin/gs4txtwrite -sstdout=/dev/null -dBATCH -dNOPAUSE -sDEVICE=txtwrite -dSAFER -sOutputFile=- -dTextFormat=2 /var/tmp/CGItemp52879 | 14:55.31 |
| | | 14:55.31 |
| kens | well it doesn't lock up with a newer executable | 14:56.36 |
| | as Chrisl suspected | 14:56.41 |
| | Hmm, I don't thnk the user who submitted that file really thought about it. Its a "Unique identification Authority of India" letter | 15:01.33 |
| | It has his name address ID number and possibly other stuff in it. | 15:02.00 |
| | Beswt we delete that I htnk | 15:02.06 |
| chrisl | kens: how long does it take to process? | 15:02.24 |
| kens | I can't tell its too quick :-) | 15:02.34 |
| | effectively instant | 15:02.43 |
| henrys | now I notice the distribution gs on casper is also really old, I thought marcosw updated regularly | 15:02.55 |
| chrisl | gs distribution on casper? | 15:03.18 |
| rayjj | peeves and peeved new IP addresses appear to have propagated now. Can others confirm that it looks ok | 15:03.35 |
| kens | I see them at 100.9.62.163 and 165 | 15:04.28 |
| henrys | chrisl: yeah /usr/bin/gs is 9.10 as well. I thought the solution would be just use the distribution release then we'd have a fairly recent version for this. | 15:04.33 |
| rayjj | those txtwrite issues have come up often | 15:04.34 |
| | kens: thanks. those are correct | 15:04.43 |
| chrisl | henrys: that's the gs version that came with Ubuntu 14.04, so..... | 15:05.06 |
| henrys | chrisl: makes sense | 15:07.50 |
| | I wonder what would trigger them to update 14.04 LTS with a new gs? a security issue? | 15:09.10 |
| chrisl | Nothing. | 15:09.23 |
| henrys | rayjj: peeves and peeved "ping" for me. | 15:10.49 |
| morksig | hello gs people, I'm playing around with FreeType's OpenType CFF renderer and was wondering... is there any specific reason why the URW35 fonts supplied with GS are shipping as Type1 fonts instead of modern .otfs? | 15:37.29 |
| chrisl | morksig: mainly because it's a Postscript interpreter so it makes sense to ship with Type 1 fonts | 15:38.03 |
| | morksig: Postscript doesn't support otf fonts | 15:38.33 |
| morksig | ah, okay :) because I love the CFF renderer and was thinking about investing some time to fix up the hinting of some fonts and sending the otfs for inclusion, in an attempt to promote FreeType's CFF renderer to distros. | 15:41.13 |
| | they part of the standard collection of installed fonts after all | 15:42.33 |
| chrisl | morksig: We do actually have plans to move to using otf/CFF fonts - but internally, they end up being treated as Postscript Type 2 fonts. But we use the fonts that URW ship, we've stopped patching them | 15:42.43 |
| morksig | hm, you mean URW supplies CFF fonts themselves to the project? or that you're going to simply convert the type1s to cffs? | 15:44.53 |
| chrisl | morksig: URW will supply us with otf fonts | 15:45.24 |
| morksig | oh! that's nice :) so I just have to stay put and wait :) any ETA? | 15:46.19 |
| chrisl | We're hoping release after next. But there's stuff internal to Ghostscript we have to resolve first | 15:47.08 |
| morksig | alright, thanks :) | 15:49.28 |
| | that means I can close my bug 696133 :) | 15:50.30 |
| chrisl | morksig: also note that if we get feedback that there's stuff out there that *relies* on the base-35 being Type 1, the plan might fall in a heap...... | 15:50.48 |
| morksig | hm. can't you ship both then? at least so that distros can prefer the otfs? | 15:53.00 |
| chrisl | These are the *Ghostscript* fonts - we ship the fonts that Ghostscript uses | 15:54.22 |
| | Plus, there's not much of a benefit to OTF fonts | 15:55.15 |
| morksig | yes, well, but they're also the default core fonts on several distros. Fedora puts them in "/usr/share/fonts/***default***/ghostscript/", which says something I think ;) the main benefit is that FreeType's CFF renderer can render CFF fonts at a higher quality than Type1 fonts, which is the main reason I want them. | 15:57.45 |
| chrisl | Well, you could fix the Freetype Type 1 code...... | 15:59.01 |
| henrys | morksig: do you have samples of rendering differences? | 15:59.19 |
| | just curious | 15:59.25 |
| chrisl | TBH, shipping both is something I would consider - once we get the current issues resolved, they're not going to change much/often | 15:59.51 |
| morksig | the author of the CFF renderer said it could theoretically be rewritten to also handle type1, but advised against it because it would increase complexity a lot. as it stands, only CFF fonts are handled right now | 16:00.32 |
| chrisl | We know what the problem is with Freetype's Type 1 code - although, I'm unclear about how the CFF interpreter resolves it | 16:00.52 |
| morksig | henrys: http://blog.typekit.com/2013/05/01/adobe-contributes-cff-rasterizer-to-freetype/ and http://google-opensource.blogspot.de/2013/05/got-cff.html | 16:01.14 |
| chrisl | morksig: it's not a renderer, it's just an interpreter - all font types use the same renderers in freetype | 16:01.30 |
| morksig | okay, interpreter then :) | 16:01.57 |
| chrisl | The major problem with the Type 1 code is that the outlines aren't scaled as the charstrings are parsed | 16:04.13 |
| henrys | morksig: neith of those links diff type 1 and cff they seem to diff cff with different rasterizers? | 16:05.50 |
| | s/neith/neither | 16:05.57 |
| | I guess the assumption is the type 1's will come out the same. | 16:06.50 |
| chrisl | I must admit, I didn't notice that big an improvement in switching to the Adobe contributed code, for the Ghostscript use, anyway | 16:08.26 |
| morksig | henrys: hm, well, yeah. what I basically want to say is that I like the output of Adobe's CFF interpreter/engine much more than what FreeType's autohint puts out :) Using the autohint path for type1, cff and truetype thingies will probably yield the same result. | 16:10.50 |
| | chrisl: rendering improvement or otherwise? | 16:13.27 |
| chrisl | Rendering - but then, we don't use hinting (except for TTF fonts) | 16:15.03 |
| morksig | it's only active when you hint afaik, "hintfull" without autohinting in fontconfig-speak | 16:16.06 |
| | or okay, just the hinting part is active then :D | 16:16.26 |
| chrisl | What's only active? | 16:16.32 |
| morksig | which is what I'm after | 16:16.40 |
| | the hinting part of it | 16:16.52 |
| chrisl | Yes, well, hinting is of limited importance for anything above ~300dpi | 16:17.42 |
| | And for a *lot* of fonts out there, the low-res results are worse with hinting.... | 16:18.27 |
| morksig | yeah, which is why i want 300+dpi in desktop monitors... | 16:18.47 |
| | I find e.g. Adobe's Source font family quite nice with hinting. | 16:19.38 |
| chrisl | Very few free or cheap fonts have the time devoted to them to produce really good hinting | 16:20.22 |
| malc_ | morksig: Just today i noticed terrible kerning with source code pro... sigh | 16:20.35 |
| morksig | yes, but my impression is that hinting a font is MUCH easier with CFF-type fonts because of the simpler type1-esqueness | 16:21.33 |
| chrisl | Than Truetype? Sure, Truetype doesn't really have "hinting" | 16:23.00 |
| morksig | malc_: how so? | 16:23.04 |
| malc_ | morksig: not sure what you are asking | 16:23.40 |
| morksig | malc_: i haven't noticed terrible kerning, so I was asking for an example :) | 16:24.20 |
| malc_ | morksig: it was in cyrillic portion.. | 16:25.58 |
| morksig | okay, no experience with that ;) | 16:26.20 |
| malc_ | can't blame you | 16:26.44 |
| Robin_ | Changing hotels. See y'all in a bit. | 17:05.23 |
| | Forward 1 day (to 2015/08/07)>>> | |
IRC Logs