| | <<<Back 1 day (to 2012/11/12) | 2012/11/13 |
| Robin_Watts_ | sebras: robin.watts@artifex.com - don't know about the others. Everything ends up at robin@wss.co.uk anyway. | 00:05.40 |
| tor8 | chrisl: xpsfapi.h could be inlined into ghostxps.h, but I take it you didn't do it that way given your preference for many small header files, or is there a conflict in xpsfapi.c otherwise? | 10:21.59 |
| chrisl | tor8: I wanted to keep a consistent pattern across all the languages, that's all | 10:22.36 |
| tor8 | chrisl: okay. | 10:22.47 |
| | I obviously don't know enough about FAPI, but would it be possible to strip away most of xpscff.c and xpsttf.c eventually? | 10:23.22 |
| | or is that still needed for -dDisableFAPI? | 10:23.31 |
| chrisl | That's still needed for -dDisableFAPI, but that should be removed in a release, or two. Most or all of xpscff.c and xpsttf.c can go at that point | 10:24.20 |
| | Oh, bloody hell, XPS has the last_char hack, too :-( | 10:26.11 |
| kens | Like PCL ? | 10:26.28 |
| | Probably because it was copied from there | 10:26.36 |
| chrisl | Yes, I removed it from PCL, didn't realise XPS had it, too | 10:26.50 |
| | tor8: FWIW, I'm not married to the xpsfapi.h separate header, given how small it turned out to be...... | 10:30.22 |
| kens | chrisl ping | 11:57.07 |
| chrisl | kens: pong | 11:57.17 |
| kens | odd problem with building PCL | 11:57.25 |
| | Having bropken my repo yetserday I recopied it today and am remaking my make changes. | 11:57.46 |
| | When building PCL I seem to be getting a UFST invocation | 11:58.00 |
| | in winlib.mak, line 139 | 11:58.11 |
| | !ifdef UFST_ROOT | 11:58.23 |
| | !include $(UFST_ROOT)\fapiufst.mak | 11:58.23 |
| | !endif | 11:58.23 |
| | Gettging this error: | 11:58.35 |
| | 1>..\gs\base\winlib.mak(139) : fatal error U1052: file '..\gs\base/../ufst\fapiufst.mak' not found | 11:58.36 |
| | 1>Stop. | 11:58.36 |
| | 1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\nmake.exe"' : return code '0x2' | 11:58.37 |
| | WHIch sort of looks like UFST_ROOT is configured | 11:58.47 |
| chrisl | Erm, UFST_ROOT shouldn't be defined - hang on, let me try it | 11:59.04 |
| kens | Yeah, I thought it shouldn't be defined, which is why I'm a bit puzzled. | 11:59.27 |
| | If it is defined it has a weird value. | 11:59.39 |
| chrisl | The error you pasted above suggests a fairly sane value | 12:00.15 |
| kens | Hmm, I thought the multiplicity of '.' and '..' looked odd | 12:00.40 |
| | I certainly don't have UFST on this machine ;-) | 12:01.09 |
| | checked my environment to make sure I don't have UFST_ROOT set there | 12:01.28 |
| chrisl | It's just a way of finding the "gs" directory - it's always one above "base" | 12:01.38 |
| kens | :-) | 12:01.45 |
| | pcl6_msvc.mak | 12:03.04 |
| | UFST_ROOT=$(GLSRCDIR)/../ufst | 12:03.24 |
| | Only if UFST_BRIDGE is true though | 12:03.40 |
| | Or rather if its no undefined | 12:04.08 |
| | Oh, actually no | 12:04.25 |
| | # Define whether to compile in UFST. Note that freetype will/must be disabled. | 12:04.51 |
| | # FAPI/UFST depends on UFST_BRIDGE being undefined - hence the construct below. | 12:04.51 |
| | # (i.e. use "UFST_BRIDGE=1" or *not to define UFST_BRIDGE to anything*) | 12:04.51 |
| | !ifndef UFST_BRIDGE | 12:04.51 |
| | UFST_BRIDGE= | 12:04.51 |
| | !endif | 12:04.51 |
| | UFST_ROOT=$(GLSRCDIR)/../ufst | 12:04.52 |
| | UFST_LIB_EXT=.a | 12:04.52 |
| | THat seems to make it unconditnally set UFST_ROOT | 12:05.14 |
| chrisl | Hmm, okay, so we porbably need "!if UFST_BRIDGE == 1" around the UFST_ROOT assignment | 12:06.55 |
| kens | Going by winlinb.mak, yes I think so | 12:07.10 |
| | I'll try it quickly | 12:07.19 |
| | Huh syntax error | 12:08.33 |
| chrisl | Sorry you need to expand the variable ""!if $(UFST_BRIDGE) == 1" | 12:09.39 |
| kens | aha | 12:09.43 |
| | Nope still get a syntax error | 12:10.32 |
| kens | hates makefiles | 12:10.37 |
| sebras | kens: how about some automake? ;) | 12:11.04 |
| chrisl | Hmm, I'm still getting the makefile not found..... give me a minut | 12:11.17 |
| kens | is never going there... | 12:11.19 |
| Robin_Watts | !if "$(UFST_BRIDGE)" == "1" ? | 12:11.38 |
| kens | chrisl note that my version is a custom hack on the standard make files, so that I cna\ have the originals unchanged in Git | 12:11.48 |
| Robin_Watts | see gs/psi/msvc.mak for the form | 12:12.13 |
| kens | SYNTAX ERROR ;-) | 12:12.22 |
| chrisl | Robin_Watts: yes, solves the syntax error, still ends up with stuff defined that shouldn't be | 12:12.40 |
| kens | Yes, syntax error fixed, but I still have a value for UFST_ROOT | 12:13.16 |
| | Or at least, it is defined | 12:13.30 |
| | and empty | 12:13.36 |
| chrisl | kens: in winlib.mak, line 108...... | 12:15.04 |
| kens | yes ? | 12:15.21 |
| chrisl | Remove the assignment of UFST_BRIDGE | 12:15.22 |
| kens | aha, OK | 12:15.26 |
| | still get the same error | 12:15.43 |
| | '\fapiufst.amk not found' | 12:15.58 |
| chrisl | Then about line 138, change the conditional to !if "$(UFST_BRIDGE)" == "1" | 12:16.09 |
| kens | Way better | 12:16.58 |
| | stufff is building now | 12:17.03 |
| | I owuld think testing UFST_BRIDGE is a better bet than testgin the existence of UFST_ROOT | 12:17.35 |
| chrisl | Too many places where the same variable can be set :-( | 12:17.46 |
| | I'll commit the change once I've tested it | 12:18.07 |
| kens | still has to try xps, svg and language_switch | 12:18.19 |
| chrisl | winlib.mak should be common to all | 12:18.40 |
| kens | I'm sure iot is, but I think I'd better check that its OK :-) | 12:18.58 |
| | TO be honest, I don't need these so there's no rush, I was just doign a compelte test of my modified projects... | 12:19.24 |
| Robin_Watts | Gawd. According to Raph the expected distance from a set pixel to the next set pixel in a greyscale of level g is 0.95/(g^2) | 12:20.01 |
| | I reckon it's 1/SQR(g) | 12:20.11 |
| kens | That's quite a difference | 12:20.23 |
| chrisl | Well, I really couldn't care less about language_switch - in fact, at least if I broke it, people would stop using it | 12:20.24 |
| Robin_Watts | Now we're dealing with squared differences, which would make it 1/g, which is much closer to what the code actually implements. | 12:21.01 |
| | The code seems to do 0.95/g | 12:21.09 |
| robin_watts_fone | someone just ate my phoneline. ADSL and all. | 12:40.29 |
| | it is possible that its by trying to fix a crackly connection we get when it rains, but... | 12:41.37 |
| | s/by/bt/ | 12:42.04 |
| kens | probably pasing builders | 12:43.06 |
| robin_watts_fone | my builders have buggered off. waiting for bricks to be delivered. | 12:43.54 |
| kens | well I was thinking of any random builder, rather than your own ;-)_ | 12:45.27 |
| robin_watts_fone | there is a by van parked outside, so.... | 12:54.24 |
| | bloody autocorrect. bt. | 12:54.50 |
| chrisl | fixes for PCL and XPS pushed, language_switch is still broken - will fix it when I get back...... | 13:02.03 |
| kens | My builds are still building.... | 13:13.41 |
| Robin_Watts | electrician here now, so unexpected power cuts'r'us. | 13:38.26 |
| kens | wonders if builds are stuck in some endless loop.... | 13:51.40 |
| Robin_Watts | Interesting. gutenprint includes an option for "Even Tone" dithering. | 13:56.03 |
| kens | could be something different | 13:56.21 |
| Robin_Watts | http://fossies.org/dox/gutenprint-5.2.9/dither-eventone_8c_source.html | 14:39.56 |
| | Looks very similar | 14:39.59 |
| kens | well it credits artofcpode with the algorithm | 14:40.31 |
| Robin_Watts | except without the incremental calculation of distances. | 14:40.33 |
| kens | and Raph | 14:40.44 |
| | So I guess it is the same | 14:40.52 |
| Robin_Watts | D'oh. | 14:40.55 |
| | Shows how much I read comments :) | 14:41.00 |
| | (for the logs) I was wrong about the incremental calculation of distances - it does use that. | 15:33.09 |
| henrys | did you want a linux person to install it and capture output? | 15:43.44 |
| | I guess chrisl or I could do that. | 15:44.27 |
| chrisl | Hmm, I can't get language_switch to build in Windows - even before the FAPI changes....... | 15:48.36 |
| kens | I haven't tried to build it for ages | 15:48.56 |
| henrys | we really should disable it entirely (all platforms) | 15:50.12 |
| chrisl | I could just leave it broken, then..... :-) | 15:50.36 |
| henrys | probably best | 15:52.28 |
| Robin_Watts | Bah. That's quitting talk. | 15:52.45 |
| | henrys: I was hoping to use Gutenprint to send the output from ETS to my printer. I am asking on the gutenprint mailing list as to how. | 15:53.01 |
| | I just noticed their ETS stuff while reading the docs. | 15:53.19 |
| chrisl | Robin_Watts: (as you're the only person I know that uses it) have you build language_switch recently? | 15:54.32 |
| Robin_Watts | chrisl: Yes. | 15:54.52 |
| | Whenever I do "Build Solution" on ghostscript. | 15:55.06 |
| | (but if you mean within the last week or so, while my attention has been elsewhere, no) | 15:55.20 |
| chrisl | VS2005 fails - I haven't tried other VS versions | 15:56.14 |
| Robin_Watts | VS2005 is what I use. | 15:56.24 |
| kens | I'm on 2008 and it fails | 15:56.34 |
| chrisl | syntax error ';'? | 15:56.48 |
| kens | no, I got an error on the makefile, wait a moment I'll try again | 15:57.08 |
| | ah, seems to be wroking since I did an update | 15:57.34 |
| | previous time was with my hacked up makefiles | 15:57.44 |
| | Using your proper commmit this time | 15:57.51 |
| chrisl | I guess I'll have to bisect, this will be s.l.o.w........ :-( | 15:58.59 |
| kens | chrisl the error I get is: | 16:01.23 |
| | 1>NMAKE : fatal error U1073: don't know how to make '.\debugobj\fapi.dev' | 16:01.23 |
| Robin_Watts | So, forms meeting time, but paulgardiner has said he'll be late. | 16:02.07 |
| chrisl | kens: yes, but I can't get the previous revision to build, either. I think I know how to fix the fapi error, but I just hit the same error I get the earlier revision | 16:02.27 |
| kens | Ah, OK | 16:02.37 |
| Robin_Watts | henrys: Did you have anything to discuss? | 16:02.43 |
| henrys | Robin_Watts:I thought we'd give paulgardiner a few minutes | 16:09.04 |
| | but no I didn't have anything important to say | 16:09.46 |
| Robin_Watts | me either. | 16:10.06 |
| henrys | I'll be around if he shows up, tor8 do you have anything? | 16:11.45 |
| paulgardiner | Hi. I made it back, nearly in time | 16:12.57 |
| Robin_Watts | paulgardiner: Ah, hi. We were just all saying that we didn't really have much to discuss anyway :) | 16:14.31 |
| paulgardiner | :-) | 16:14.39 |
| Robin_Watts | sebras tried the forms stuff on linux the other day. | 16:15.04 |
| | he noted that the input wasn't as nice as on other platforms (still console/stdin based, IIRC)? but then we knew that. | 16:15.36 |
| paulgardiner | I don't think I have anything to add. A little bit more to do implementing alerts on android before I'll know if the plan works. | 16:15.46 |
| Robin_Watts | He did say that it was asking twice for each input though, which sounds wrong? | 16:15.52 |
| paulgardiner | That's odd | 16:16.06 |
| tor8 | henrys: I got nothing | 16:16.53 |
| henrys | this isn't really related to paulgardiner but with the show coming up it might be good to look at overall performance issues on the android platform. Frequently we see scanned to pdf stuff, how well does a big bitmap work on the android? | 16:21.39 |
| Robin_Watts | henrys: Well, we decode bitmaps and cache them internally. We then smooth scale them to the screen. The smooth scaled versions are cached too. | 16:22.34 |
| | We also have a subsampling mechanism where we avoid holding the fullsize bitmap, but rather just the log2 subscaled size above the size we need (for some bitmap types at least) | 16:23.20 |
| | So as long as you aren't repeatedly changing your zoom over such a boundary, you stand a good chance of only having an interpolated plot to do. | 16:24.10 |
| paulgardiner | I have some files that, on each pan, are slow to update in high-quality the ucovered areas. | 16:27.01 |
| Robin_Watts | paulgardiner: Bitmaps? Lineart? | 16:27.22 |
| | transparency? | 16:27.30 |
| paulgardiner | Bitmaps I think | 16:27.40 |
| | Grahame's thesis is one example. | 16:27.59 |
| Robin_Watts | Presumably that's tex output right? | 16:28.25 |
| paulgardiner | It's the pages with diagrams that are slow | 16:29.29 |
| henrys | Well for the show you can have some demo's onhand that you will know in advance don't perform poorly, but I wouldn't discount somebody coming up and saying bring up my pdf at http:// ... if we quickly paged through all the files in the PDF ATS it might show something. That was a "royal" we. | 16:29.51 |
| Robin_Watts | I have my finger on my nose. | 16:30.24 |
| paulgardiner | The diagrams could be line art | 16:30.53 |
| | That or very high res images | 16:31.05 |
| | Slowness seems to be more related to image complexity than size, so I think they might be line art | 16:33.15 |
| | That, plus I cannot see pixelation other than at screen res | 16:33.42 |
| henrys | well why don't we all just be mindful of it. I'll pull down the new apk and put it on my nexus and try to run some interesting files, if everyoned does that we'll get a pretty good sense of performance | 16:34.44 |
| | are we good for this meeting? I wanted to work on some other stuff? | 16:36.08 |
| Robin_Watts | I'm happy. | 16:37.50 |
| paulgardiner | Yeah, I'm good thanks. | 16:37.54 |
| ray_laptop | morning, all | 16:38.09 |
| Robin_Watts | So, we're all agreed, we'll get ray to do it then? | 16:38.14 |
| | oh, hi ray. | 16:38.19 |
| ray_laptop | I am in the fourth day of a bad cold :-( | 16:38.24 |
| henrys | Robin_Watts:right ray_laptop will do it, he's weak from sickness and won't be able to fight. | 16:45.28 |
| | Uh could you please rifle through the PDF ATS on your phone and tell us what happens? Nobody is going to volunteer for that one. | 16:46.50 |
| Robin_Watts | henrys: I'll do that, yeah. | 16:47.58 |
| | mvrhel: ping ? | 16:53.29 |
| mvrhel | good morning | 16:54.57 |
| Robin_Watts | Morning. | 16:55.03 |
| | I've been prodding at the random noise stuff today briefly. | 16:55.33 |
| | partly to see if we can reduce it's scale so it can't be noticed, while keeping it having the desired effect. | 16:56.21 |
| | and something has just struck me. | 16:56.38 |
| mvrhel | Robin_Watts: oh. I had a plan to take a look at the random stuff to see what the frequency characteristics were | 16:56.44 |
| Robin_Watts | Ah. I tried to understand that too. | 16:56.56 |
| | We can talk about that if you want. | 16:57.06 |
| | but the thing that I just noticed... | 16:57.25 |
| kens | D'OH! Robin_Watts the bmpcmp is Candidate, Reference, Difference ? | 16:57.35 |
| Robin_Watts | there are 2 different ways of getting randomness; one uses seeds, one using tables. | 16:57.45 |
| | kens: Yes... | 16:57.51 |
| kens | Then I am being totally dumb, and the candidate is a progression, thanks Robin_Watts | 16:58.09 |
| | Been staring at that for an hour :-( | 16:58.15 |
| henrys | CRD kens just like the postscript dictionary | 16:58.23 |
| kens | henrys, yes, but for some stupid reason I was thinking the opposite | 16:58.41 |
| | I haev no idea why..... | 16:58.48 |
| Robin_Watts | the one that uses tables picks a table value given an x/y position. | 16:59.02 |
| | which means it gets the same random value for every plane. | 16:59.19 |
| | wheras the seed based one will get different random values for each plane. | 16:59.36 |
| | I wonder if that is significant ( and which one is better). | 16:59.47 |
| | In particular I wonder if picking the same value for each plane is bad when we are doing multiplane optimisation. | 17:00.07 |
| henrys | okay the only thing I had for the meeting is I was hoping tor8, ken and I would carefully review chrisl's changes. | 17:00.48 |
| | chosen because tor8 and I do languages and kens can review font stuff. | 17:01.03 |
| tor8 | henrys: the changes to xps were pretty minimal | 17:01.15 |
| | I went through them this morning | 17:01.22 |
| mvrhel | Robin_Watts: oh good catch | 17:01.30 |
| | the correlation between the randomness in the planes is not good | 17:01.56 |
| henrys | tor8:okay thanks | 17:02.04 |
| Robin_Watts | Having said that, the seed based one looks worse to me :( | 17:02.07 |
| mvrhel | Robin_Watts: is the seed based one generating a nice blue noise pattern I wonder? | 17:02.52 |
| Robin_Watts | No idea. It's a mysterious "tm" table ina header file. No indication how it's generated. | 17:03.20 |
| | sorry. | 17:03.34 |
| | The seed based one is NOT blue noise, I'm sure. | 17:03.45 |
| | It's a simple random number generator. | 17:03.51 |
| mvrhel | Robin_Watts: ok that is the difference I suspect | 17:03.55 |
| | I bet he generated a nice blue noise pattern in the table | 17:04.09 |
| Robin_Watts | The table based one is from a header. | 17:04.12 |
| | could be. | 17:04.15 |
| mvrhel | when he needs to have 4 (or more) of those | 17:04.27 |
| Robin_Watts | or at least to space us out within that table. | 17:04.42 |
| mvrhel | Robin_Watts: I will grab the one in the header and take a look at it | 17:04.44 |
| henrys | marcosw:fwiw I notice the firefox folks are using a tool called perecptual diff to detect visual differences with themselves and poppler, I looked at that too some time ago and it seemed to slow to be useful but maybe it has improved. We could compare ourselves with Adobe using something like that. | 17:04.52 |
| | alexcher your regression machine has been down quite a bit. Is everything okay? | 17:05.25 |
| marcosw | I can take a look at it. is perceptual diff available as a stand alone tool or embedded deep in the firefox source distribution? | 17:05.53 |
| Robin_Watts | http://pdiff.sourceforge.net/ | 17:06.03 |
| mvrhel | Robin_Watts: so what is the period and organization of the data in tmmat? | 17:06.06 |
| alexcher__ | henrys: somebody has switched it off. | 17:06.10 |
| henrys | Robin_Watts:what Robin_Watts said | 17:06.44 |
| Robin_Watts | mvrhel: Urm... | 17:07.08 |
| | result->tmmat = tmmat; | 17:07.10 |
| | result->tmwid = 256; | 17:07.12 |
| | result->tmheight = 256; | 17:07.14 |
| mvrhel | ok | 17:07.17 |
| henrys | marcosw:any reason alexcher's machine is off | 17:07.54 |
| | alexcher how about your project - you've seemed quiet lately. | 17:08.19 |
| alexcher__ | henrys: I hope It will be ready for the meeting. | 17:09.02 |
| marcosw | yes. alex_x6 fails when running svn update in the tests_private directory. I contacted him some time ago asking for access and/or to send me the logs but didn't hear back (or more likely he did reply and I overlooked it). | 17:09.05 |
| alexcher | marcosw: I thought it was a random glitch. | 17:10.03 |
| henrys | Robin_Watts, mvrhel:it looks like you guys have ets under control, is there anything else you need? | 17:10.10 |
| mvrhel | Robin_Watts: has done 95% of the work | 17:10.32 |
| | maybe even 99% | 17:10.41 |
| henrys | there is no harm in sending a question to Raph if you want. | 17:10.50 |
| Robin_Watts | henrys: Well, at the moment, none of us has got to the stage of printing anything. | 17:10.57 |
| | henrys: Right, but I think we now understand the code. | 17:11.22 |
| henrys | does gutenprint recommend ets for some particular product? | 17:11.29 |
| mvrhel | Oh maybe I can try to get some printing to take place this week here | 17:11.34 |
| | I found my old code to drive the HP | 17:11.46 |
| henrys | kens:anything for the meeting? | 17:11.56 |
| Robin_Watts | gutenprint has ETS built in; it says it's very good for photos, less good for drawings etc. | 17:12.10 |
| marcosw | alexcher: no, I've tried several times and it hangs trying to fetch tests_private/pdf/PDF_1.7_ATS it's a large set of files but shouldn't be a problem since your internets connection is fast. both peeves and henrys_x6 managed the update okay (I had to deal with the machines in miles's manually). | 17:12.30 |
| Robin_Watts | It's not Raph's code, but someone elses reimplementation. | 17:12.33 |
| | It has a 'hybrid' ETS too, where (AIUI) it uses ETS to choose between certain known dither cells. | 17:13.46 |
| marcosw | henrys: pdiff hasn't been updated in 3.5 years, so depending on when you last looked at it it won't have gotten faster (otoh computers are faster and we have a cluster of fifteen 6/8 core machines). | 17:13.57 |
| henrys | It might be fun for us to take over that project - just a thought. Probably could do a lot with multiple cores. | 17:16.57 |
| | I wish I could find mozilla's pdf.js QA project page that used pdiff I was just lookng at it the other day. | 17:18.31 |
| | anyway that's all I had this week, anybody else? | 17:19.55 |
| Robin_Watts | http://people.mozilla.com/~bdahl/corpusreport/test/ref/ ? | 17:20.09 |
| henrys | that is it yes | 17:21.15 |
| marcosw | I just upgraded do Acrobat XI and was about to run the test suite (including the new PDF_1.7_ATS files) so Ghostscript using our internal bitmap comparison tools. I'll give pdfiff a try and see how it compares. | 17:24.30 |
| | Speaking of PDF_1.7_ATS, did we want to add a subset of these to the git/nightly/weekly regression tests? There are too many files to add all of them and I don't know how to go about selecting a reasonable subset. | 17:25.19 |
| henrys | maybe ray can identify a subset based on customer complaints. | 17:27.45 |
| | in the interest of not repeating bugs | 17:27.58 |
| marcosw | some of the files would probably be good to use as performance regression test, since most of the Quality Logic PDF files we currently use are too fast to be useful. | 17:29.52 |
| henrys | and if you are feeling proactive QA wise: another interesting thing I saw mozilla do was grab pdfs from the web with the highest page rank - googling for filetype:pdf pdf - that seems to pull up some important pdfs that we should get right. | 17:31.31 |
| | back to the salt mine | 17:32.13 |
| marcosw | henrys: I saw that and was going to fetch the list of files they use and see if there were any we had problems with. I presume someone would have noticed by now, but perhaps not. | 17:33.26 |
| | I have to run, my battery is nearly dead and this starbucks doesn't have any available power outlets. | 17:34.41 |
| sebras | henrys: or harvest problematic pdfs from other projects bugzillas... | 17:35.48 |
| henrys | sebras:yes - for all of these ideas the pdiff thing looks very powerful, assuming we are interested in finding problems ;-) | 17:39.22 |
| mvrhel | Robin_Watts: So I am grabbing the tm file and going to have a look at it in MATLAB to see what the frequency characteristics are | 17:41.09 |
| | Robin_Watts: the psd format had me so mad yesterday. trying to read files from photoshop itself (not just ours) and they dont seem to follow the spec that I have very well. the size of the resources dont seem to be correct. I am going to hold off on that for a bit | 17:44.08 |
| Robin_Watts | mvrhel: I was driven mad enough by it adding support to bmpcmp for it. | 17:45.11 |
| mvrhel | I remember that | 17:45.29 |
| Robin_Watts | mvrhel: In the paper, Raph describes the expected distance as being 0.95/(g^2) | 17:47.50 |
| | I reckon that's rubbish. | 17:47.58 |
| kens | off for the night, goodnight everyone | 17:48.51 |
| Robin_Watts | For a greyscale of 1/4, we'd expect (say) the top left pixel in each 2x2 square to be set. Hence an expected distance of 2. | 17:49.07 |
| | For a greyscale of 1/9, we'd expect the top left pixel in each 3x3 square to be set. Hence an expected distance of 3. | 17:49.32 |
| | For a greyscale of 1/16, 4 etc. | 17:49.45 |
| | so I reckon the expected distance is more like SQR(1/g) | 17:50.02 |
| | The algorithm deals in "distance squared" though, so that would be 1/g | 17:50.27 |
| | and the actual code uses 0.95/g which is pretty close. | 17:50.38 |
| | So I think the paper is wrong. That explains one of the FIXMEs. | 17:51.02 |
| mvrhel | Robin_Watts: good observation on this | 17:51.48 |
| henrys | I did want ask at the meeting we start spell checking logs, someone's commit reminded me of that ;-) Does that seem reasonable? | 18:00.26 |
| chrisl | I wonder if there's a commit hook for that..... | 18:01.27 |
| Robin_Watts | henrys: oops. Was that me? | 18:01.54 |
| henrys | actually kens commit got my attention but I think most of us have done it. | 18:02.56 |
| mvrhel | I had to go look at the logs to see. I know I do a mispell now and thng | 18:02.59 |
| | Kens is pretty good :) | 18:03.15 |
| Robin_Watts | https://github.com/icefox/git-hooks | 18:03.49 |
| ray_laptop | Spell checking with all of our special terms will be a pain. It'll take a while to get a dictionary that has everything. unless maybe we can process old logs, kick out all 'mis-spellings' and add those that are OK. | 18:05.59 |
| | have to change venues. bbiaw. | 18:07.55 |
| henrys | yes I was more thinking you guys could have an editor with spell checking that pops up when you commit right? Then you can ignore jargon | 18:08.02 |
| Robin_Watts | Right. Can emacs be set to spell check commit messages automatically? | 18:10.38 |
| | If you come up with the emacs lisp for that, I'll have a copy :) | 18:10.59 |
| | ooh. git-gui might already do it. | 18:11.26 |
| henrys | I use flyspell-mode. even works for comments in code. | 18:18.31 |
| Robin_Watts | Needs ispell installed. | 18:19.59 |
| henrys | yes | 18:20.29 |
| | http://www.emacswiki.org/emacs/FlySpell | 18:20.57 |
| | is that a problem on windows? | 18:21.32 |
| Robin_Watts | just installing aspell now to try. | 18:21.47 |
| | That seems to be working. | 18:33.36 |
| | but not in C files. | 18:33.44 |
| henrys | did you add the hook from the wiki page | 18:34.28 |
| Robin_Watts | I did. | 18:34.36 |
| | And even calling it manually doesn't seem to work. | 18:34.45 |
| henrys | and it's listed in your mode bar - I have (C Fly AC Abbrev) | 18:36.53 |
| | when I bring up a c file that is. | 18:37.25 |
| Robin_Watts | (C Fly Abbrev) | 18:37.26 |
| | doesn't run automatically. Maybe I have the hook name wrong. | 18:37.39 |
| | OK, now I have it running automatically. | 18:38.33 |
| | but it's not highlighting misspellings in comments. | 18:38.59 |
| henrys | mine underlines and colors misspellings | 18:40.17 |
| Gigs- | Are there non-deterministic factors in tiffsep's output? | 18:42.11 |
| | I wrote a regression script that's pretty sensitive and running it multiple times gives me different results each time in terms of regression vs no regression | 18:42.46 |
| | I'm taking care of the date, these are single pixel differences, 00 turns to ff, etc | 18:43.09 |
| chrisl | Gigs-: which tiff device are you using? | 18:43.32 |
| Gigs- | tiffsep? | 18:43.42 |
| chrisl | Hmm, I'm not aware of problems with tiffsep, although someone on here was saying the same thing, but wouldn't give us any details | 18:44.30 |
| Gigs- | it's not a problem really, just single pixel differences that seem non-deterministic | 18:44.51 |
| henrys | Robin_Watts:it doesn't preprocess the entire file but you should get an error if you type in an error or edit near a misspelling | 18:45.06 |
| Robin_Watts | Right. That's what I tried. | 18:45.41 |
| mvrhel | Robin_Watts: so the random matrix is definitely blue noise like. Perhaps I should generate 3 others | 18:45.47 |
| | ? | 18:45.48 |
| Robin_Watts | Gigs-: It seems like a problem to me. | 18:46.08 |
| chrisl | Gigs-: there is (we think) a very rare indeterminism in the halftoning code, but it shouldn't affect tiffsep | 18:46.08 |
| Robin_Watts | mvrhel: 3 ain't enough :( | 18:46.23 |
| mvrhel | ? | 18:46.29 |
| | well for CMYK that will be fine | 18:46.35 |
| Gigs- | I'll see if I can pin it down further | 18:46.39 |
| mvrhel | I can generate 5 more | 18:46.46 |
| Robin_Watts | CMYKcmy ? | 18:46.46 |
| mvrhel | ok 6 more | 18:46.52 |
| | to I hear 7? | 18:47.00 |
| | s/to/do/ | 18:47.08 |
| Robin_Watts | I'd be tempted to just have the 1 and use offsets for each plane personally. | 18:47.29 |
| mvrhel | Robin_Watts: that would be fine | 18:47.45 |
| | a much better solution | 18:48.13 |
| ray_laptop | Robin_Watts: Just applying a horizontal and/or vertical shift per plane should reduce correlation in the randomness | 18:48.13 |
| | for the stochastic threshold when I wanted CMYK I just did 90 degree rotations, but offsets of 1/4 or so of the table is fine too | 18:49.06 |
| | mvrhel: did you ever do the Fourier on the tm matrix noise ? | 18:49.41 |
| mvrhel | just did it | 18:49.47 |
| | and can see that it is blue | 18:49.57 |
| ray_laptop | mvrhel: sorry -- I missed that in the log. | 18:50.11 |
| mvrhel | not sure it was in the logs. I mentioned to Robin_Watts that I was going to look at it | 18:50.33 |
| | and just got it into MATLAB and looked at the power spectrum | 18:50.49 |
| ray_laptop | so blue noise should be better than white noise (that the seed gives us). Which shows in the results as well. | 18:51.14 |
| mvrhel | right | 18:51.58 |
| | getting the planes uncorrelated in their noise should provide some improvement too | 18:52.16 |
| ray_laptop | of course, we can play with the frequency and spectrum for the blue noise and maybe make it better. | 18:53.31 |
| | I suspect that we want a very high frequency since that's where the eye is going to pick up 'patterns'. If the dots are far apart, a little position difference is not noticed | 18:55.16 |
| | I would guess the frequency corresponding to between 3 and 8 pixels would work well. | 18:57.02 |
| Robin_Watts | So, I've been staring at the compute_randshift code. | 19:06.37 |
| | I reckon it's called with nl in the 0..0x10000 range. | 19:06.55 |
| | and with 'rs' being the shift value. The higher the shift, the lower the effect the noise has. | 19:07.54 |
| | It generally returns rs unchanged, except when nl is in certain ranges, when it decreases rs by up to 3 and returns it. | 19:08.31 |
| | The question is where are those ranges centred... I reckon they are: | 19:08.57 |
| | centred on 0x10000, reduces rs by up to 3. This corresponds to full intensity. | 19:09.28 |
| | centred on 0x8000, reduces rs by up to 3. This corresponds to alternating pixels. | 19:09.51 |
| | Actually, a better way of putting this: 1 => -3, 1/2 => -3, 1/3 => -2, 1/4 => -3, 1/6 => -1 | 19:11.13 |
| | then there is another one, about 1/9.33 if I'm reading it right, which is -1. | 19:11.34 |
| henrys | chrisl:I am pretty sure that shift in pcl/pcl5cfts/fts.0010 banner is a regression, let me create an obvious example | 19:22.11 |
| chrisl | henrys: I'm not seeing a significant shift there | 19:27.40 |
| henrys | yes but it grows with font size sending an email. | 19:28.58 |
| | do you want bugzilla reports or just emails? | 19:30.24 |
| chrisl | henrys: bugzilla is probably best | 19:30.45 |
| henrys | It looks like you are missing the lsb | 19:30.55 |
| | I sent the email already but I'll do bugzilla from now on. | 19:32.41 |
| | bbiab | 19:37.48 |
| Robin_Watts | henrys: PDF_1.7_FTS? Was that what you wanted tested? | 19:52.53 |
| | No, the ATS... | 19:54.24 |
| henrys | either rays new ats files or PDFIA1.7_SUBSET | 20:03.02 |
| Robin_Watts | Ah. I'll do the subset as the new ones are still downloading. | 20:09.57 |
| henrys | oh okay great. | 20:14.29 |
| Robin_Watts | paulgardiner: We really must get it to sort the file list | 20:15.12 |
| | Of the IA3Z files there are 4 slow/sluggish ones | 20:36.19 |
| | 0845 being the worst. | 20:36.29 |
| | CATZ8874.pdf is unreadable. | 20:43.46 |
| | CATX8874.pdf that is. Due to not being able to zoom far enough in. | 20:44.10 |
| Gigs- | Need attachments to http://bugs.ghostscript.com/show_bug.cgi?id=693447 marked private | 20:44.51 |
| Robin_Watts | Done. | 20:45.56 |
| | mvrhel, ray_laptop: I think I'm burnt out on ETS for a bit. | 20:49.46 |
| | I'm going to step away from it tomorrow and look at the slowness in some of these mupdf files. | 20:50.04 |
| | I've pushed all my latest fiddlings. | 20:50.16 |
| | Gigs-: Thanks for the bug report. | 20:50.47 |
| Gigs- | thanks | 20:52.07 |
| | I don't know if it's going to be reproducible or not | 20:52.17 |
| | make sure to try at least 5 times | 20:52.28 |
| mvrhel | Robin_Watts: ok. on ETS. I can look at some of the things that remain on the list. Did you do anything with the random stuff then? | 21:09.41 |
| tkamppeter | mvrhel, hi | 21:12.52 |
| | oy, hi | 21:13.14 |
| mvrhel | tkamppeter: hello | 21:13.27 |
| oy | tkamppeter, hello | 21:13.57 |
| mvrhel | tkamppeter: I have the output intent stuff on my to do list | 21:14.08 |
| oy | cool | 21:14.14 |
| tkamppeter | mvrhel, did oy contact you already about our findings about Ghostscript on the Color Management hackfest which ended yesterday? | 21:14.17 |
| mvrhel | tkamppeter: no | 21:14.29 |
| | oy and tkamppeter: if you can wrap up any issues into bugzilla for me that would be very helpful | 21:15.15 |
| | in case they are not already there | 21:15.26 |
| | I have an appt I need to head out for right this sec | 21:15.38 |
| tkamppeter | mvrhel, you are talking about bug 691952? | 21:15.55 |
| mvrhel | right | 21:16.12 |
| | tkamppeter ^^ | 21:16.23 |
| tkamppeter | mvrhel, and bug 693438? | 21:16.37 |
| mvrhel | oh that is the one that chris was telling me about | 21:17.12 |
| | I will try to take a look at that tonight | 21:17.23 |
| | need to go now. if there is more please open bugs | 21:17.31 |
| oy | assumes, tkamppeter has the OutputIntent and Rendering Intent bugs reported or actualised | 21:17.44 |
| tkamppeter | oy, I have updated bug 691952 because of your test files, and Richard has reported bug 693438 due to messed up CUPS Raster files. Please tell me if there is another issue to report. | 21:37.15 |
| oy | tkamppeter, will look tomorrow into | 21:38.27 |
| chrisl_r61 | henrys: I believe the problem was the scaling when I retrieved the glyph width through FAPI causing rounding errors. I have an idea, but it needs more testing - tomorrow...... | 22:31.19 |
| | marcosw: I had to revert your --exclude Makefile change to clusterpush.pl because it broke the pcl/xps/ls cluster testing. We'll need to just exclude ghostpdl/gs/Makefile, and not ghostpdl/Makefile | 23:55.05 |
| marcosw | isn't ghostpdl/Makefile generated by ./configure (or autogen)? | 23:55.53 |
| chrisl_r61 | No, it's in git - ghostpdl uses a config.mak.in for the configure results | 23:56.28 |
| marcosw | oops, sorry about that. | 23:58.38 |
| chrisl_r61 | No worries. Since we're not maintaining the non-configure ghostpdl build any more, we could change that, but for now, I just commented out the line in clusterpush.pl | 23:59.56 |
| | Forward 1 day (to 2012/11/14)>>> | |
IRC Logs