Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2020/02/18)Fwd 1 day (to 2020/02/20) >>>20200219 
petercher I'd like to discuss the bug 688990 - imagemask interpolation doesn't quite match Adobe00:45.20 
  The reference implementation seems to have white pixels before the scan line and black pixels after the scan line.00:46.41 
  gs and my implementation assume white pixels on both sides. Is this acceptable?01:16.03 
  Can somebody comment on the bug 688990, "imagemask interpolation doesn't quite match Adobe" ?16:17.12 
Robin_Watts Hi petercher 16:39.40 
  If you have a mechanism for getting an exact match, then we'd be interested in seeing it.16:40.24 
petercher The context on the left and right edges used by on Adobe is different.16:42.08 
  Does gs want this bug?16:42.22 
Robin_Watts petercher: The issue is this...16:44.31 
  It's a device dependent operation.16:44.42 
  If we can exactly match adobe then there is some arguable benefit to us taking a new version.16:45.06 
  If we can't exactly match adobe, then it's a question of us moving from one thing that doesn't quite match to another thing that doesn't quite match - much less of a benefit.16:45.45 
  Whether it's worth our time is a question of complexity etc.16:46.26 
ray_laptop Robin_Watts: and from your comment #8, does Adobe even match Adobe (presumably we were comparing to CPSI which we no longer have running anywhere)16:47.13 
Robin_Watts If you have a commit ready to go, then clearly we'll take a look (and we'll honour the bountiable status) as long as it's not stupidly complex.16:47.28 
  I suspect this is one of those bugs that we'd never have bothered with if it came up again today, but given that it has, let's see what you've come up with.16:48.03 
petercher I want to know what to do with the right edge.16:48.22 
Robin_Watts petercher: I would not put any more effort into trying to get an exact match to adove.16:48.57 
  adobe.16:48.59 
  as long as it does something that doesn't look awful, we probably don't care.16:49.22 
petercher OK, I'll submit a patch today.16:50.31 
Robin_Watts Thanks.16:50.42 
petercher Please also look at the big 70210516:51.01 
Robin_Watts Bear with us a bit though, cos we're in the throes of preparing a release, so we may not get to look at it immediately.16:51.03 
ray_laptop Robin_Watts: how do we test/verify the scaling -- it is likely to cause LOTS of bitmap diffs, and AFAIK we don't have "real Adobe PS" available (we used to have ScanVec Amiable CPSI, but that dongle no longer works on modern motherboards -- I last tried it > 3 years ago when my MB died)16:51.09 
kens petercher I'm still awaiting a response on bug #69059516:51.35 
Robin_Watts ray_laptop: Presumably petercher has something he's been working against?16:52.56 
  petercher: I'll need to dig into bug 702105 a bit to understand what the patch achieves.16:53.33 
petercher kens: Oh, that bug affected the spool size rather than the output file. 16:53.41 
kens Well can you tell me how to reprooduce a result please ?16:54.15 
petercher Yes, the old SAi PhotoPrint.16:54.24 
kens Could you stick a method in a comment on the bug please ? I'm in the middle of a different problem and I'll only forget....16:54.52 
ray_laptop petercher: Yes, that's what we have (we bought a copy years ago) but, I can get it to run anymore. How is yours running?16:55.50 
petercher Robin_Watts: The old code increased the counter too much and missed end-of-line condition.16:56.15 
ray_laptop s/can get/can't get/16:56.21 
Robin_Watts petercher: Right, but I need to convince myself that's a reasonable fix rather than improving the end-of-line condition. I'm a bit buried at the moment, but I have it on my list now.16:57.22 
petercher Robin_Watts: I'll attach my full test file to 702105. This file will establish the base state for the old interpolation.17:00.03 
Robin_Watts ok.17:03.40 
  ok, I've looked at 702105 and it looks plausible to me. I'll get that in. Thanks.17:19.36 
 <<<Back 1 day (to 2020/02/18)Forward 1 day (to 2020/02/20)>>> 
ghostscript.com #mupdf
Search: