| | <<<Back 1 day (to 2013/01/07) | 2013/01/08 |
| Robin_Watts | henrys, tor8: I'll mail zeniko now. | 00:03.30 |
| henrys | Robin_Watts: thanks | 00:08.25 |
| JakeSays | question regarding the order of path elements - will they always be specified in a clockwise direction? i have a path that consists of moveto,lineto,lineto,lineto,closepath that denotes a rectangle that is drawn in a clockwise direction. just wondering if i need to deal with the case where its drawn in a counter clockwise direction | 00:10.31 |
| Robin_Watts | JakeSays: No. | 00:11.42 |
| JakeSays | ok. was afraid of that. thanks | 00:12.12 |
| Robin_Watts | You need to read up on path winding; it's no so much clockwise and anticlockwise as 'odd' and 'even'. | 00:12.17 |
| JakeSays | yeah. its been decades since i've worked with paths. | 00:12.49 |
| | however in this case i'm only dealing with paths that look like moveto,lineto,lineto,lineto,closepath | 00:13.19 |
| | at least i hope | 00:13.22 |
| Robin_Watts | Essentially, for any given point, conceptually you count how many times you cross an edge (and in what sense) as you move off to infinity. | 00:13.39 |
| | That sum tells you whether the point is inside or outside the point, according to the rule in play. | 00:14.14 |
| JakeSays | arent there two basic rules, even/odd and.. i cant remember the other. | 00:15.09 |
| Robin_Watts | non-zero | 00:16.14 |
| JakeSays | ah thats it | 00:16.23 |
| | however i have a feeling i'm being overly simplistic here. i'm trying to detect paths that represent rectangles, and i imagine there's a ton of ways to draw a rect | 00:16.56 |
| mmmwwww | Hello! Some friendly advice needed. There is a program that prints interesting tables of data, and I want to capture it. I was thinking one option is to setup a virtual printer for it to print directly to PDF and use existing tools to try and parse the interesting data out... or my other option | 00:29.29 |
| | may be to use redmon + ghostscript and print directly to ghostscript files. But I have no idea if this is a better or worse file format for trying to parse (or using existing tooling that can parse it for me) | 00:30.16 |
| | What would you kind folks suggest? | 00:30.25 |
| JakeSays | mmmwwww: i happen to be working on a similar problem. we're printing to pdf, then i'm parsing and interpreting them | 00:31.35 |
| saper | PostScript seems nicer to me to work with, and I can write PostScript around it | 00:32.09 |
| mmmwwww | JakeSays: :) | 00:32.18 |
| | I'm just not sure which has the better tooling to be able to parse it | 00:32.30 |
| saper | itext is nice to grok pdf | 00:32.47 |
| | check it out | 00:32.56 |
| JakeSays | well, we're using pdf right now because we have several hundred thousand pdfs to parse | 00:33.11 |
| | but eventually we'll switch to postscript | 00:33.20 |
| | saper: itext is java, right? | 00:33.59 |
| mmmwwww | from some simple googling, it seems that there is more documented tooling for PDF parsing | 00:35.28 |
| | I'm not overly concerned about which format I get the closed-source application to print with, my big concern is what is best to put in place so I can parse out all the interesting data again | 00:36.10 |
| | :) | 00:36.14 |
| JakeSays | yes, but i think ps is more accurate, but thats just a hunch | 00:36.14 |
| saper | JakeSays: yes | 00:36.17 |
| mmmwwww | JakeSays: are you parsing .pdf files into usable data? what toolset are you using for this? | 00:38.53 |
| JakeSays | mmmwwww: yes. i'm parsing pdfs that represent billing statements, and pulling out all of the billing data. i'm using a tweaked mudraw | 00:39.45 |
| | at least for the moment. | 00:40.03 |
| saper | interesting | 00:40.09 |
| JakeSays | not sure i'll end up with mudraw long term though | 00:40.12 |
| | these statements have useful rects and lines on them, so i'm trying to detect paths that represent lines/rects | 00:42.53 |
| saper | JakeSays: is the text inside readable? CID-encoded? or just graphics? | 00:43.21 |
| JakeSays | saper: its all truetype | 00:43.38 |
| | embedded truetype | 00:43.41 |
| | some is CID encoded, some isnt | 00:43.49 |
| saper | maybe it's easier to get postition of text bboxes and find out which is which by comparing them? | 00:51.58 |
| JakeSays | saper: what? | 00:52.25 |
| saper | if text is readable, I would just extract positions of the text to get the layout | 00:52.48 |
| JakeSays | i'm doing that | 00:53.04 |
| saper | and the lines and rectangles? | 00:53.14 |
| JakeSays | anchors | 00:53.19 |
| | the text floats | 00:53.27 |
| mmmwwww | I'm going to give pdfquery by jcushman a try | 00:53.47 |
| JakeSays | yeah python.. i'd rather not. | 00:54.27 |
| mmmwwww | thanks guys, goodnight! | 01:24.53 |
| JakeSays | i have a character that didnt get merged in to a span because of a difference in x of .001 | 02:35.40 |
| | hmm. it appears that in this instance the last character is printed first, which creates a line, then when the rest are printed they end upon a new line | 03:12.20 |
| chrisl | kens: if I'm reading this correctly, it *looks* like that "glyphs off by one" problem is because we're misreading the cmap table from the TTF. | 08:53.57 |
| kens | chrisl, sorry was away dumping sacks of broken glass at the tip. Mis-reading the CMAP subtable was more or less what I next thought of as the likely problem | 09:44.28 |
| | Especially since the same problem exists after conversion to PDF by pdfwrite. | 09:44.49 |
| chrisl | kens: np, I think I've found the the problem - another undocumented piece of crazyness :-( | 09:47.10 |
| kens | In Ghostscritp I assume ? | 09:47.22 |
| chrisl | Yeh, Freetype doesn't use the cmap table in this case because it's via the incremental interface | 09:48.22 |
| | Basically, in a format 4 cmap table, we can't ignore an empty segment (one whose start code and end code are the same), we have to "create" a one entry segment..... | 09:49.41 |
| kens | Oh, weird | 09:49.51 |
| chrisl | Well, we already do that, *but*..... | 09:50.06 |
| | it *seems* we shouldn't do that if the start code and end code are both zero - in that case, we *should* ignore it | 09:50.43 |
| kens | Oh wow! | 09:51.08 |
| chrisl | I need to implement it properly, and then clusterpush it, but that seems to be the problem | 09:52.34 |
| kens | Good to find it, must be a weird piece of font subsetting | 09:52.56 |
| | I'm trying to understand the pdfwrite image handling, my head hurts :-( | 09:53.50 |
| chrisl | Hmm, you have my sympathy! | 09:54.12 |
| kens | I think I'm going to rewrite the whole thing. | 09:54.45 |
| mace | ray_work: did you get Robin_Watts ? | 09:54.49 |
| kens | mace ray_work is in California, so he won't be online for a while (unless he's working *very* late) | 09:58.36 |
| mace | nods, figured he'd see his name mentioned in the logs etc later :) | 10:01.53 |
| | ditto Robin_Watts | 10:02.03 |
| kens | Yes, they should both read the logs | 10:02.17 |
| mace | cool the new website is live | 10:03.10 |
| kens | Yes, I think we switched over a week or two back, someone really hsould have told you | 10:03.32 |
| mace | it was vaguely mentioned in an email from ray at 5am our time as there is some new content wanted or something | 10:04.04 |
| kens | I guess I kmissed it (or wasn't cc'ed) | 10:04.20 |
| mace | wasn't cc'd i'm afraid :) | 10:04.51 |
| kens | Not a problem, I suspect I don't need to know ;-) | 10:05.06 |
| mace | there is a lot to be said for "the less you know.." :) | 10:05.35 |
| kens | Yes, I can't be blamed that way :-) | 10:05.46 |
| Robin_Watts | can't remember how to do editing on the new website. | 10:37.58 |
| | I'm sure mace showed me at some point, and I thought we'd shown Miles because he's edited stuff before. | 10:38.31 |
| | mace: What's the magic URL for the editing stuff again? | 10:39.33 |
| mace | /admin | 10:46.51 |
| | i wanted to check with you before getting back to Ray/Miles, to avoid confusing matters | 10:47.23 |
| Robin_Watts | And I can't remember by username/password. ass. | 10:48.13 |
| mace | want me to reset? | 10:48.26 |
| Robin_Watts | mace: please | 10:48.40 |
| chrisl | kens: I've put a notice on ghostscript.com about the pending license change. | 10:51.41 |
| kens | chrisl, nice one | 10:51.51 |
| | Hmm, I htink a MS update has broken my laptop | 10:53.37 |
| Robin_Watts | goes for haircut. back in 20 mins. | 10:57.16 |
| | tor8: ping | 12:55.34 |
| tor8 | Robin_Watts: . | 12:56.19 |
| Robin_Watts | damn. phone. | 12:56.34 |
| sebras | tor8: still too tired to type "pong"? | 12:57.44 |
| Robin_Watts | I have a possible fix for the openjpeg stuff. | 12:57.54 |
| | In order to cluster push the test I'd need to push my changes to the thirdparty openjpeg repo though. | 12:58.33 |
| tor8 | Robin_Watts: right. | 13:03.15 |
| Robin_Watts | You happy with me trying that? | 13:03.35 |
| tor8 | wonder if there's a convenient way for the cluster to pull submodules from different repos | 13:03.42 |
| | but disregarding that, you can push changes to a branch on the thirdparty openjpeg git and then remove that branch after testing | 13:04.04 |
| Robin_Watts | tor8: ok. | 13:06.17 |
| | except I don't have permission to push :( | 13:09.00 |
| tor8 | Robin_Watts: try again | 13:11.16 |
| Robin_Watts | fab. | 13:11.28 |
| | I've pushed to 'robin_test' | 13:11.35 |
| | Thanks. | 13:11.37 |
| henrys | I think Miles has high hopes about Affero but I suspect most of the server users are creating a separate process for our programs and will get around GPL that way. At least on a server there is less reason to have an integrated linked solution. We'll see. | 15:28.27 |
| kens | I htink you are probably correct | 15:28.50 |
| Robin_Watts | For people that don't alter ghoscript, Affero gains us nothing. | 15:30.17 |
| | For people that alter it, they have to publish their alterations. | 15:30.48 |
| | or seek an alternative license. | 15:30.56 |
| henrys | No if they link using the API we would ask they publish their source code. | 15:31.25 |
| Robin_Watts | Ah, right, yes. | 15:32.02 |
| | So: For people that don't alter gs and call it just as a binary, it gains us nothing. For people that either alter it, or link to it, we get to insist that their code is released (or that they take a commercial license) | 15:37.00 |
| | tor8, henrys, paulgardiner: Forms meeting in 10 ? | 15:54.48 |
| henrys | meeting in 5 minutes | 15:54.49 |
| paulgardiner | oh ok. | 15:55.04 |
| henrys | so is tor8 going to put the code up on Google Play? | 16:00.47 |
| | paulgardiner: glad you had a look at adobe and I agree with the goal. | 16:02.09 |
| Robin_Watts | To do that we need to register as an android developer, which means we need to set up a google account in the company name, and somehow pay for it, without getting it linked to one of our personal accounts. | 16:02.09 |
| | I tried that before under "android@artifex.com" and failed. Now we can never use android@artifex.com again. | 16:02.45 |
| henrys | how does the billing work? | 16:03.14 |
| paulgardiner | Did they link it based on your IP address? | 16:03.23 |
| Robin_Watts | You have to pay a fee, and I tried to pay it with google wallet. | 16:03.38 |
| henrys | when in Rome... | 16:03.57 |
| Robin_Watts | And because the google wallet I used was my personal account, it linked to that. | 16:04.05 |
| | And there is NO WAY TO UNLINK ACCOUNTS. EVER. | 16:04.32 |
| henrys | is it a one time fee? | 16:04.47 |
| Robin_Watts | It is. | 16:04.52 |
| henrys | so you can expense report it and we're done. I don't understand. | 16:05.28 |
| Robin_Watts | I don't care about the fee. I care that my carefully setup android@artifex.com email address is now unusable. | 16:05.35 |
| | So we need to set up a new email address, and reregister as a developer etc. | 16:06.05 |
| | and spin the payment roulette wheel again. | 16:06.16 |
| henrys | crazy | 16:06.41 |
| tor8 | Robin_Watts: want to try with android@mupdf.com? | 16:06.44 |
| Robin_Watts | It's not a huge problem. It's just massively annoying. | 16:06.50 |
| | tor8: That might make sense, yes. | 16:06.55 |
| paulgardiner | Might be worth using a less sensible address and then linking to that one when it all works out | 16:07.47 |
| Robin_Watts | paulgardiner: possibly. | 16:08.16 |
| | I will endeavour to get us registered on google play before next meeting. OK ? | 16:08.37 |
| tor8 | Robin_Watts: sounds good to me. | 16:08.51 |
| henrys | Robin_Watts: okay | 16:09.00 |
| | was there a fee at apple? | 16:09.29 |
| saper | Robin_Watts: I don't understand this affero change; changes are rarely accepted into the official repo and there is no licensing program for small guys... | 16:09.36 |
| tor8 | paulgardiner: take a look at int fz_highlight_selection(ctx, page, rect, out_bbox_array, out_bbox_max) | 16:09.52 |
| | henrys: there's an annual fee for apple | 16:10.14 |
| Robin_Watts | saper: "Changes are rarely accepted into the official repo"? For gs? | 16:10.25 |
| tor8 | paulgardiner: that should cover the basic text selection by dragging a rect | 16:11.01 |
| paulgardiner | tor8: That might be useful. Didn't know that was there. | 16:11.02 |
| tor8 | it has space for improvement | 16:11.06 |
| | paulgardiner: just added it recently, for the gtk+ viewer | 16:11.14 |
| | paulgardiner: there's a matching fz_copy_selection() function as well | 16:11.51 |
| Robin_Watts | gs is very complex, hence a lot of the time we get given 'fixes' etc that only work in some circumstances etc. Where fixes are well formed and work well, we accept them. This happens regularly. | 16:11.56 |
| paulgardiner | tor8: actually it may be easier not to use it becaue I have to avoid going to C for the sake of speed. | 16:11.59 |
| henrys | can we throw in the customer bug status into this meeting. How many openjpeg problems are there? | 16:12.01 |
| tor8 | paulgardiner: right. | 16:12.13 |
| | paulgardiner: are you pulling the fz_text_page stuff up into java classes then? | 16:12.25 |
| Robin_Watts | henrys: /home/support/693503/libopenjpeg contains 1282 files. | 16:12.57 |
| | So 641 problems, I think. | 16:13.09 |
| paulgardiner | tor8: I have a JNI method that returns the text with boxes and then I was writing java to select from that | 16:13.34 |
| Robin_Watts | BUT... I haven't checked them all yet. | 16:13.41 |
| paulgardiner | returns the text from the fz_text_page | 16:13.59 |
| Robin_Watts | OpenJPEG 2 is not a panacea - in fact, it has problems that 1.5 does not. | 16:14.10 |
| | I've opened issue 207 on the openjpeg bug tracker to try to get them solved (I suspect it's 1 problem). | 16:14.45 |
| saper | Robin_Watts: somet bountiable patches take forever to review; and small unimportant stuff like http://bugs.ghostscript.com/show_bug.cgi?id=692527 just stays there | 16:14.54 |
| paulgardiner | tor8: possibly I could use the function you just mentioned but I'd have to add separate locking for the fz_text_page | 16:15.03 |
| henrys | Robin_Watts:well feel free to assign some of it to alexcher et al. | 16:16.00 |
| | maybe we should just cherry pick from 2.0 | 16:16.21 |
| Robin_Watts | henrys: 2.0 looks like a nice upgrade - except for this one regression. | 16:16.43 |
| alexcher | OK | 16:16.58 |
| Robin_Watts | (Essentially, sometimes we get files that says "this is tile 6 of 5". Previous versions ignored that and continued. New version bales.) | 16:17.31 |
| | If we can get that fixed, I think we're in a generally better position than we were before. | 16:18.04 |
| henrys | too bad luratech is not an option here. | 16:18.58 |
| Robin_Watts | I'll open a bugzilla bug for it, and we can discuss it there. | 16:19.16 |
| henrys | my hope was to offload mupdf business from you to either paulgardiner or tor8 so you could help out with some pre release gs stuff - but it looks like that is not going to work out. | 16:20.20 |
| Robin_Watts | henrys: well, I can park the customer 395 bugs at any point. | 16:21.08 |
| | So if there is prerelease gs stuff that's higher priority please just say. | 16:21.35 |
| henrys | we'll discuss it next meeting. | 16:21.53 |
| Robin_Watts | tor8: So how do we setup android@mupdf.com ? | 16:22.44 |
| henrys | IMHO the mt crash for the languages should be a showstopper I believe marcosw has already set the bug's priority. I was thinking you could work with ray on that. | 16:23.06 |
| Robin_Watts | henrys: ok. | 16:23.21 |
| tor8 | Robin_Watts: I don't know how the mail is handled for mupdf.com | 16:24.08 |
| henrys | also if paulgardiner wan't more hours and wants to dive into the openjpeg stuff that is fine too. But I don't know if that makes sense when start up time is taken into account. | 16:24.11 |
| tor8 | the web hosting and dns is done by casper, IIRC. I believe it was ray or ralph who set it up. | 16:24.25 |
| marcosw | Robin_Watts and tor8: I can try and figure out how mupdf.com mail works. Are there currently any email accounts? | 16:25.40 |
| tor8 | marcosw: no. no email is active for mupdf.com | 16:26.03 |
| marcosw | I suspect there isn't any setup for mupdf.com email. The web site resolves via virtual hosting. | 16:26.39 |
| tor8 | marcosw: so it all just goes to the regular ghostscript.com email? | 16:27.06 |
| henrys | what is the account email name at apple? | 16:27.32 |
| marcosw | it depends on how the mx records are set up. it might not go anywhere :-) | 16:27.50 |
| tor8 | henrys: tor.andersson@artifex.com | 16:27.55 |
| Robin_Watts | I'll register us a google developer account with artifex@wss.co.uk or something and then we can link that across | 16:27.58 |
| | marcosw: Would it be easier to just set up android2@ghostscript.com or something? :) | 16:28.53 |
| henrys | do we have anything else for paulgardiner? the status report looks good as usual. | 16:29.44 |
| marcosw | Robin_Watts: that would be easier. Just add a user with that name on casper and create a .forward file in the home directory. | 16:29.59 |
| Robin_Watts | marcosw: I've never added a user before. Perhaps it might be better if you did it? | 16:30.53 |
| marcosw | Robin_Watts: sure. is android2 the name you wanted or was that a typo? | 16:31.09 |
| Robin_Watts | I think I used android@artifex.com before. | 16:31.32 |
| | which means android@ghostscript.com would be perfect. | 16:31.40 |
| marcosw | btw, I just sent a test email to marcos@mupdf.com and it didn't immediately bounce. I wonder where it went... | 16:32.03 |
| | Robin_Watts: okay, there is now an android@ghostscript.com account. Where would you like the email to forward? | 16:33.58 |
| Robin_Watts | robin.watts@artifex.com ? | 16:34.09 |
| henrys | a field day for email harvesters | 16:34.24 |
| Robin_Watts | and we can copy in tor/paul once it's set up. | 16:34.25 |
| | henrys: My email address hasn't changed since 1995ish. Nothing I do now will affect the amount of spam I get :) | 16:35.11 |
| marcosw | Robin_Watts: okay, it's setup to forward. I'm sending a test email. | 16:35.13 |
| Robin_Watts | marcosw: Thanks. | 16:35.20 |
| paulgardiner | henrys: I'd like to help with the openjpeg stuff. Not sure how much I can up my hours though. I've generally been working 4 days a week. Shortish days admittedly, but then I find accuracy and concentration suffers if I extend my day. Could certainly up them short term to get us past current problems. | 16:35.31 |
| | Also, I seem to remember messing with openjpeg before, although a long time ago. | 16:36.54 |
| marcosw | one question answered, marcos@mupdf.com email bounced back. | 16:37.32 |
| henrys | paulgardiner: best if I leave it with Robin_Watts to decide he has his head in the issues and I really don't. | 16:37.37 |
| marcosw | I have to run, I'll be back online in time for the meeting | 16:37.47 |
| henrys | are we good meeting wise - we've gone over the 1/2 hour. | 16:39.34 |
| | ? | 16:39.37 |
| paulgardiner | Yeah, good I think. | 16:40.34 |
| Robin_Watts | henrys: On a different subject; has any decision been made on when/where the next meeting is? | 16:41.02 |
| | The proposed date of 10/11 March is about 8 weeks away now. I saw mvrhel ask about it the other day. | 16:41.34 |
| henrys | Robin_Watts: no, since you are the 2nd person to ask I'll remind miles. | 16:41.47 |
| marcosw | phew, made it. | 16:58.45 |
| mvrhel_laptop | good morning | 16:59.23 |
| henrys | ah next meeting time | 17:00.07 |
| ray_laptop | morning, mvrhel_laptop | 17:00.08 |
| henrys | I just emailed miles to send out the next meeting info | 17:00.52 |
| mvrhel_laptop | oh good | 17:01.04 |
| henrys | marcosw has made the mt crash a showstopper I think I agree with that. ray_laptop I thought Robin_Watts could help out with that if you wanted. | 17:02.22 |
| mvrhel_laptop | henrys: so I pinged customer #330 this week to see where he is with integrating all the changes I made. No word. I hope he doesn't wait until mid Feb. | 17:02.37 |
| ray_laptop | henrys: I agree that it should be a show stopper for the next release | 17:03.05 |
| marcosw | chrisl: I've gotten past the compile issues with Ghostscript/Ghostpcl and ufst 5 but any pcl6 command line seg faults. | 17:03.48 |
| Robin_Watts | ray_laptop: If there is a section of that work that can easily be split off (or if there is some investigation I can reasonably do to help you) please just say. | 17:03.55 |
| henrys | mvrhel_laptop: well probably any change would miss the feb release... | 17:03.58 |
| ray_laptop | so, the problem is that the lcms package doesn't pass allocators around, but sometimes does allocations using a memory allocator from another structure. | 17:04.03 |
| chrisl | marcosw: okay, I'll look at it in a bit | 17:04.13 |
| | marcosw: are you using the new code or the old? | 17:04.30 |
| marcosw | chrisl: I'm not sure, how do I tell? | 17:04.50 |
| ray_laptop | so short of always having lcms always use a non-gc thread-safe allocator (i.e. gsmalloc), there isn't a way to have the lcms actions in a thread not use the allocator that was used at parse time | 17:05.36 |
| mvrhel_laptop | I have 693418 as a blocker that I need to get done before the release | 17:05.36 |
| chrisl | If you do configure --with-ufst=.... then "make", it will use the new code, if you did "make uproduct" or whatever it was, it will use the old code | 17:05.44 |
| | marcosw:^^ | 17:05.52 |
| henrys | alexcher:the soft mask is getting late relative to the release. We really need it to be in soon if it is to go in February | 17:06.07 |
| marcosw | configure --with-ufst=. | 17:06.09 |
| | make uproduct doesn't work. | 17:06.18 |
| alexcher | henrys: I know this. | 17:06.32 |
| chrisl | marcosw: okay, so that's trying to use the old code - it definitely *did* work - having two overlapping interfaces is a freakin' pain :-( | 17:07.42 |
| henrys | do we have any other showstoppers? | 17:08.24 |
| marcosw | chrisl: it may be my command line, so don't be surprised if it works for you. | 17:08.34 |
| henrys | marcosw? | 17:08.38 |
| marcosw | henrys: the ufst 5 issue is a blocker. | 17:08.47 |
| chrisl | I don't think it is a blocker if it only goes wrong with the old code | 17:09.09 |
| henrys | norbert is using 5 though so it sort of leaves him stranded. | 17:10.43 |
| chrisl | The new code works with 5 | 17:10.56 |
| | After we discussed it back in Dec, I got 5 working. | 17:11.37 |
| henrys | chrisl:confused - marcosw sees a crash yes? | 17:14.01 |
| chrisl | with the old code | 17:14.13 |
| marcosw | marcosw: with GhostPCL and configure --with-ufst=... | 17:14.33 |
| chrisl | and "make uproduct"? | 17:14.53 |
| kens | mvrhel_laptop : ping | 17:15.20 |
| henrys | chrisl:so what version of ghostpcl does the ufst require? | 17:15.32 |
| marcosw | chrisl: I can't get "make uproduct" to compile. | 17:16.25 |
| chrisl | marcosw: have you updated ufst? | 17:16.56 |
| marcosw | I'm running r3353 (seems strange not to have to type 32 hex characters). | 17:17.35 |
| mvrhel_laptop | hi kens | 17:18.02 |
| henrys | chrisl:I'd like to find someway to disable the language switch build for the release, or at least have some obvious warning that this is a deathtrap when it is built. Any ideas? | 17:18.18 |
| kens | mvrhel_laptop : I'm getting a crash in the ICC code, I'm not sure how to handle it. explanation coming | 17:18.22 |
| chrisl | henrys: I'll look into it, it shouldn't be too hard. | 17:18.45 |
| henrys | thank you. | 17:18.59 |
| chrisl | marcosw: ufst 5 is at r3275 | 17:19.16 |
| marcosw | isn't ufst 5 in svn+ssh://casper.ghostscript.com/var/lib/svn-private/ghostpcl/trunk/ufst? | 17:19.59 |
| chrisl | Yes | 17:20.41 |
| kens | mvrhel_laptop : I do an gs_icc_get_link and input_colorspace->cmm_icc_profile_data is NULL. SO we 'use default type' which calls gsicc_get_gscs_profile(input_colorspace.... But that returns NULL. Later we test to see if outptu_colorspace is NULL and if it isn't, we do gs_color_space_index index = gsicc_get_default_type (gs_input_profile). But because gs_input_profile is NULL it crashes | 17:20.42 |
| | mvrhel_laptop : I believe the input colourspace is a Separation spac if that helps | 17:21.15 |
| mvrhel_laptop | kens: so you have a separation source color space? | 17:21.40 |
| henrys | kens, mvrhel_laptop:is this color management business supposed to make February? | 17:21.50 |
| kens | mvrhel_laptop : I htink so, yes | 17:21.51 |
| | henrys I was hoping it would, but I'm not sure now | 17:22.08 |
| marcosw | chrisl: that might be the problem, if I do a svn co svn+ssh://casper.ghostscript.com/var/lib/svn-private/ghostpcl/trunk/ufst I get r3353 (I just tried it again). | 17:22.22 |
| kens | I thought I had lionework corre4ct, but I've stumbled ona a whoel category that isn't working | 17:22.26 |
| | Basically ps2write is totally broken :-( | 17:22.46 |
| mvrhel_laptop | kens: and what do you want to convert the sep space to? | 17:22.50 |
| kens | mvrhel_laptop : I was hoping the device space. I'm not sure what that is at present | 17:23.12 |
| chrisl | marcosw: I just built with "./configure --with-ufst=./ufst make uproduct" and tried the exe, and it produces output. | 17:23.23 |
| kens | Its possible that this is the problem | 17:23.25 |
| mvrhel_laptop | kens: in any event you will need to push it through its alternate tint transform before doing any icc work | 17:23.39 |
| | didn't we do this before? | 17:23.46 |
| henrys | I've exhausted my meeting topics if anybody else has something try to get it out before the 1/2 hour. | 17:24.01 |
| kens | mvrhel_laptop : Ah, I think I had forgotten that | 17:24.03 |
| | mvrhel_laptop : SO I really shouldn't be passing a Separation space in here at all, I should be passing in the alternate space, and the tint-trnsformed colours | 17:25.28 |
| marcosw | chrisl: I'm not sure I understand. I need to use both "./configure --with-ufst=./ufst" and "make uproduct"? | 17:25.31 |
| chrisl | marcosw: yes | 17:25.43 |
| mvrhel_laptop | kens: yes exactly | 17:26.03 |
| | kens: the same is going to be true for DeviceN spaces | 17:26.17 |
| kens | OK that's somewhere for me to go tomorrow, thanks. I'm sure I have tha code somewhere else that I can steal it | 17:26.27 |
| mvrhel_laptop | also, be careful about indexed spaces | 17:26.27 |
| marcosw | that might be it then. "./configure --with-ufst=./ufst" and "make" seems to build but doesn't work. Am I correct in believing that for ghostscript I don't need to do a special make? Just configure --with-ufst...? | 17:26.40 |
| kens | Indexed I already handle, I just forgot sepa dn deviceN | 17:26.40 |
| mvrhel_laptop | kens: ok great | 17:26.52 |
| kens | mvrhel_laptop : THe 'pdfwrite' cases already work, this is for the fallback to low levels of PDF (< 1.3) | 17:27.02 |
| mvrhel_laptop | ok | 17:27.08 |
| henrys | marcosw:pcl always require configure these days. | 17:27.15 |
| kens | ps2write sets the compatibility level to 1.2 | 17:27.16 |
| mvrhel_laptop | I think you will get it all done before the release | 17:27.17 |
| marcosw | tor8: you have some git repositories on casper that are out of date, could please remove them. Specifically the ufst and luratech ones. | 17:27.27 |
| kens | mvrhel_laptop : I'm not so sure, I have to rewrite the image handling | 17:27.34 |
| | Mostly because I can't understand what's there | 17:27.49 |
| chrisl | marcosw: make uproduct will build pcl6 with the *old* integration code, "make pcl" will build with the FAPI code. Ghostscript never had an "old" integration | 17:27.52 |
| marcosw | henrys: I don't understand. | 17:28.31 |
| | chrisl: right, so I guess pcl is broken with the FAPI code and ufst 5. Or is that not supposed to work? | 17:29.05 |
| henrys | marcosw:nothing to do with the ufst - pcl requires both configure and make, it used to not have any configure scripts. | 17:29.19 |
| chrisl | It is supposed to work, I'm just going to try it now - does it crash or does it error? | 17:29.31 |
| marcosw | chrisl: seg faults | 17:29.40 |
| chrisl | Huh, odd..... | 17:29.47 |
| marcosw | henrys: yes, but I don't understand why you are telling me this. | 17:30.13 |
| henrys | marcosw:somehow I got the impression you didn't think you needed to run configure. | 17:31.03 |
| marcosw | I'm saying pcl6 seg faults, presumably if I must have run ./configure in order to get it to compile. | 17:31.03 |
| chrisl | marcosw: Okay, I see the seg fault - I'll look into it | 17:31.25 |
| marcosw | chrisl: great. I thought I was going crazy. | 17:32.06 |
| ray_laptop | is our meeting over ? (I need to drop my car off for service) | 17:32.53 |
| chrisl | marcosw: I have make some changes to improve PDF/PS support with UFST 5, it may be related to those..... | 17:33.23 |
| marcosw | btw, are there now 4 different ufst/fapi combinations (i.e. ufst 5 and 6 and with/without FAPI). which one(s) do we want to test (i.e. which are our customers using?). | 17:34.18 |
| henrys | ray_laptop:it's always over at 9:30 | 17:35.53 |
| chrisl | I suggest we test only 5, since we only currently have customers using 5, and with FAPI, since that's the "future" | 17:36.14 |
| marcosw | chrisl: and that's the combination that seg faults? | 17:36.54 |
| chrisl | Er, yep! | 17:37.06 |
| ray_laptop | henrys: thanks -- I was just making sure no one had anything else for me. I'll make the allocator changes for 693361 and see if I get any problems (with leaked elements since it won't use the GC) | 17:37.14 |
| henrys | ray_laptop:great | 17:37.36 |
| chrisl | marcosw: We should probably continue to test the non-FAPI 5 build for a while, too. | 17:37.40 |
| marcosw | chrisl: make sense | 17:39.12 |
| chrisl | Is that a typo or a request ;-) | 17:39.30 |
| henrys | tor8:looks like each openjpeg problem results in 6 mismatched files so not as bad as 264 sounds. | 17:40.47 |
| chrisl | marcosw: I see what the seg fault is - a "fallback" case we shouldn't use for Microtype fonts. I can fix it in a minute | 17:42.02 |
| marcosw | chrisl: what about the r3353 vs r3275 issue? | 17:43.03 |
| chrisl | I think you are correct, I was getting strange output from svn log, but my *current* revision is r3353, too | 17:43.56 |
| Robin_Watts | henrys: The 264 openjpeg problems are the ones todo with v2 vs v1.5 | 17:44.05 |
| henrys | Robin_Watts:understood yes | 17:44.44 |
| Robin_Watts | and I suspect that basically most of them boil down to the fact that the new code bales on an error rather than trying to continue. | 17:44.47 |
| henrys | hmm 40 or so files have baling errors? | 17:45.47 |
| | seems unlikely I don't think we have very many openjpeg tests to begin with. | 17:46.30 |
| kens | OK goodnight everyone | 17:46.51 |
| henrys | kens:goodnight | 17:47.00 |
| Robin_Watts | henrys: About 264 tests (or 246/6 = 40 files if you prefer) have errors due to images not appearing at all. | 17:48.23 |
| chrisl | marcosw: I've pushed the fix for the FAPI code | 17:48.43 |
| Robin_Watts | henrys: http://ghostscript.com/~regression/robin/ | 17:49.09 |
| henrys | I'm surprised there are that many broken files | 17:49.21 |
| marcosw | chrisl: thanks. that was quick. | 17:49.40 |
| chrisl | marcosw: I'd put in a fallback in case FAPI can't handle a font, but the Microtype loading code requires the error return - I'd forgotten that | 17:50.52 |
| henrys | Robin_Watts:do we just have 40 openjpeg files and it doesn't work at all? | 17:52.14 |
| marcosw | uh oh. I'm getting strange errors from casper that feel like a hardware issue. I guess i'll move it to a new instance. | 17:52.25 |
| Robin_Watts | henrys: I don't know what proportion of our JPEG2K files those 40 correspond to, no. | 17:53.32 |
| marcosw | casper will be down for 10 minutes or so... | 17:53.49 |
| Robin_Watts | It does work for some files (hivemind for example) | 17:53.59 |
| chrisl | marcosw: hmm, I had someone mail me earlier today asking if ghostscript.com was down, they got a weird error...... | 17:54.08 |
| Robin_Watts | henrys, alexcher: Were we passing the OpenJPEG 2 stuff with gs to shelly ? | 17:54.56 |
| | It seems likely that he'll hit the same problems with that. | 17:55.09 |
| | So the openjpeg stuff breaks down into: 1) v2 vs v1.5 - alex is going to look at doing v2 for gs so will presumably hit the same problems so I'll leave this to him to solve. | 17:59.50 |
| | 2) The remaining customer 395 issues. | 18:00.10 |
| | I will continue to look at 2, and farm as many out to people as I can, but I will give priority to helping ray with the MT stuff. | 18:00.48 |
| henrys | Robin_Watts:sound right - but I did think you said there were only openjpeg problems, has more stuff been reported? | 18:01.20 |
| Robin_Watts | henrys: I ran through the files that customer 395 supplied. I ignored all ones that were in openjpeg, and solved all the others. | 18:02.13 |
| | now I've got to go back and deal with the ones I skipped. | 18:02.24 |
| | So all the outstanding issues (that I've managed to reproduce) are openjpeg related (I believe) | 18:03.13 |
| tor8 | casper doesn't seem to be coming back to life after that reboot... | 18:17.03 |
| mvrhel_laptop | bbiab | 18:17.31 |
| chrisl | tor8: I guess moving it to a new instance takes longer than a normal reboot | 18:17.40 |
| tor8 | chrisl: right. I guess I need more patience then :) | 18:18.15 |
| chrisl | tor8: Yep, you need more patience - RIGHT NOW!!! ;-) | 18:18.46 |
| Robin_Watts | ray_laptop: ping. | 18:47.19 |
| | (Assuming it's not you that mvrhel_laptop is on the phone to :) ) | 18:48.00 |
| | alexcher: ping | 19:42.50 |
| | In openjpeg in j2k.c at line 430ish we have j2k_read_siz | 19:43.37 |
| | Is it reasonable to expect that image->x0 > image->x1 or image->y1 > image->y0 are faults in the file? | 19:44.22 |
| alexcher | Robin_Watts: pong | 19:47.10 |
| sebras | Robin_Watts: http://goo.gl/hnnPg | 19:47.36 |
| alexcher | Robin_Watts: What gs does in this case ? | 19:48.17 |
| Robin_Watts | For this particular file? typecheck in --run-- | 19:50.41 |
| alexcher | Robin_Watts: I need to look closer. What Acrobat does? | 19:53.09 |
| Robin_Watts | acrobat thinks the file is damaged beyond repair. | 19:54.28 |
| alexcher | Robin_Watts: IMHO the case can be closed. | 19:55.06 |
| Robin_Watts | alexcher: No, because it causes a SEGV. | 19:55.20 |
| | I don't care that the image is not displayed. I care that in trying to display it it crashes. | 19:55.57 |
| | hence my desire to amend the image decoder so that it can spot illegal data and quit early (and cleanly) | 19:56.51 |
| | But I just pushed some code that checks for image->x0 > image->x1 or image->y0 > image->y1 and it caused differences in files that were working already. | 19:57.43 |
| sebras | Robin_Watts: are you talking about the openjpeg code itself? I noticed several SEGVs while fuzzing just a single input image. | 19:57.44 |
| Robin_Watts | sebras: Yes. I'm inclined to think that openjpeg is just stupidly broken in most cases. | 19:58.13 |
| mvrhel_laptop | Robin_Watts: I am sorry I am here | 19:58.30 |
| Robin_Watts | mvrhel_laptop: Hi. | 19:58.42 |
| | I was going to ask you some questions about the gscms stuff, but I've done some more digging since. | 19:59.08 |
| sebras | Robin_Watts: yes, it is. I even looked at the j2k spec and tried to understand the issues, but wasn't able to do so easily (mostly because I don't know openjpeg). | 19:59.09 |
| Robin_Watts | Do we have a copy of the spec? | 19:59.28 |
| mvrhel_laptop | Robin_Watts: ok. I am going to grab some lunch | 19:59.50 |
| Robin_Watts | yeah, I have a copy here. | 19:59.56 |
| | mvrhel_laptop: afore ye go... | 20:00.03 |
| | I've just reviewed our use of memory pointers within lcms. | 20:00.38 |
| alexcher | Robin_Watts: yes, I do. It's public. | 20:00.49 |
| Robin_Watts | Essentially, the memory pointers get pickled in when profiles/links are created and then never changed. | 20:01.15 |
| sebras | alexcher: yes, but some parts are harder to find. I had to check jpeg.org-links to find them all. | 20:01.43 |
| | alexcher: at archive.org I mean. | 20:02.07 |
| Robin_Watts | mvrhel_laptop: My memory was that you claimed that profiles/links should never be used across threads (i.e. they would be created and used all within a single rendering thread). | 20:02.42 |
| | Do you still believe that to be the case? | 20:02.50 |
| alexcher | -rwxr--r-- 1 alexcher alexcher 2037268 Jul 27 2010 15444-1annexi.pdf | 20:03.06 |
| mvrhel_laptop | yes I do | 20:03.07 |
| alexcher | -rwxr--r-- 1 alexcher alexcher 2596526 Jul 27 2010 15444-2annexm.pdf | 20:03.08 |
| | -rwxr--r-- 1 alexcher alexcher 2595848 Jul 27 2010 15444-2annexn.pdf | 20:03.09 |
| | -rwxr--r-- 1 alexcher alexcher 2322269 Jul 27 2010 fcd15444-1.pdf | 20:03.11 |
| | -rwxr--r-- 1 alexcher alexcher 3189686 Jul 27 2010 fcd15444-2.pdf | 20:03.12 |
| Robin_Watts | mvrhel_laptop: Then do you understand how this can ever be a problem? | 20:03.28 |
| mvrhel_laptop | what is "this" | 20:03.41 |
| Robin_Watts | The multi-threaded rendering cms memory problems that ray is seeing. | 20:04.01 |
| mvrhel_laptop | I don't understand how or where the issue would be coming from | 20:04.23 |
| | all the profiles are stored in the clist | 20:04.42 |
| | except for the device profiles | 20:04.53 |
| Robin_Watts | When you say "profiles are stored in the clist" you mean "the raw blocks of profile data", right? | 20:05.34 |
| mvrhel_laptop | right. | 20:05.40 |
| Robin_Watts | so no cms created object goes into the clist at any point. | 20:05.56 |
| mvrhel_laptop | no | 20:05.59 |
| Robin_Watts | And the device profiles are created for each rendering thread itself, right? | 20:06.17 |
| mvrhel_laptop | yes | 20:06.26 |
| | and each thread has its own link cache | 20:06.45 |
| Robin_Watts | OK, so I cannot see how the problem is occurring either. | 20:06.50 |
| | Either there is something wrong with my understanding, or the situation is not as we just agreed it is. | 20:07.15 |
| mvrhel_laptop | right | 20:07.25 |
| Robin_Watts | I'll send ray a mail describing this, and we can see if he has some observation that explains things. | 20:07.51 |
| | mvrhel_laptop: Thanks. Enjoy your lunch. | 20:08.05 |
| mvrhel_laptop | Robin_Watts: ok | 20:08.11 |
| mace | wonders if Miles was being funny or just mistyped Robin :) | 20:25.26 |
| Robin_Watts | mace: Who knows :) | 20:25.56 |
| mace | he seems happy anyway, so job done | 20:26.09 |
| | ta | 20:26.12 |
| Robin_Watts | thank you. | 20:26.19 |
| mace | hows the speed for you? | 20:27.53 |
| | i take it its now on the hosting platform the old website was on? | 20:28.11 |
| | took ~ 30 seconds earlier to even connect, but once it had it started loading fairly quickly | 20:28.31 |
| Robin_Watts | mace: speed is 'fine', I think. | 20:29.52 |
| | It's not quite as zippy as it could be, but it's perfectly acceptable. | 20:30.08 |
| mace | i could probably optimise it further, but i'd realistically need access to the hosting account | 20:30.37 |
| Robin_Watts | mace: That hosting account is busily serving terrabytes of data a month for downloads, so it's reasonable that it's a tag sluggish. | 20:31.47 |
| mace | Robin_Watts: you sure it's still with that hosting provider? | 20:33.42 |
| Robin_Watts | mace: yes. | 20:33.51 |
| mace | curious, that'd explain the lag anyway | 20:34.03 |
| Robin_Watts | mvrhel_laptop: I've sent ray a mail. If you could skim read it to make sure I've not claimed that black is white, I'd be grateful. | 20:35.49 |
| mvrhel_laptop | Robin_Watts: ok will do | 20:36.01 |
| ray_work | Robin_Watts: mvrhel_laptop: The problem in lcms allocation is not related to profiles, but transfer functions. lcms is making a 'copy' of a structure using the memory allocator (not thread safe) from a structure that was created at parse time. | 21:06.55 |
| mvrhel_laptop | where is it making this copy of a transfer function? | 21:07.33 |
| ray_work | mvrhel_laptop: I'd have to fire up the debugger (on peeves) to tell you which functions I've caught messing up/ | 21:09.35 |
| mvrhel_laptop | ok. I have to head out now | 21:10.17 |
| | maybe you can add that information to the bug | 21:10.24 |
| ray_work | mvrhel_laptop: I'll add some more info to the bug.. | 21:17.13 |
| apineda | hey guys I was just hoping for some help. I did some analysis of pdf trailer and I get 526 indirect objects. I look at the pdf in illustrator and see at most 100 objects (grouped objects, compound paths, clipping paths, and paths). | 21:18.21 |
| | The point of all this is that our RIP (Versaworks) crashes from load and we're trying to cut down on object complexity in our "artwork" | 21:18.53 |
| | perhaps indirect objects is not the best measure of scan conversion complexity/processing requirement | 21:20.07 |
| alexcher | apineda: having 526 objects is normal. Complex files have over 100K objects. | 21:21.25 |
| apineda | alexcher: I'll analyze our output pdf then because they are composed of these smaller ones (like stamps) | 21:21.49 |
| alexcher | apineda: Uou can try to simplify your PDF file using Ghostscript. | 21:21.57 |
| apineda | alexcher: how? | 21:22.15 |
| rayjj | apineda: I agree with alexcher, you probably need a better RIP than Versaworks. Try Ghostscript or mupdf :-) | 21:22.24 |
| | apineda: or use mutool clean -g (the -g leaves out unused objects) | 21:23.10 |
| alexcher | apineda: gs -sDEVICE=pdfwrite -o OUT.pdf IN.pdf | 21:23.10 |
| rayjj | apineda: and what alexcher says will also leave out unused objects | 21:23.40 |
| | apineda: what do you get out of Versaworks (when it doesn't crash) ? | 21:24.58 |
| apineda | rayjj: well its HPGL/RTL with one to print on wide format printers and roller cutters | 21:25.58 |
| rayjj | apineda: Thanks. I just googled it, and it seems to come with Roland printer/cutters (for signs). To bad that it's Adobe CPSI based. We can't help there | 21:27.27 |
| apineda | We are looking at other RIPs | 21:30.51 |
| | Thanks gentlemen! Good evening... | 21:37.39 |
| rayjj | apineda: I don't know which RIPs use Ghostscript, but I do know that some do that support 'vector' output for cutters | 21:38.11 |
| | apineda: good evening. | 21:38.21 |
| | apineda: check our logs http://ghostscript.com/irclogs/ -- if I find one that does, I'll post info for it to apineda (so you can find it) | 21:39.23 |
| | Forward 1 day (to 2013/01/09)>>> | |
IRC Logs