| <<<Back 1 day (to 2011/07/18) | 2011/07/19 |
mvrhel2 | henrys: are you there? | 00:01.59 |
henrys | yes | 00:02.57 |
mvrhel2 | so I am working on a fix for bug 692204 | 00:03.31 |
| We probably want this to be the default case I am guessing | 00:03.45 |
| that is device gray mapping to k for deviceCMYK target | 00:04.03 |
| When I do get the fix for this, it is likely there are gong to be significant diffs in the cluster push | 00:04.49 |
| for pkmraw and psdcmyk | 00:05.03 |
| so it is interesting. AR saving to TIFF does the gray to K. But if I open the same PDF in photoshop it does the composite gray that we are currently doing | 00:05.57 |
henrys | this is a regression with the new color management yes? | 00:06.04 |
mvrhel2 | It is a change from the way things were prior to the ICC stuff being added in. I can see some wanting it one way and some wanting it another way. I have a runtime option set up to let the user choose | 00:07.31 |
| I just want to know what we should have for a default. I am guessing the default should be the way it used to be | 00:07.52 |
| which is gray to K only | 00:08.02 |
henrys | yes I agree the old way is best for default, as far as checking if marcos can't look at everything we'll split it up. | 00:08.29 |
mvrhel2 | ok. | 00:09.00 |
| I feel pretty confident that the fix is low risk of causing any problems | 00:09.23 |
| but just wanted to warn you about what is looming | 00:09.41 |
henrys | what else do you have promised for 9.04? or are you going for the next out of bound release? | 00:12.41 |
mvrhel2 | henrys: I think all my promises are now in | 00:13.31 |
| I was hoping though to get this gray to K fix in too | 00:13.48 |
Robin_Watts | I've fixed the SEGVs, but have lots of diffs. | 00:14.15 |
henrys | mvrhel2:well that's good news I guess we'll talk a lot about the release at the meeting tomorrow | 00:15.08 |
mvrhel2 | henrys: there are some smaller things I would not mind tending related to handling of Cyan, Magenta and Yellow when they are separation and DeviceN colors but those things could get pushed off until after the release. Depends upon how quick I am | 00:15.24 |
Robin_Watts | mvrhel2: Before I go to bed... | 00:15.47 |
| http://ghostscript.com/~regression/robin/ | 00:15.54 |
mvrhel2 | oh looks like some regressions | 00:16.18 |
Robin_Watts | The lack of patterns is going to be my fault, but the cups ones look interesting anyway. | 00:16.19 |
| 0 looks like it's wrong anyway. | 00:16.32 |
| likewise 17 | 00:16.45 |
mvrhel2 | hehe yes | 00:16.55 |
Robin_Watts | and 34. | 00:16.58 |
mvrhel2 | yes. I wonder if the pbmraw has the same issue? | 00:17.24 |
Robin_Watts | No. That'd be 2, for example. | 00:17.38 |
mvrhel2 | oh. I bet it is some polarity issue | 00:17.47 |
| I think the cups device has the opposite polarity to pbmraw | 00:18.01 |
Robin_Watts | oh, but 2 is non banded. | 00:18.03 |
| anyway... I'll look into the ones I broke tomorrow. | 00:18.21 |
mvrhel2 | oh that too | 00:18.23 |
| looks like you made some great progress though | 00:18.32 |
Robin_Watts | hopefully. | 00:18.44 |
| night all. | 00:18.47 |
mvrhel2 | have a good night | 00:18.55 |
| dinner time here | 00:20.29 |
| bbiaw | 00:20.31 |
marcosw | if anyone is interested in a cluster node woot.com is selling an HP i7 @ 3.4 GHz with 8 gigs for $699.99 | 05:10.46 |
mvrhel2 | good night all | 05:44.14 |
malc_ | tor8: hejsan. around? | 08:33.04 |
tor8 | morning malc_ | 08:33.20 |
malc_ | tor8: just did a pull and noticed text branch, what's going to change there? | 08:33.57 |
tor8 | malc_: two things, mostly. new and improved heuristics for detecting line breaks. grouping the text into blocks/lines/spans (rather than only spans as it was before) | 08:35.19 |
| this is in the text extraction device, used for copy-paste | 08:36.04 |
malc_ | tor8: nice.. hopefuly ARM ARM text will be easier to handle.. | 08:36.08 |
tor8 | forgive me, "ARM ARM" text? | 08:38.22 |
Robin_Watts | ARM Archtecture Reference Manual | 08:38.33 |
tor8 | ah, that one! | 08:38.43 |
| Robin_Watts: I have a funky test case from customer K | 08:39.19 |
Robin_Watts | For what? text extraction? | 08:39.39 |
tor8 | where the heuristics don't work all that well | 08:39.40 |
| yeah | 08:39.44 |
kens | Can I have that file too please ? | 08:39.55 |
Robin_Watts | Ah, right. | 08:39.58 |
tor8 | it's a page with a mish-mash of images with captions, so a lot of randomly placed blocks of text | 08:40.05 |
| sometimes a line from one block will continue into another block, but not regularly | 08:40.29 |
Robin_Watts | I spotted that zeniko had raised a bug with the clipping stuff (saying that text clips too much) | 08:40.40 |
tor8 | yeah, I think that the font bboxes are not reliable enough in the general case | 08:40.58 |
Robin_Watts | tor8: Probably a matter of tuning some thresholds to stop lines being added to one another wrongly. | 08:41.09 |
tor8 | or is it a mismatch with the "accumulate" argument to the clip_text functions | 08:41.35 |
kens | tor8 can you point me to the file please ? | 08:41.37 |
| Sorry, my router is having a bad day today. Did I miss anything ? | 08:44.57 |
tor8 | kens, Robin_Watts: /home/tor/captions.pdf on casper (not a public file) | 08:45.01 |
kens | THanks tor8 | 08:45.08 |
tor8 | no, I waited until you came back to paste :) | 08:45.10 |
kens | OK got it, thanks tor8 | 08:46.34 |
tor8 | Robin_Watts: the "concept 1.1" heading ends up totally out of whack. "concept .1" in one place, and the middle "1" in a block of its own | 08:47.43 |
| which just means, I've got more work to do :) | 08:48.27 |
| kens: are you working on the text device for ghostscript now? | 08:48.56 |
kens | Have been for some time tor8 | 08:49.04 |
| I'm using an old Adobe flyer for Adobe Type Manager as my current test file | 08:49.28 |
tor8 | ah! how is progress? | 08:49.28 |
kens | I can get Unicode text out for files with ToUnicode CMaps or GlyphNames2Unicode tables. | 08:49.46 |
tor8 | can you point me to that file? | 08:49.52 |
kens | No, but I can send you a copy ;-) | 08:50.06 |
tor8 | glyphnames2unicode, that'd be the adobe glyph list? | 08:50.19 |
kens | For files without Unicode info, I look at the glyph names. For glyph names beginning 'uni' I use the following digits as Unicode values. | 08:50.37 |
| No, glyphNames2Unicode is a PostScript extension by Adobe which gives Unicode values, just lie a ToUnicode cmap | 08:51.03 |
| If the glyph name doesn't begin 'uni' then I fall back to the Adobe Glyph List :-) | 08:51.18 |
| WHich can result in one glyph name becoming up to 4 separate Unicode values. | 08:51.37 |
| If that fails, then I fall back to using the character code. | 08:51.49 |
| Which will work (up to a point) even for PCL input. | 08:52.19 |
| There's a lot still to do, but I'm hoping to stick an alpha version in the next release. | 08:52.50 |
| Which will probably work at least as well as ps2ascii ;-) | 08:53.06 |
tor8 | sounds much like what mupdf does, but I have the advantage of being able to do it before the graphics library sees things :) | 08:53.28 |
| since the fitz graphics library takes both glyphs and unicode characters, at the same time, in its interface | 08:53.54 |
kens | That doesn't hurt too much. At least I get everything consistent nad only haev one matrix to worry about :-) | 08:54.02 |
tor8 | kens: do you do anything special with the surrogate pair values in the AGL? | 08:54.57 |
| or wait, am I confusing them with the surrogate pairs in the UCS2 CMap resources.. | 08:55.23 |
kens | I think maybe yes. | 08:55.35 |
| The AGL just matches glyph names to Unicode values. | 08:55.46 |
| Some (especially Hebrew) glyph map to multiple Unicode points, like Latin accented glyphs, eg Aumlaut could be two unicode points (there is actually a single one, but you get my drift) | 08:56.31 |
tor8 | yeah, plenty of one-to-many mappings in the AGL | 08:57.06 |
kens | Yes, that's the thing. Caught me out initially but I cater for it now. | 08:57.20 |
ManDay | tor8: ping | 08:58.22 |
tor8 | hm, I think I punted on them :/ | 08:58.24 |
| morning ManDay | 08:58.31 |
ManDay | hi! | 08:58.47 |
tor8 | kens: I should put that on my TODO list | 08:58.56 |
ManDay | i wanted to ask whether your reader is anything like ready | 08:59.02 |
tor8 | ManDay: afraid not, other projects keep derailing me :( | 08:59.16 |
ManDay | aw ;-( | 08:59.25 |
tor8 | then there's that whole, "agh! need to write UI code! procrastination time!" :) | 08:59.58 |
| I do have XCB based image drawing code that works quite well | 09:00.26 |
malc_ | blah | 09:00.40 |
| xcb shmxcb | 09:00.43 |
| it will be dog slow anyway | 09:00.49 |
tor8 | compared to using opengl textures, yeah, most 2d pipelines will be dog slow | 09:01.23 |
kens | tor8 its easier for me, because I don't need to carry hte mutliple Unicode representations around. | 09:01.32 |
| tor8 do you want a copy of this Adobe flyer ? | 09:01.41 |
tor8 | kens: yes, please. | 09:01.48 |
kens | OK, in the mail | 09:01.55 |
tor8 | is it a private doc or can it go in the public mupdf test suite? | 09:02.09 |
kens | I would think it can be public, its advertising from Adobe (and old at that) | 09:02.34 |
malc_ | tor8: btw. how's xcb image drawing any different from regular xlib drawing? | 09:02.38 |
tor8 | kens: well, I do allow for n-to-m mappings in the fitz interface, so it's just laziness (and data structure design, for storing the AGL without wasting a lot of memory) | 09:03.08 |
kens | I'm afraid I probably waste a lot of memory, I have the AGL built in, glyoh name strings and Unicode code points. | 09:03.46 |
tor8 | malc_: more direct to the wire protocol, but no significant difference. there's still zero help in converting a known image to the format the server expects, unless you use the oh-so-slow per-pixel "allocate a color" and XPutPixel | 09:04.29 |
| kens: http://git.ghostscript.com/?p=mupdf.git;a=blob;f=pdf/data_glyphlist.h that's the current structure. I'll need to add a count to every entry in one of the tables. | 09:05.22 |
malc_ | tor8: direct to the wire?? there's no much manipulation going on (with mitshm version at least).. | 09:05.52 |
tor8 | hm, or just another table, with the counts as bytes | 09:05.55 |
| malc_: X11 does put another layer of abstraction on before you get to what actually gets sent over the socket | 09:06.37 |
kens | tor8 I tackled it differently. I have 4 tables, single, double, triple and quad Unicode values. I search each table in turn looking for matches. Of course I drop out as soon as I search past the sorted glyph name. | 09:07.14 |
tor8 | ken: that works too I guess :) | 09:07.55 |
kens | But obviously my requirement is quite different. | 09:07.56 |
malc_ | tor8: there's not much being sent over the socket in mitshm :) i written my share of direct to the wire X stuff, hence me being puzzled by your remarks | 09:08.48 |
kens | tor8 file is on its way | 09:09.23 |
tor8 | malc_: well, maybe I'm confusing it with the xcb-image library which is dreadful. useless wrappers that did nothing but pretty up and confuse the api. | 09:10.03 |
Robin_Watts | power going off here. back soon, I hope. | 09:10.28 |
tor8 | malc_: I wrote the X11 library for Go | 09:10.31 |
malc_ | tor8: Pike made you his bitch... sorry for the language (pun intended) | 09:11.11 |
tor8 | malc_: I've been his, well, for over a decade... used his editor and derivatives of it for a long time now :) | 09:12.22 |
malc_ | Acme? | 09:12.37 |
tor8 | and Wily before that | 09:12.42 |
malc_ | Acme is too mousy by the descriptions i've read.. (never tried it myself) | 09:13.13 |
tor8 | it's very mousy indeed, to good effect IMO | 09:16.49 |
| the mouse chording turns the mouse into a powerful tool. the only drawback is that it really does need a proper 3-button mouse. | 09:17.47 |
| like the HP DY651A | 09:18.34 |
malc_ | hmm, looks like you know your rodents by name, meaning that we will never be on the same page | 09:20.14 |
tor8 | :) | 09:20.46 |
malc_ | tor8: so how is go in your opinion? | 09:21.19 |
tor8 | malc_: I haven't actually had time to use it very much :( | 09:22.06 |
| but if I were starting a new project on my own I'd probably use it today | 09:22.48 |
malc_ | tor8: so you write X protocol bindings just for the heck of it.. neat | 09:22.55 |
tor8 | what better way to learn? ;) | 09:23.08 |
malc_ | write go in go ofcourse! | 09:23.17 |
| and i mean the game | 09:23.27 |
tor8 | the concurrency model in Go is (IMO) done right. so much much much better than what I had to endure ten years ago when I had to do a job in Java. | 09:24.56 |
malc_ | tor8: you mean channels as opposed to low level stuff like locks? | 09:25.57 |
tor8 | yup. | 09:26.20 |
malc_ | you should try erlang then :) | 09:26.35 |
tor8 | the lock and shared memory model blows chunks | 09:26.46 |
malc_ | not only it's like that it's also swedish! | 09:26.48 |
tor8 | I have, but not written anything serious in it. I've written more prolog than erlang, if you can believe it! | 09:27.08 |
malc_ | tor8: prolog is so 20-th century, real coders use mercury or oz :) | 09:27.35 |
tor8 | I know, joe's english is a bit... swedish :) | 09:27.40 |
| ugh, don't get me started on mercury... c is not a good intermediate language! | 09:27.57 |
| not for compile times anyway :) | 09:28.18 |
malc_ | tor8: hah, there's one funny thing about Joe (Armstrong i presume).. his thesis (pdf) has nice ligature for 'ft' which maps to 'd' so.. when selecting text (in say mupdf) you get 'sodware' instead of 'software' :) | 09:28.55 |
tor8 | malc_: armstrong, yes. hah, that's a funny mapping :) | 09:29.29 |
kens | tor8 FWIW my code does what I expect it to with captions.pdf. But its probably not as comprehensive as your and Robin's code. It also (like adobe.pdf) is losing text somewhere. I need to fix that today. | 09:29.38 |
malc_ | tor8: yeah compiling to C blows goats.. | 09:29.39 |
tor8 | kens: the ATM flyer makes for a great test case. thanks! | 09:30.47 |
kens | No problem, I'm glad you think it s a good test cae too, make me more confident about using it. | 09:31.09 |
tor8 | kens: you're just emitting the text in the same order it comes in right? | 09:31.31 |
kens | No :-) | 09:31.38 |
tor8 | oh! | 09:31.43 |
kens | I have two methods. | 09:31.45 |
| First emits text as it is encountered, it is emitted with all sorts of decoration like position wiring mode, font name, rendering mode etc. | 09:32.14 |
| That one is for those who want to do it themselves. | 09:32.22 |
| The other tries to emit just text. | 09:32.35 |
| THe 'just plain text' option consolidates 'nearby' text fragments to make rows, then tries to gather rows together. | 09:33.02 |
| Ideally it should emit something broadly the same as the original text. | 09:33.18 |
| Its only partially complete, because I don't cater for the case where text runs start in the middle of the page. | 09:33.45 |
tor8 | ah, right. you got any fancy algorithms for the second phase? it's what robin and I have been toying around various ideas for. | 09:34.04 |
kens | So the adobe flyer has hte columns not lining up properly. | 09:34.08 |
| No fancy algorithms I'm afraid :-) | 09:34.19 |
tor8 | right, so you're trying to do a line-by-line scan of the text with columns preserved in the plain text layout? | 09:35.01 |
kens | Yes, exactly so. | 09:35.13 |
tor8 | right. we're trying to separate the columns instead :) | 09:35.22 |
kens | I thought that was the case. I could do that too of course. Maybe I should add that as an option. | 09:35.39 |
tor8 | group the paragraphs and columns into "blocks" of lines | 09:35.52 |
| I was thinking I should look into how JBIG2 encoders work, when they decide what a "symbol" is. maybe the same approach can be used to group characters into paragraphs of text. | 09:36.46 |
kens | Yes, I think I can do that fiarly readily. It means another loop of reordering but that's not a problem. Hmm, actually I think it means replacing the second loop. | 09:36.55 |
| tor8 I don't hink encoders know, they have to be told. | 09:37.14 |
| But I'm not really sure, its been a long time since I looked at JBIG2 | 09:37.34 |
tor8 | ocr engines must use a similar approach, no? to detect individual characters. | 09:37.37 |
kens | Again, its 30 years since I worked on OCR. But back then the idea was multiple passes. One cleans up thescanned data, then feature extraction, then m,atching to shapes. | 09:38.18 |
tor8 | feature extraction, that's the pass that splits into lines and characters? | 09:38.39 |
kens | It could be very different by now | 09:38.40 |
| tor8 basically edge detection | 09:38.50 |
| But after OCR the packages presumably use positional information to build the outptu text. | 09:39.20 |
tor8 | I have no idea how OCR engines work :) But I know JBIG2 and DjVu dumps characters as individual "symbols" and that must be gotten from somewhere :) | 09:39.32 |
kens | Normally the scanner looks for contiguous white space round a character. | 09:40.04 |
| After cleaning up stray pixels | 09:40.12 |
tor8 | hmm, maybe we should just output the character and positions for further processing by an OCR package :) | 09:40.20 |
kens | Well, that's what my first option is for :-) | 09:40.31 |
| But I thought I'd have a go at the more complex result, for the people who might want such a thing. | 09:41.00 |
tor8 | people are certainly asking for it for mupdf | 09:41.39 |
kens | Seems to be quite a demand in GS too, people keep on using ps2ascii :-( | 09:41.56 |
| Even though I keep telling them it won't work properly | 09:42.08 |
| reboot router brb | 11:07.04 |
Robin_Watts | mvrhel2: Morning. Got a mo ? | 15:22.13 |
ray_laptop | morning, all | 15:33.40 |
kens | Hi ray | 15:33.57 |
mvrhel2 | Hi Robin_Watts: I am back | 15:36.56 |
Robin_Watts | mvrhel2: This pdf14 rabbit hole keeps getting deeper. | 15:37.50 |
| Lots of places seem to say "oh, the rectangle is set up reversed for some reason - let's fix it". | 15:38.15 |
| rect is always the bounding box of the buffer, and I'd hoped that bbox was the bounding box of the touched bit, but alas, that doesn't seem to be the case. | 15:39.39 |
| bbox is frequently set to be the same as rect. | 15:39.51 |
| Who originally wrote this code? | 15:40.10 |
| I can't think of a purpose of having 2 bounding boxes for the same buffer unless one is supposed to be 'complete' and one is supposed to be 'dirty', but I'd like to be sure. | 15:43.00 |
| Maybe that was the intent, and it's just gotten eroded over the years. | 15:43.11 |
mvrhel2 | Raph originally wrote it | 15:44.14 |
Robin_Watts | ok, so we can't easily ask if that was the original intent. | 15:44.36 |
mvrhel2 | I do think there should be 2. One that is touched and one that is the group size | 15:44.57 |
kens | We can certainly ask him | 15:44.59 |
mvrhel2 | It doesnt matter. We should do it the correct way | 15:45.16 |
Robin_Watts | mvrhel2: Right. I agree that there should be 2. | 15:45.19 |
mvrhel2 | so we should go ahead and use the rect to keep track of the touched regions then yes? | 15:53.08 |
Robin_Watts | use bbox to keep track of the touched regions. | 15:58.10 |
ray_laptop | I also think that we want to keep the original buffer rect (that was used to create the transparency group), but want to maintain a 'marked' (or dirty) bbox rect within that | 15:58.15 |
Robin_Watts | I am tempted to rename bbox to dirty | 15:58.18 |
ray_laptop | 'marked' is not as dirty ;-) | 15:58.39 |
mvrhel2 | a rename would be a good idea | 15:58.47 |
Robin_Watts | ray_laptop: There ARE already 2 bboxes. rect and bbox. | 15:58.52 |
| rect = the buffers total rectangle. | 15:59.05 |
ray_laptop | Robin_Watts: right, I thought someone was suggesting that we didn't need two | 15:59.19 |
Robin_Watts | bbox is intended to be the 'marked' section, but is kept inconsistently. | 15:59.32 |
| ray_laptop: No, we all agree that we want two. It's just a shame the current code fails to keep it consistently. | 15:59.56 |
| So I might do a rename here. Preferred names ? | 16:00.13 |
henrys | so I guess we should start talking about the release (again) | 16:00.39 |
Robin_Watts | I'd go with 'dirty' personally, but could live with 'marked'. | 16:00.43 |
ray_laptop | the terminology might be less confusing if we used 'bbox' for the rectangle that comes from the PDF BBox, 'rect' is just sort of ambiguous. Then 'marked' or 'dirty' for area we've painted | 16:01.13 |
Robin_Watts | ray_laptop: Right. But that's a rename I'd want to do in 2 stages :) | 16:01.41 |
henrys | can everyone go through their customer, p1 and p2 bugs and see if you want anything in the release? | 16:01.43 |
ray_laptop | Robin_Watts: I am fine with 'dirty' -- I was just kidding | 16:01.44 |
henrys | chrisl:will we have a web page this time? | 16:02.19 |
chrisl | henrys: I'll try, I'm optimistic | 16:02.40 |
henrys | there is still no bug for the unicode problem and we want that in right? | 16:03.22 |
chrisl | oh, I thought Ray had raised a bug on it - yes, we should try to get it sorted, I think | 16:04.00 |
henrys | Robin_Watts, mvrhel2:with robin's change we get down to 30 minutes but adobe is around 3 what else is missing in handling stars.pdf? | 16:05.09 |
Robin_Watts | henrys: I haven't committed yet. | 16:05.21 |
| It's pandoras box. | 16:05.35 |
| Assuming I can fix pdf14 so that it correctly carries around the dirty rectangles, and only blends what it needs to, that will fix stars.pdf, and we'll be sorted. | 16:07.23 |
henrys | chrisl:when can we create a branch - I really don't like slowing down development for release - that is one of the things we were supposed to do better with git? | 16:07.32 |
mvrhel2 | henrys: I don't know. Robin_Watts: with you fix what does the profiling show? | 16:07.40 |
Robin_Watts | That should give us the 30 minute figure. | 16:07.46 |
| mvrhel2: I haven't got a fix that I'm happy to profile. | 16:07.59 |
mvrhel2 | Robin_Watts: maybe you should make a branch | 16:08.07 |
Robin_Watts | mvrhel2: I may well. | 16:08.17 |
chrisl | henrys: well, I was planning on creating the 9.04 branch on Friday (22nd) | 16:08.24 |
mvrhel2 | then we can share it and profile it for stars at least | 16:08.25 |
| 22nd... | 16:08.38 |
ray_laptop | chrisl: I thought you were going to open the unicode bug, sorry. I'll do that right now. I'll make it P1. | 16:08.44 |
mvrhel2 | there are a few things we want to get into 9.04 | 16:08.49 |
Robin_Watts | chrisl: We can create a branch now for us to work on, right? That won't affect you? | 16:09.04 |
mvrhel2 | one is having ray move the icc_dir to the libctx | 16:09.05 |
chrisl | Robin_Watts: yep, that won't bother me. | 16:09.22 |
henrys | mvrhel2:I thought that was done | 16:09.37 |
marcosw_ | mvrhel2: is the object based rendering intent to the point where it should be tested? | 16:09.40 |
mvrhel2 | henrys: not in the trunk | 16:09.45 |
| only in the 9.03 special release version | 16:09.57 |
| sounds like a beer | 16:10.00 |
chrisl | mvrhel2: creating the release branch isn't necessarily "code freeze" it just gives us more control/awareness of what actually goes into the release - without holding up development on master. | 16:10.25 |
henrys | IMHO everything should go to trunk then chrisl can cherrypick. | 16:10.29 |
mvrhel2 | I agree | 16:10.40 |
henrys | ray_laptop:are you good with that? | 16:11.15 |
chrisl | henrys: some stuff for 9.03 was exceptional on that front, cherry-picking from master should be the norm. | 16:11.21 |
mvrhel2 | marcosw_: the object based rendering is in the code. It would be good perhaps to have a subset of files and conditions to test | 16:11.54 |
henrys | chrisl:yes like disabling unicode ... | 16:11.57 |
ray_laptop | I am good with creating a 9.04 branch, that gets published, and only tagging it when we release. | 16:12.30 |
chrisl | henrys: and the ICC path stuff: it wasn't clear that was the final solution, or just an interim one for 9.03. | 16:12.55 |
Robin_Watts | I personally think the branch should be called ghostpdl-9.04 and the release tag should be ghostpdl-9.04-release | 16:13.06 |
mvrhel2 | there are 2 things that I want to get into 9.04 which are going to have significant diffs during the cluster push | 16:13.11 |
chrisl | ray_laptop: sorry I got the wrong end of stick on the Unicode bug front..... I thought you'd done it | 16:13.18 |
mvrhel2 | one is getting gray to map to K in CMYK by default | 16:13.25 |
ray_laptop | and I like chrisl 's suggestion of naming the branch differently to the eventual tag ! That created confusion w/ ghostpdl-9.03 | 16:13.31 |
mvrhel2 | the other is that I want to replace the SWOP CMYK profile and the sRGB profile with our own versions | 16:13.40 |
Robin_Watts | ray_laptop: Me too. But the branch should have the simple name. | 16:13.51 |
ray_laptop | chrisl: np. I'm entering the bug right now. | 16:13.52 |
Robin_Watts | And the tags should have -rc1, -rc2, -release etc. | 16:14.06 |
henrys | marcosw_:have you been checking your email scott said he was having problems reaching you and I didn't hear back from you yesterday. | 16:14.18 |
ray_laptop | how about just 904 or gs904 for the branch | 16:14.20 |
chrisl | Hmm, don't like just the number | 16:14.42 |
Robin_Watts | because it's in the nature of things that we'll have multiple tags for a single branch. | 16:14.44 |
ray_laptop | IMHO we should keep the release as the name "ghostscript-9.04" and "ghostpdl-9.04" | 16:14.57 |
Robin_Watts | I'd really rather keep ghostpdl-9.04 personally. It's clearer. | 16:15.03 |
| ray_laptop: Well, in git, tags and branches are really the same thing. | 16:15.17 |
ray_laptop | Robin_Watts: we've traditionally had both | 16:15.18 |
marcosw_ | henrys: I checked my email this morning but overlooked the email from Scott. | 16:15.34 |
Robin_Watts | so people asking git for 'ghostpdl-9.04' will get the right thing. | 16:15.40 |
ray_laptop | Robin_Watts: not exactly -- different refs directories and conflicting names confuses git | 16:15.47 |
Robin_Watts | ray_laptop: They are the same in the sense that they are just references to a commit state. | 16:16.14 |
henrys | marcosw_:he wants you to contact that potential customer - I forwarded you email yesterday. | 16:16.16 |
marcosw_ | I'll do so right after the meeting. | 16:16.29 |
henrys | thanks | 16:16.34 |
marcosw_ | in terms for the release I think that http://bugs.ghostscript.com/show_bug.cgi?id=692074 should be blocker. it breaks cups output for a bunch of files. | 16:16.41 |
Robin_Watts | They go in different directories, but as git looks in both, it's a somewhat arbitrary difference. | 16:16.42 |
ray_laptop | we may want to drop the ghostscript-9.04 tag later (since it pulls in the whole tree), but distros, etc. are used to the ghostscript-X.XX names | 16:16.54 |
Robin_Watts | ray_laptop: Sorry? As I said, tags and branches have EXACTLY the same meaning. | 16:17.31 |
| dropping one, won't cause "less of the tree" to be pulled in. | 16:17.58 |
mvrhel2 | ok. I will dig into 692074 | 16:18.07 |
Robin_Watts | and in fact with git, there is no concept of "just part of the tree". | 16:18.10 |
| Oh, sorry, I see what you mean. | 16:18.30 |
| Yes, well, having a ghostscript-9.04 ref as well as a ghostpdl-9.04 is not a problem. | 16:18.56 |
marcosw_ | mvrhel2: let me know if you need help testing; Robin_Watts wrote a cups conversion program that probably can be used on Windows (the readcups.c that I wrote requires a library that probably isn't available on windows). | 16:19.25 |
henrys | ray_laptop:is compile inits finished, can it simply be cherrypicked back to trunk? | 16:19.46 |
Robin_Watts | marcosw_: I think I just updated bmpcmp to read cups files. | 16:19.55 |
mvrhel2 | ok. so can we run the cups device on windows now? | 16:19.58 |
Robin_Watts | mvrhel2: Yes. | 16:20.04 |
mvrhel2 | ok. well this should be easy to track down then | 16:20.15 |
| marcos: did you see my earlier post that I am going to be doing some commits that will probably have diffs in every file | 16:20.51 |
henrys | marcosw_:I think you had another customer request from kens and Raed if I understood the exchange correctly. | 16:20.56 |
kens | Indeed :-) | 16:21.04 |
mvrhel2 | but they should be minor color changes | 16:21.04 |
marcosw_ | Robin_Watts: right you are. If needed I can write a cupstopbm.c based on your code that doesn't require a library. | 16:21.06 |
| mvrhel2: yes :-( | 16:21.12 |
Robin_Watts | git cluster bmpcmp -t 16 | 16:21.40 |
mvrhel2 | I am debating on if I should do them as 1 or 2 commits | 16:21.41 |
Robin_Watts | That will bmpcmp and only show ones where there is a difference of more than 16. | 16:22.11 |
mvrhel2 | they are different in that one is the gray to K fix | 16:22.13 |
| and the other is the change in the profiles | 16:22.17 |
| but being both minor color changes I am leaning toward doing them as one commit | 16:22.36 |
| Robin_Watts: how does that work with pkmraw? | 16:22.58 |
Robin_Watts | magically! | 16:23.06 |
alexcher | mvrhel2: small commits help to find regressions. | 16:23.11 |
mvrhel2 | I realize that alexcher | 16:23.20 |
Robin_Watts | bmpcmp converts everything to 8bit grey or 888rgb internally. | 16:23.30 |
mvrhel2 | but having to go through 20000 diffs twice is a pain | 16:23.33 |
Robin_Watts | and the difference is done there. | 16:23.35 |
chrisl | Robin_Watts, ray_laptop: any conclusion on the branch/tag names? As I said in my e-mail, my proposal was to call the branch "ghostpdl-x.yxB" and the tags "ghostpdl-x.yz" and "ghostscript-x.yz" - in order to avoid the name clash, and keep the tag names consistent | 16:23.39 |
mvrhel2 | ok. I will do 2 commits | 16:23.46 |
ray_laptop | henrys: sorry. I think all of the COMPILE_INITS fixes are already in the master | 16:23.51 |
Robin_Watts | chrisl: I think we'd be potty to try to call the tags ghostpdl-9.03 | 16:24.11 |
henrys | ray_laptop:oh mvrhel2 just told me 9.03 only | 16:24.27 |
Robin_Watts | As has been shown by the release that happened last week, that's just setting ourselves up to fail. | 16:24.39 |
mvrhel2 | hmm | 16:24.42 |
chrisl | Robin_Watts: eh? Why? | 16:24.50 |
ray_laptop | chrisl: I was proposing a shorter name for the branch: gs904 or even just 904 (but git may try and use 904 as a shortform SHA1) | 16:24.52 |
chrisl | ray_laptop: okay, I'm happy with that. | 16:25.15 |
Robin_Watts | Because you prepare a release, you build it, you tag it, and oops, you find a bug that means you've got to pull something else in. | 16:25.16 |
| so the tag is useless, and you've used your one and only magic tag. | 16:25.34 |
| Much better to have the branch as the short name. | 16:25.51 |
| Then you tag as ghostpdl-9.04-rc1, ghostpdl-9.04-rc2, ghostpdl-9.04-release | 16:26.17 |
chrisl | No, I'll do -rcX tags, then use that as the basis for the final release | 16:26.25 |
ray_laptop | Robin_Watts: I agree that the branch should be a short name (even shorter than ghostpdl-9.04) since it makes switching back and forth with other branches easier | 16:26.37 |
Robin_Watts | and if you find a bug, that's fine, you just do a ghostpdl-9.04-release2 | 16:26.39 |
chrisl | well, then nothing to stop you doing a ghostpdl-9.04-2 tag | 16:27.20 |
ray_laptop | Robin_Watts: we can't have a re-release. Once we release, that's it, we have to bump the number | 16:27.29 |
Robin_Watts | chrisl: Right, but you've negated the point of having the nice short name. | 16:27.58 |
henrys | kens:anythong for the meeting? | 16:28.08 |
kens | Nope. its quiet for me | 16:28.22 |
chrisl | Robin_Watts: but it is consistent with what's been done before | 16:28.23 |
ray_laptop | because gs doesn't keep track of anything but the X.XX number and when people report bugs, we woudln't be able to tell if they have release1 or release99 | 16:28.33 |
Robin_Watts | When we go back in history to hunt for bugs, we want to be able to jump back to ghostpdl-9.04, not have to remember how many attempts there were for each version. | 16:28.41 |
mvrhel2 | ray_laptop: I dont see the icc directory fix in master? | 16:28.42 |
ray_laptop | (shades of SP1, SP2, ...) | 16:28.47 |
Robin_Watts | ray_laptop: Right. | 16:29.06 |
mvrhel2 | I thought you had just put it in 9,03 | 16:29.31 |
Robin_Watts | But when we were producing 9.03, the tag had to be moved several times. | 16:29.31 |
ray_laptop | mvrhel2: oh, you mean moving the profiledir to lib_ctx. Sorry, you are right. | 16:29.34 |
| I will go ahead and do that, ASAP | 16:29.43 |
chrisl | Robin_Watts: haven't you just argued *for* the straight ghostpdl-9.04? | 16:29.44 |
mvrhel2 | ok thanks | 16:29.49 |
Robin_Watts | No. I've argued for that as the BRANCH name, | 16:29.55 |
mvrhel2 | so when you guys are done naming the baby, should I just plan on committing things to the master and then telling chrisl if I want it in the branch? | 16:30.29 |
chrisl | but checking out the branch doesn't guarantee you the release, the *tag* gets you the release. | 16:30.37 |
ray_laptop | I'd rather reserve the ghostpdl-9.04 for the release tag, and call the branch something shorter (to make it easier to type) | 16:30.50 |
chrisl | mvrhel2: yes, that's the plan. | 16:30.53 |
henrys | mvrhel2:I got lost in the release naming shenanigans - did marcosw_ agree to look at output? | 16:30.57 |
mvrhel2 | well he gave a frown.... | 16:31.08 |
marcosw_ | henrys: yes I did. | 16:31.13 |
henrys | well we can split it up I realize it is a lot. | 16:31.25 |
marcosw_ | if the differences are minor I automatically skip them; other than that I can look at 10,000 files in about an hour. | 16:32.14 |
henrys | alexcher:do you have anything for the meeting I think ken assigned a bug to you yesterday that was just supposed to be simplified and moved on. | 16:32.26 |
mvrhel2 | marcosw_: there is very little risk of any regressions. the main thing will be gray going to K only instead of composite CMYK and then maybe some minor changes when I change the profiles. If I am good, there may not be any diffs from the profile changes | 16:32.33 |
marcosw_ | mvrhel2: does that mean only psdcmyk and pkm will change? | 16:33.09 |
alexcher | henrys: I don't have anything for the meeting. | 16:33.12 |
| henrys: I'm rorking on the newly assigned bugs. | 16:33.36 |
henrys | chrisl:it would probably be good to look at each commit in 9.03 and make sure nothing was put in that also belongs on trunk but I think we have everything. | 16:33.36 |
mvrhel2 | marcows_: yes for the one commit it will be only CMYK based devices | 16:33.38 |
chrisl | henrys: okay, I'll do that - although I mostly want to forget about 9.03 completely :-( | 16:34.10 |
marcosw_ | the real issue is if we want to make sure the changes don't affect the the only weekly tested build variations (compile inits 0, luratech, 32 bit, etc). Since those take a week to test :-) | 16:34.17 |
henrys | chrisl:I think these out of bounds releases are bad for us. It's a huge context switch for everyone. | 16:35.00 |
Robin_Watts | chrisl: You're the one who has to handle the release, so the decision is yours. I feel I've made my case, so do as you see fit. If it all goes wrong though, I *will* say "I told you so" :) | 16:35.11 |
ray_laptop | henrys: I AGREE !!! | 16:35.25 |
marcosw_ | henrys: I'm thinking about adding a couple of cluster nodes: http://www.woot.com/ (presumably to Miles' office, though if mvrhel2 wants to have a warmer office this is a good opportunity). | 16:35.38 |
chrisl | Robin_Watts: the problem is, I don't feel we can just ignore the tag name convention. | 16:36.12 |
henrys | marcosw_:I think it would be cool to have a windows node if we could iron out the wrinkles, I am curious what the windows folks think of that. | 16:36.51 |
| ? | 16:36.54 |
marcosw_ | yeah, I know... | 16:37.05 |
Robin_Watts | henrys: I think having a windows cluster node would be awesome in terms of our testing (we can't spot windows build failures with clusters etc) | 16:37.40 |
henrys | okay 7 minutes past end of meeting - please check your bugs and make sure you have no blockers. | 16:37.45 |
alexcher | marcosw_: I thought that AMD is faster and cheaper. | 16:37.46 |
marcosw_ | wait, do you mean a windows machine for running cluster jobs or a box to run windows regressions? I | 16:37.49 |
Robin_Watts | but I also feel it's likely to be a pain in the backside. | 16:38.06 |
marcosw_ | alexcher: these are the latest i7 cpus at 3.4GHz and should be faster than the amd chip. | 16:38.26 |
Robin_Watts | ... to get working, and to get over the initial hump of mismatches. | 16:38.46 |
| marcosw_: Sandy Bridge ? | 16:38.58 |
marcosw_ | I think an overnight test to run windows regressions is doable, but a window cluster node is asking for trouble. | 16:39.10 |
mvrhel2 | off to the coffee shop. It is never going to warm up here in the NW. we have had a total of 78 minutes above 80 degrees this year | 16:39.20 |
henrys | marcosw_:I think there are issues with a windows node but no insurmountable - using cygwin to poll - nmake etc. | 16:39.36 |
kens | I'm off night all. | 16:39.38 |
marcosw_ | Robin_Watts: yes. though not the 2600k with the unlocked clock | 16:39.42 |
henrys | s/no/not | 16:39.44 |
mvrhel2 | bbiab | 16:40.38 |
Robin_Watts | marcosw_: So you were planning on buying them and taking windows off ? | 16:40.45 |
alexcher | bash on Cygwin can call windows executables, and pipes work. | 16:41.04 |
marcosw_ | henrys: I think it's not impossible, but I'd rather set up a overnight windows regression machine. | 16:41.20 |
henrys | marcosw_:okay maybe a good start. | 16:41.50 |
marcosw_ | Robin_Watts: yes, assuming we use them as a linux cluster node. I was going to set up windows in a virtualbox. | 16:42.04 |
henrys | and if one of the windows developers wants to try doing a node implementation they can go ahead and give it a go. | 16:42.18 |
marcosw_ | does windows finally have sshd | 16:42.39 |
| ? | 16:42.41 |
Robin_Watts | There are sshd's for windows. | 16:42.54 |
henrys | it's all very doable in cygwin but I'm afraid it will be too slow. | 16:45.54 |
Robin_Watts | And there will be the rsync nightmare all over again. | 16:46.32 |
| maybe that'll be OK cos it's only fetching... | 16:47.21 |
marcosw_ | bmcmp jobs send as well... | 16:47.49 |
henrys | marcosw_:I do think you should let a windows user set it up if we go that route you have enough on your plate and I know you like windows about as much as I do. | 16:51.17 |
marcosw_ | but uses scp, so perhaps not a problem. | 16:51.42 |
| henrys: thanks for the suggestion, I very much agree :-) | 16:52.16 |
henrys | making coffee brb | 16:52.22 |
marcosw_ | I need to run to school. I've replied to all the pending emails (I think) and will be around later today. | 16:54.13 |
chrisl | ray_laptop: ? | 16:54.23 |
ray_laptop | chrisl: yes ? | 16:54.40 |
chrisl | ray_laptop: the ICC path fixes don't seem to be in master, is that right? | 16:55.00 |
ray_laptop | chrisl: yes, I am working on that right now | 16:55.15 |
chrisl | ray_laptop: ah, great! I'll shut up then.... :-) | 16:55.32 |
ray_laptop | chrisl: it is NOT simple since some of the changes conflict | 16:56.07 |
chrisl | ray_laptop: I know, I was about to ask you to do it, because I feared I'd mess it up | 16:56.32 |
Robin_Watts | mvrhel2: pdf14_get_buffer_information | 16:57.48 |
| AIUI, that bundles up the information for the top of the stack pdf14 buffer into a 'fill_trans_buffer' structure, right? | 16:58.41 |
| And that fill_trans_buffer structure is then passed around to drawing functions that don't know anything about pdf14 buffers ? | 16:59.03 |
mvrhel2 | yes | 16:59.25 |
| well | 16:59.32 |
| the pdf14 mark_fill_rect draws into the trans_buff | 16:59.58 |
Robin_Watts | Right. | 17:00.09 |
| But some things (like the tiling functions) draw into it, without knowing about pdf14 buffers. | 17:00.25 |
mvrhel2 | yes exactly | 17:00.38 |
| that way they can get what they need to know about it | 17:00.50 |
Robin_Watts | Those functions don't update the dirty rectangle. | 17:00.57 |
mvrhel2 | ok. I was just going to say I may have missed that | 17:01.09 |
Robin_Watts | hence the code currently bales and says "it's all dirty!" | 17:01.12 |
mvrhel2 | ok | 17:01.19 |
Robin_Watts | that code *can't* update the dirty rectangle, because it doesn't have access to it. | 17:01.37 |
| I'd like to add a pointer from the fill_trans_buffer to the dirty rectangle data. | 17:02.04 |
| so that they can. | 17:02.10 |
mvrhel2 | ah yes | 17:02.13 |
| ok | 17:02.28 |
Robin_Watts | Now, in pdf14_get_buffer_information | 17:02.45 |
| it does: rect_intersect(rect, buf->bbox) | 17:03.14 |
| which makes no sense to me. | 17:03.26 |
mvrhel2 | ok. It is likely there is an issue there | 17:03.48 |
Robin_Watts | If we are preparing a buffer to be passed out to other rendering functions, then those rendering functions might CHANGE buf->bbox (by rendering outside the bounds). | 17:04.14 |
| So, unless this function is being used for something else that I don't understand, I'd like to drop that line. | 17:04.38 |
mvrhel2 | Robin_Watts: I don't remember what case had me put this in | 17:05.46 |
| In the transparency code there are some strange cases where the group bbox is basically empty but we need to handle things still due to the fact that the softmask can be defined outside the bbox | 17:06.52 |
| and affect things | 17:06.57 |
| but I don't think that was why I had that here | 17:07.04 |
| I would pull it and see if it makes any diffs | 17:07.15 |
Robin_Watts | ok. | 17:07.24 |
| The reason I was getting SEGVs the other day with a fix... damn phone. | 17:07.58 |
| ok. | 17:08.44 |
ray_laptop | Robin_Watts: how do I see the revision history of a branch (ghostpdl-9.03). In particular, I want to be able to see the diff from the state before aeb8d66 and know what it's predecessor SHA1 was (logg is confusing me and gitk doesn't help) | 17:08.48 |
Robin_Watts | git diff aeb8d66~1..aeb8d66 ? | 17:09.53 |
| ~1 gives you the predecessor commit of any commit, be it an SHA1 or a tag or a branchname or whatever. | 17:10.44 |
ray_laptop | Robin_Watts: thanks | 17:11.57 |
Robin_Watts | git logg includes --all, so it shows all branches. | 17:12.57 |
| hence saying: git logg ghostpdl-9.03 won't do anything different to git logg, I think. | 17:13.25 |
| mvrhel2: Sanity check here... | 17:18.17 |
| it's OK to merge a tos onto a nos where tos is a smaller size than nos, right | 17:18.36 |
| ? | 17:18.38 |
mvrhel2 | Robin_Watts: you mean to compose them yes? sure but the nos stays the same size and its dirty box becomes the union of its old one and the tos | 17:19.53 |
Robin_Watts | Right. | 17:20.00 |
| I've got a dirty rectangle being bigger than the whole rectangle and that's confusing the calculations here. | 17:20.23 |
mvrhel2 | oh its drawing outside the group bbox? | 17:20.44 |
Robin_Watts | no, it's almost certainly me doing something dumb. | 17:21.16 |
mvrhel2 | bbiab | 18:48.27 |
henrys | hallelujah! Shelly found a bug that is fixed in 9.03... this hasn't gone as I hoped... | 20:01.36 |
Robin_Watts | And our survey says... 12 differences. | 20:13.38 |
| all in cups files. | 20:13.51 |
henrys | how does something like that happen? | 20:20.16 |
Robin_Watts | no idea. running a full test now. | 20:20.57 |
kens | Cups uses weird colour spaces | 20:21.18 |
| tor8 #692354 is a customer issue. I'm guessing its the old 'butt images together' problem. | 20:22.24 |
tor8 | kens: yeah, that's why I ignored it... | 20:23.38 |
kens | Well, they've said they are a cusotmer now. | 20:23.54 |
| You need to follow up really, at least to explain what it is. | 20:24.05 |
| I've just mailed them to say that I've upped the priority | 20:24.21 |
| Sorry.... | 20:24.39 |
mvrhel2 | Robin_Watts: that is good news | 20:24.45 |
| does it still take 30 minutes to run though? | 20:25.07 |
tor8 | kens: right. | 20:25.36 |
mvrhel2 | hmmm I think my fix for the gray to K is going to be easier once ray_laptop gets the icc_dir moved. | 20:34.11 |
| I will wait to finish that up and go work on my blocking bug until then | 20:34.30 |
| Robin_Watts: how do I search the git logs for a particular SVN rev? | 20:37.19 |
| never mind | 20:37.45 |
| found it | 20:37.47 |
| oh this should be straight forward to fix | 20:38.06 |
henrys | 2 9.03 regressions already | 20:42.09 |
kens | THe ones from Phil ? | 20:42.19 |
henrys | yes | 20:42.50 |
kens | Not sure the second is a regression | 20:43.08 |
henrys | true | 20:43.26 |
kens | Probably a missing font, but I haven't checked | 20:43.39 |
Robin_Watts | http://ghostscript.com/~regression/robin/ | 21:00.28 |
| 13 differences in the full test. All cups. | 21:00.39 |
| Number 12 is... interesting. | 21:00.45 |
mvrhel2 | oh that is a progression | 21:02.21 |
Robin_Watts | oh, right. | 21:02.37 |
| my patch still doesn't get the subset of groups right when tiling. | 21:03.19 |
| It just sets the dirty rectangle to the xmin/xmax/ymin/ymax the tiling is called with. | 21:03.55 |
| but at least that decision is being made in a place where it could be right now. | 21:04.14 |
| I'm trying a run of stars.pdf now. | 21:04.22 |
| Damn. stars.pdf takes 30 mins and then falls over in a garbage collect. | 23:36.37 |
mvrhel2 | Robin_Watts: shoot what does the profiling show? | 23:46.17 |
Robin_Watts | no idea. | 23:46.28 |
mvrhel2 | shoot. I was sure what you were doing was going to fix this | 23:46.49 |
Robin_Watts | When I stop it crashing, then I'll profile it. | 23:46.54 |
| 300dpi works fine, in 1 minute 30. | 23:47.07 |
| 400dpi runs in 4 mins and then falls over. | 23:47.20 |
mvrhel2 | ok. in that case is it not doing the clist? | 23:47.23 |
Robin_Watts | presumably. | 23:47.30 |
mvrhel2 | i.e. is one doing clist patterns and one not | 23:47.32 |
| ok | 23:47.33 |
| hmm | 23:47.49 |
Robin_Watts | Doing a memento run with paranoia 1 now to see if I can spot any memory corruption. | 23:48.09 |
| this might take a while though, so I'll run it overnight. | 23:48.27 |
henrys | mvrhel2:I do have a fix for 692234 but I found another problem fixing it. Your new test file text_graphics_image.pdf crashes with x11cmyk - but 8.71 crashed too so it isn't a regression. | 23:52.11 |
mvrhel2 | oh wow. this one looks like it has been involved | 23:53.29 |
| Forward 1 day (to 2011/07/20)>>> | |