| | <<<Back 1 day (to 2015/10/01) | 20151002 |
| fredross-perry | mvrhel_laptop: rayj: I am seeing â# # # rgâ and NOT â# # # # kâ in tiger.eps.d.pdf. | 00:02.55 |
| | I tried adding â-sColorConversionStrategy=CMYKâ when converting to PDF, no change really. | 00:30.18 |
| | I shoud say that the resulting tiger.eps.d.pdf has â# # # # kâ and NOT â# # # rgâ, but the proofing result looks the same. | 01:26.45 |
| kens | Looking at rayjj's comments from last nght re tiger.eps, pdfwrite absolutely does *NOT* convert the incoming colour space unless specifically told to do so (using -dUseCIEColor or -dColorConversionStrategy). A PDF created from a CMYK tiger will have CMYK in it. | 07:13.57 |
| kens2 | And the reason the tiger uses RGB colour space is because that's how the tiger.eps file declares its colours. THe file contains a procedure which uses setrgbcolor, it does not use setcmykcolor. So you should expect that the PDF output by Ghostscript will be in RGB space, because the input is in RGB space. | 07:27.35 |
| | If I set -sColorConversionStrategy=CMYK then teh output is in CMYK space. | 07:28.38 |
| | fred clearly had the same result (since his tifer.pdf use s'k' to set colours), I have no idea why the proofing result would be the same. But I don't see any problem with what pdfwrite is doing. | 07:29.57 |
| Robin_Watts | Morning tor8. | 08:11.44 |
| tor8 | Robin_Watts: morning. | 08:12.33 |
| Robin_Watts | I think I OK'd all of your commits apart from the "Todo: ref counting one" | 08:12.35 |
| | There are a few more on robin/master too. | 08:12.47 |
| tor8 | Robin_Watts: yes, I've got a fix for the refcounting TODO on tor/master as well | 08:14.23 |
| Robin_Watts | cool. I'm out for a bit, but will look when I get back. | 08:16.20 |
| tor8 | Robin_Watts: all LGTM (but you'll want to rebase again to pick up the modified commits on tor/master instead) | 08:19.15 |
| sebras | tor8: you mentioned that you are to do a release soon. how soon? | 09:09.24 |
| tor8 | sebras_: next week, hopefully | 09:22.55 |
| sebras | tor8: alright, then let's skip jxr and bmp. | 09:35.57 |
| | tor8: I'm travelling to dublin today, but I'll be back and then I'm eager to fix the last jxr issues and fix the bmp decoder. | 09:36.31 |
| tor8 | sebras: okay. safe travels! | 09:44.17 |
| Robin_Watts | sebras: Have fun. | 11:23.59 |
| | fz_outline refcounting is not threadsafe. | 11:25.55 |
| | tor8: oooh, unhappy cluster test. | 11:38.01 |
| | tor8: Urgh. If you look at my bmpcmp, you'll see that that font width thing has nasty side effects :( | 11:56.21 |
| tor8 | Robin_Watts: yeah. all of a sudden we respect what the PDF file says the width to be :/ | 11:58.33 |
| Robin_Watts | tor8: Can we not respect the width for the advance, without stretching glyphs? | 11:58.55 |
| tor8 | Robin_Watts: could be mostly fixed with a one-liner, to exempt substitute CJK fonts from font width tabling | 11:59.00 |
| Robin_Watts | Perhaps we should only shrink glyphs, not stretch them? | 11:59.18 |
| tor8 | or to exempt droid sans fallback from stretching | 11:59.24 |
| Robin_Watts | Matching widths is most important for layout, as otherwise we can overwrite other content. | 12:00.56 |
| | Stretching glyphs wider certainly doesn't help with that. | 12:01.20 |
| tor8 | the new font table width code shouldn't affect anything but rendering | 12:01.37 |
| | the positioning is all done, unchanged, on the PDF interpreter side | 12:01.50 |
| Robin_Watts | I can see the logic in shrinking glyphs (so they don't overlay neighbours) | 12:01.52 |
| | The impetus for this was the text extraction stuff. | 12:02.16 |
| tor8 | the stretching logic is to match the actual font width with the PDF specific font widths | 12:02.23 |
| | and we only do that for substitute fonts | 12:02.35 |
| | and that works on the same table of widths as the text extraction | 12:02.53 |
| Robin_Watts | Can you see a downside to never fitting fonts at render time unless they get thinner ? | 12:04.16 |
| tor8 | before we never created the table of widths for non-substitute fonts nor for CJK fonts | 12:04.20 |
| | terrible gaps between words | 12:04.33 |
| | I mean, between letters, making them appear to be separate words | 12:04.45 |
| Robin_Watts | mmm. | 12:05.34 |
| tor8 | the problem of stretching looking this bad is exagerrated by CJK fonts using full width glyphs for punctuation and numbers, | 12:05.39 |
| Robin_Watts | Maybe we need some heuristics. | 12:05.54 |
| tor8 | but without embedding, we can't know if it's a full-width or half-width so I think the default ends up being a proportional-width glyph being stretched to full width | 12:06.05 |
| | the spacing being bad isn't as problematic for CJK | 12:06.12 |
| Robin_Watts | There are some files here (albeit ones where the encoding is screwed), where shrinking chars really does make a difference. | 12:08.48 |
| | But they aren't CJKV. | 12:08.53 |
| tor8 | - pdf_make_width_table(ctx, fontdesc); | 12:09.38 |
| | + if (!fontdesc->to_ttf_cmap) | 12:09.38 |
| | + pdf_make_width_table(ctx, fontdesc); | 12:09.38 |
| | try that patch | 12:09.42 |
| Robin_Watts | ok. | 12:09.49 |
| tor8 | that will cover all CJK substitute fonts | 12:10.45 |
| | but unfortunately also non-embedded fonts that use an Identity-H encoding (seriously, wtf is wrong with people) that we have a workaround for by using the ToUnicode cmap instead | 12:11.28 |
| | Robin_Watts: better fix on tor/master | 12:20.10 |
| Robin_Watts | tor8: Can we use your macros for making the outline refcounts threadsafe? | 13:08.10 |
| tor8 | Robin_Watts: I don't really see the point, but I guess so | 13:20.33 |
| Robin_Watts | Something somewhere along the line causes asserts. | 13:29.38 |
| | and so I'm cluster pushing at various points. | 13:29.46 |
| | I get compile failures at some point. | 13:29.53 |
| | oh, my bad. | 13:30.32 |
| | ok, so the reference counting causes asserts in xps files. | 13:44.05 |
| henrys | chrisl: how's the character problem coming? Anything I can help with? Is it a regression? | 13:57.59 |
| chrisl | henrys: it depends on how you define "regression".... | 13:58.53 |
| | henrys: the problem is that (almost?) all TTF consumers actually translate the glyph outline so the glyph outline origin is at (0,0). Except, it seems, those built into PCL/PXL interpreters, which apparently don't | 14:01.30 |
| henrys | regression definition: I had it right before and you screwed it up ;-) | 14:01.41 |
| chrisl | Well, what we're now doing is the correct way to handle the TTF outline, *but* it's clearly not what PCL/PXL expects | 14:02.20 |
| Robin_Watts | regression = "a bug caused by you fixing a bug that caused the previous stack of bugs to no longer cancel out" | 14:02.35 |
| henrys | I like that | 14:03.05 |
| chrisl | So, yes it is a regression, but it is caused by us now doing something we are supposed to which we didn't previously do | 14:03.56 |
| henrys | chrisl: so we have to treat a tt glyph differently if it is PCL, that's unforturnate. | 14:04.49 |
| chrisl | It seems that way, yes | 14:05.07 |
| Robin_Watts | tor8: OK, so I found the cause of the crashes. You'd added stuff to fz_drop_link to free a dest, but xps was making links without initialising that field. | 14:07.47 |
| | New stack of commits on robin/master | 14:08.00 |
| | cluster testing now. | 14:08.03 |
| chrisl | henrys: and the two problems Norbert reported are actually the same issue | 14:09.57 |
| henrys | chrisl: I thought we had pretty good coverage of download tt's in the regression suite. We'll need to add one of these files I guess. | 14:12.45 |
| | although it may have a test and it was thought to be pixel shift upon checking. That's more likely actually. | 14:13.55 |
| chrisl | henrys: I'm very suspicious about this font, TBH. The thing about always translating the outline to 0,0 is not documented in the spec, but there is overwhelming evidence that is what the benchmark TTF consumers do. There is a head table flag documented to request the interpreter do that translation, and this font has that flag set - so even according to the letter of the spec, the output is "correct" | 14:17.04 |
| tor8 | Robin_Watts: I'd drop the cast on return (fz_link*)fz_keep_imp; the return type is void* | 14:19.22 |
| henrys | chrisl: what exactly in the head table are you looking at? | 14:19.22 |
| tor8 | Robin_Watts: maybe write the loop as while (fz_drop_imp()) { ... } ? | 14:19.35 |
| Robin_Watts | tor8: Ooh, I like that. | 14:19.47 |
| chrisl | henrys: the field called "flags": https://www.microsoft.com/typography/otspec/head.htm | 14:19.59 |
| | henrys: "Bit 1: Left sidebearing point at x=0;" | 14:20.16 |
| henrys | chrisl: so PCLXL ignores that? | 14:21.57 |
| chrisl | Well, that's how it seems, yes | 14:22.15 |
| | henrys: certainly, the old Ghostscript code ignored it | 14:23.18 |
| henrys | chrisl: for type42 as well? | 14:24.55 |
| chrisl | henrys: yup | 14:25.01 |
| Robin_Watts | tor8: Updated. | 14:25.17 |
| henrys | chrisl: so we should come up with a postscript test for this also? | 14:25.26 |
| | or pdf | 14:25.37 |
| chrisl | henrys: well, that brings me to where I'm currently at....... | 14:26.16 |
| tor8 | Robin_Watts: LGTM | 14:27.20 |
| chrisl | henrys: The first thing I need to confirm is that there isn't still something missing in Freetype, and that our previous "correct" output wasn't coincidental on missing this outline translation stuff *and* missing something else | 14:27.44 |
| | In other words, that our old code had two (or more) problems that effectively cancelled each other out | 14:28.21 |
| henrys | chrisl: if you throw that thing into pcl->pdf do you get a type42 that is badly placed in pdf? | 14:29.08 |
| chrisl | I don't get a font in the PDF output | 14:29.26 |
| henrys | chrisl: yeah I feared that... | 14:30.16 |
| chrisl | I'm guessing there isn't enough Truetype font in the PCL to allow embedding in a PDF | 14:30.19 |
| kens | That's not great | 14:30.35 |
| chrisl | This is another thing that muddies the water a bit - I would not be at all surprised if a Postscript or PDF created from the same original TTF worked fine, because *something* in one of the tables not present in the PCL is what we need to get it "right" | 14:31.56 |
| | But as there is no evidence of what the original font actually was, that's pure conjecture | 14:32.36 |
| | henrys: how old is your PCL printer? | 14:37.25 |
| henrys | chrisl: pretty new... | 14:38.07 |
| | still supported | 14:38.22 |
| chrisl | Is it worth throwing one of these files at it, and see what it makes of it? | 14:38.39 |
| henrys | I have the library code that driver clients are supposed to use to create the fonts. | 14:38.42 |
| | chrisl: I did print the test files. You mean different tests? | 14:39.17 |
| chrisl | One of the two Norbert sent | 14:39.35 |
| henrys | I printed the one where the string Bjeljac is wrong and it's right on the HP | 14:40.15 |
| chrisl | Okay, I thought it would - Norbert is pretty conscientious | 14:40.53 |
| Robin_Watts | tor8: OK, see my new bmpcmp. Looks a lot better, but a couple of unexpected changes. | 14:43.16 |
| chrisl | henrys: BTW, I'm to release 9.18 on Monday - assuming nothing horrible comes in over the weekend | 14:43.31 |
| Robin_Watts | 0 and 54 for example. | 14:43.37 |
| henrys | chrisl: sounds good | 14:44.31 |
| Robin_Watts | oh, and 12 :( | 14:44.44 |
| chrisl | Ahem, that should have read " I'm planning to release 9.18"..... I guess I suffering the Friday afternoons | 14:45.09 |
| tor8 | Robin_Watts: yeah, I was about to point out the missing text in 12 | 14:50.38 |
| henrys | kens: I do wonder if all PCL downloaded fonts fail to produce a font on the other end, bitmap and intellifonts are not big deal but the tt's are actually pretty important in most pcl workflows | 14:50.40 |
| kens | henrys I have no idea | 14:51.00 |
| | I have never tested for anything like that | 14:51.07 |
| | I'm not at all certai we actually test the TTF | 14:51.26 |
| | As far as I recall we simply copy it. If it failed to give some kind of information then we might fail at a higher level | 14:51.58 |
| tor8 | Robin_Watts: looks like the overflow check commit is the culprit | 14:54.03 |
| Robin_Watts | tor8: Ah, right. I'll rebase that to the top and push the rest then. | 14:55.31 |
| | Then investigate that. | 14:55.36 |
| | tor8: OK, so the first file that loses all its content contains: | 15:29.09 |
| | 0 1509055325929460700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Td | 15:29.16 |
| | With my overflow check I return that as 0 MAX_INT Td | 15:29.31 |
| | wheras previously we read it as 0 0 Td. | 15:29.42 |
| | I would guess that Acrobat uses 0 too. | 15:31.55 |
| | No, acrobat overflows in exactly the same way we do. So just ignoring the overflow is the correct thing to do. | 15:35.25 |
| | OK, tor8. Updated commits on robin/master | 16:06.41 |
| | The cluster tests out with no diffs all the way except the last 2. | 16:07.02 |
| | I am just going to cluster test/bmpcmp those now. | 16:07.13 |
| | tor8: So, the bmpcmps in my area now, so the latest version of the code. All look like progressions etc except for 42-47 | 16:19.48 |
| tor8 | hm, it looks like there are more regressions there | 16:28.50 |
| | some non-cjk fonts are losing the stretching | 16:28.56 |
| Robin_Watts | tor8: OK, I shall wait on those 2 then. | 16:29.28 |
| tor8 | I'll poke more at them next week, I've got to go now= | 16:29.39 |
| Robin_Watts | Sure. | 16:29.45 |
| | Have a good weekend. | 16:29.47 |
| | I'm back to SOT for a bit. | 16:29.54 |
| mvrhel_laptop | ok. found the issue that mupdf is having with the listbox widget. I think I can get a fix in place for this. Off to run a couple errands now though and then lunch | 17:27.27 |
| | Robin_Watts: are you around? | 21:34.17 |
| Robin_Watts | I am. | 22:06.35 |
| mvrhel_laptop | Robin_Watts: just got back. I know its late there now. are you still up? | 23:39.25 |
| | Robin_Watts: I will chat with you tomorrow | 23:55.49 |
| | Forward 1 day (to 2015/10/03)>>> | |
IRC Logs