| | <<<Back 1 day (to 2012/04/05) | 2012/04/06 |
| mvrhel | Robin_Watts: for the logs, right about wanting to look at the individual planes | 00:19.13 |
| | marcosw__ : so, Robin_Watts is going to get bmpcmp working directly with psdcmyk files so I don't think there will be anything for you to do | 00:19.57 |
| jzmer | is it normal for /CIDSystemInfo section to include password? | 08:38.40 |
| kens | No | 08:38.50 |
| jzmer | if so, given i have a postscript font | 08:38.52 |
| | i see | 08:38.57 |
| kens | CIDSystemInfo dictionary contains 3 keys, Registry ORdering and Supplement | 08:39.17 |
| jzmer | however, i have some cid keyed postscript cjkv fonts that contain /password in /CIDSystemInfo , and i suspect something's quite wrong | 08:39.55 |
| | since MOESung doesnt have /password there | 08:40.05 |
| kens | Wihtout seeing the PostScript I can't comment | 08:40.16 |
| jzmer | kens: anywhere i can post it? | 08:40.29 |
| kens | But the CIDSystemInfo dictionary should not contain a password key | 08:40.34 |
| | jzmer anywhere that's convenient for you | 08:40.47 |
| | transferbigfiles.com, pastebin.com, whatever seems best to you and you can get to | 08:41.05 |
| jzmer | right, i only need paste the plain text part, not the postscript binary. | 08:41.20 |
| kens | Having said that, if a dictionary contains a key that isn't used, it will cause no harm | 08:41.29 |
| jzmer | kens: there you go http://fpaste.org/8uBD/ | 08:43.32 |
| kens | Its possible that a font foundry has created a protected font, and uses the /password entry to decrypt it | 08:44.22 |
| | Its not standard, but non-standard extensions to protect fonts are quite common in the Far East | 08:44.45 |
| jzmer | this font is made by founder, a chinese company | 08:45.10 |
| kens | When you consider that a font contains tens of thousands of glyphs in these languages, its not surprising that efforts are made to protect them. | 08:45.18 |
| jzmer | known to have crazy encryption for its rip | 08:45.20 |
| kens | And originally to have 'borrowed' the code from teh Harlequin rip | 08:45.37 |
| | Its entirely possible this font will not work on a regular RIP | 08:45.54 |
| jzmer | however, since founder has fonts available for generic rips, i doubt they took interest in encrypting their fonts so that no one else can print them | 08:46.55 |
| kens | Depends. | 08:47.06 |
| | They may seel different fonts for those rips, or they may licence the encryption technology to the rip vendors (a la Morisawa Copr in Japan) | 08:47.34 |
| | In order to print Morisawa fonts, you need the decryption code buitl into your interpreter, many rip ve3ndors licence this so that they can use the fonts, as demanded by their end users. | 08:48.24 |
| | By the way, this appears to be a raw CIDFont, not a CID-keyed instance of a font. | 08:48.50 |
| | You haven't actually said what problem you are encoutnering / | 08:49.15 |
| jzmer | i see, so if i am trying to have ghostscript processing their ps files with proprietary encrpyption, it is my problem, and none can fix. | 08:49.49 |
| kens | *If* that's the problem, hten yes. | 08:50.03 |
| | Even if we were to licence the technology, we would not be able to use it in an open-source product. | 08:50.22 |
| | But, you haven't yet said what the problem is. Also I could try the comeplte PostScript on some other engines, to see if they have teh same problem. THe more engines with teh problem, the more likely it is a custom encryption | 08:51.48 |
| jzmer | the problem is, i am trying to convert to a founder FIT ps file to pdf with ghostscript | 08:52.23 |
| | which requires the aforementioned font | 08:52.35 |
| | and boom | 08:52.48 |
| kens | And what error do you get ? | 08:52.50 |
| jzmer | let me complete this first. afterwards, i tried many other methods like lcdf's type tool and fontconfig to query the original font file | 08:53.41 |
| | i think at one point i tried to have fontforge open the file, and it failed at no cmap | 08:54.30 |
| | as for the error with ghostscript | 08:54.42 |
| kens | A CIDFont will not contain a CMAp | 08:54.51 |
| jzmer | its the same | 08:55.00 |
| kens | The same error ? | 08:55.11 |
| jzmer | right. and i assume the cmap is already installed with adobe's cmap | 08:55.29 |
| kens | That suggests you are trying to use the CIDFont 'bare', which will only work with teh PostScript 'glyphshow' operator | 08:55.34 |
| | Installing a CMap will have no effect. | 08:55.49 |
| | To use a CIDFont you must first compose it with a CMap which gives you a CID-keyed instance of teh font, which you can then use. | 08:56.14 |
| | You can't use the CIDFont 'as is' | 08:56.25 |
| | Maybe you should let me see your PostScript file. | 08:56.45 |
| kens | fetches more coffee, be right back | 08:58.28 |
| jzmer | well, not that i dont trust you, but the file contains some company insider info, i dont think im allowed to give | 08:59.02 |
| | but given the rest of the complaint from various programs | 08:59.38 |
| | i think it should be an encryption problem | 08:59.55 |
| | since there are fonts with adobe-gb1 that still has problems | 09:00.15 |
| | time to tell ppl to switch from founder | 09:00.54 |
| kens | jzmer, cna you create a file which you can give out ? | 09:03.29 |
| jzmer | not on this machine | 09:03.41 |
| kens | I am not completely convinced this is an encryption problem from your description | 09:03.44 |
| | It sounds more like you aren't using the font properly (at least so far, from your description) | 09:04.11 |
| jzmer | founder's rip is windows-only | 09:04.20 |
| kens | Interesting, I thought they had a Linux version | 09:04.36 |
| | Maybe they dropped it | 09:04.46 |
| | Well, if you can give me a file to look at I can investigate some more, but without seeing the actual PostScript, I don't think I can suggest anything else. | 09:05.44 |
| | Robin_Watts : your last commit broke the MuPDF build | 09:06.14 |
| | cbz/mucbz.c:236: error: too few arguments to function 'fz_malloc' | 09:06.35 |
| Robin_Watts | d'oh. thanks. | 09:07.03 |
| kens | NP | 09:07.07 |
| jzmer | thanks, though i think i will talk to those the creator of the ps file first. | 09:07.40 |
| kens | Tjzmer that's a reaonable approach, they may be able to figure t out if they understand PostScript | 09:08.05 |
| | s/Tjzmer/jzmer/ | 09:08.28 |
| sebras | Robin_Watts: welcome home. :) | 11:26.12 |
| Robin_Watts | sebras: Thanks. | 11:26.20 |
| kens | lunches | 11:33.05 |
| tannerwatson | *waves* good morning everyone | 12:26.49 |
| kens | waves back | 12:27.02 |
| nicoo | too | 12:28.12 |
| Robin_Watts | kammerer: Hi. | 13:01.27 |
| | kammerer: You reported bug 692957. | 13:02.31 |
| | Unfortunately, I don't have any cbz files large enough to trigger this. Can you point me at one that does please? | 13:03.04 |
| | kens: Have you seen anything like: | 13:25.55 |
| | 1>ttpost.obj : error LNK2019: unresolved external symbol _FT_Stream_GetShort referenced in function _load_format_20 | 13:25.58 |
| | 1>ttpost.obj : error LNK2019: unresolved external symbol _FT_Stream_ReadShort referenced in function _load_format_20 | 13:26.00 |
| kens | Nope, is this a GS build error ? | 13:26.18 |
| Robin_Watts | It is. | 13:26.24 |
| kens | Never seen that before, mine builds OK | 13:26.55 |
| | What version FreeType are you using ? | 13:27.03 |
| | THe regular one ? | 13:27.09 |
| Robin_Watts | Yeah, this is a vanilla windows build. Trying from clean now. | 13:27.24 |
| kens | Odd. I rebuilt from clean yesterday and it was OK | 13:27.42 |
| Robin_Watts | Clean build worked. | 13:30.55 |
| kens | Weird.... | 13:31.29 |
| | But if its OK now... | 13:31.34 |
| tannerwatson | just curious but is there any way to increase the performance of GhostScript. When converting 1000+ PDFs to TIFF we are only using about 12% CPU | 14:14.55 |
| Robin_Watts | tannerwatson: Well, you may be hitting IO limits. | 14:15.13 |
| | Or you might be using one core of an 8 core machine. | 14:15.28 |
| tannerwatson | Robin_Watts, the IO spikes at writing 13MB, when my wrapper creates a copy of the PDF before converting, but besides that it stays at about 1MB average | 14:21.14 |
| | How do you tell GS to use more cores? | 14:21.49 |
| Robin_Watts | tannerwatson: How many cores on the machine you are using ? | 14:21.58 |
| tannerwatson | Robin_Watts, 4 physical 8 with hyper threading | 14:22.33 |
| henrys | 12% sounds suspicious? | 14:22.37 |
| Robin_Watts | Right. so we are completely maxing out one of the virtual cores. | 14:22.56 |
| | tannerwatson: Well, you can try using -dNumRenderingThreads=8 | 14:23.14 |
| | but that only parallelises the rendering phase (and then only if you are rendering using a clist). | 14:23.42 |
| | A better approach may be to run 8 copies of gs and do 1000/8 jobs on each. | 14:24.00 |
| henrys | Robin_Watts:haven't seen tor8 around lately was hoping to get a meeting in before Tuesday but I guess it can wait. | 14:24.36 |
| | paulgardiner:I assume you are plugging along okay? | 14:24.57 |
| Robin_Watts | henrys: I thought tor8 was in Korea ? | 14:24.57 |
| henrys | oh that's right he sent me email, darn I forgot | 14:25.27 |
| tannerwatson | aaaahhhhh, that is a good idea. so I would need to get 8 different instances of GS with gsapi_new_instance ? for some reason i thought I couldnt do this | 14:25.49 |
| | Robin_Watts, thanks a lot. that points me in hte right direction | 14:26.26 |
| Robin_Watts | I chatted to Paul on Tuesday/Wednesday about where he was at, and I think he was in a position to keep making progress. | 14:26.31 |
| henrys | okay great. | 14:26.52 |
| paulgardiner | henrys: Yes. Text input is sort of working now. Not every case covered, but various things like scale to fit is. | 14:27.27 |
| Robin_Watts | paulgardiner: So you got the '0 Tf' special case working? Nice. | 14:27.57 |
| paulgardiner | And I believe it is done in a way where just writing out the file in the normal way would save the form entries | 14:28.27 |
| | Robin_Watts: Yes. | 14:28.55 |
| | Positioning isn't entirely correct yet. I'm losing the tails of letters off the bottom. Not yet entirely sure of the correct way to handle it. | 14:29.56 |
| Robin_Watts | You probably need to read the fount bbox. | 14:30.23 |
| | Got to go jump start the van. brb. | 14:30.39 |
| | back,. | 14:34.33 |
| | paulgardiner: How are you doing scale to fit? | 14:34.45 |
| | Every font has a font bbox (the largest bbox for any glyph). | 14:35.25 |
| paulgardiner | I render to a bbox device to measure and if the result is too big recalculate the size and regenerate | 14:35.33 |
| kens | Font BBox are not reliable | 14:35.48 |
| Robin_Watts | paulgardiner: Oh, OK, that's better, probably. | 14:36.02 |
| paulgardiner | I use measuring only for the horizontal fit. | 14:36.35 |
| Robin_Watts | But if you get a bbox for the string, then I'd not expect to see the descenders lost... | 14:36.45 |
| | Ah, right. So you probably need to use the vertical bits of the bbox to set the baseline ? | 14:37.03 |
| paulgardiner | I notice that Acrobat keeps the font base line fixed as the font decreases in size | 14:37.04 |
| kens | base line is the current point, so it will not change | 14:37.20 |
| Robin_Watts | In Acrobat, if you have 'read' and you add 'y' onto the end, (so you introduce a character with a descender into the string) does the baseline change then ? | 14:38.28 |
| paulgardiner | How does font size relate to how much vertical space it takes? It looks to be the same, but maybe it's the size above the base line. | 14:38.55 |
| kens | baseline does not change | 14:39.08 |
| paulgardiner | Robin_Watts: No. Keeps it the same. | 14:39.12 |
| mvrhel | good morning. Robin_Watts | 14:39.32 |
| Robin_Watts | Not all fonts with the same size are the same size :) | 14:39.44 |
| | i.e. the font size is a very rough measurement. | 14:40.09 |
| mvrhel | any luck hooking in bmpcmp with the pspcmyk output? | 14:40.23 |
| Robin_Watts | Maybe we should construct our own font bbox and use that or something. | 14:40.34 |
| | mvrhel: I have an updated bmpcmp here. | 14:40.41 |
| mvrhel | can you commit it? | 14:40.51 |
| Robin_Watts | It seems to work on CMYK psd's. | 14:41.00 |
| mvrhel | did you test with CMYK+spot? | 14:41.11 |
| Robin_Watts | but I haven't got a non CMYK psd to test it with. Can you point me at a test file ? | 14:41.23 |
| | (just point me at a file that when fed to gs will output CMYK + spot) | 14:41.52 |
| mvrhel | just run one of the files on bug 692961 | 14:42.12 |
| paulgardiner | henrys: this week and last I've worked pretty solidly on this, but next I may not get to put in many hours on it. Should be back to it the week after. | 14:42.24 |
| henrys | paulgardiner:no problem | 14:42.51 |
| Robin_Watts | At the moment, all the planes will be diffed, and the 'map' will show where the differences are. | 14:42.57 |
| mvrhel | Robin_Watts: ok good. | 14:43.10 |
| Robin_Watts | But the actual diff image will only be constructed from CMYK. | 14:43.15 |
| mvrhel | what happens if the number of planes is different between the two? | 14:43.27 |
| Robin_Watts | (i.e. I haven't done the mapping of the other planes down to cmyk/rgb) | 14:43.45 |
| | mvrhel: bmpcmp will refuse to diff that file. | 14:43.56 |
| mvrhel | Robin_watts: that is fine | 14:43.58 |
| | Robin_Watts: could it perhaps show something? | 14:44.17 |
| Robin_Watts | Hmm. Tricky. | 14:44.33 |
| | I could make it output a 'WTF' bitmap :) | 14:44.57 |
| mvrhel | yes. | 14:45.03 |
| paulgardiner | If I measure some text with the bbox device and no characters of the text have tails, will the bbox still extend to accomodate the possibility of a tail? | 14:45.08 |
| mvrhel | or a mismatch in band numbers | 14:45.14 |
| | channel numbers | 14:45.19 |
| | I can see this happening in some cases | 14:45.39 |
| Robin_Watts | mvrhel: At the moment, bmpcmp exits with an error if width or height or bpp etc don't match. | 14:45.52 |
| mvrhel | ah ok | 14:46.01 |
| Robin_Watts | (i.e. it insists that images are directly comparable) | 14:46.06 |
| mvrhel | well if there is an error on exit I would think you could stuff something into the html you are constructing | 14:46.33 |
| Robin_Watts | That probably means that you just don't get an entry for it in the cluster based test. | 14:46.38 |
| | mvrhel: Possibly, yes. | 14:46.46 |
| | paulgardiner: No. | 14:46.57 |
| mvrhel | Robin_Watts: ok well something to think about later I suppose | 14:47.13 |
| | I am anxious to look at some diffs to | 14:47.28 |
| Robin_Watts | paulgardiner: AIUI, when you measure text with the bbox device you get just the bbox for that text. | 14:47.34 |
| | Gimme 10 minutes and I'll run some of those spot files through. If it doesn't crash, I'll commit it. | 14:48.24 |
| mvrhel | cool. ok. I will go grab some breakfast | 14:48.39 |
| Robin_Watts | paulgardiner: I suspect that we should construct our own font bbox and use that for the vertical measurements. | 14:49.20 |
| paulgardiner | And if I measure a y or g e.g., then it may not actually be a y or g glyph in the font | 14:49.28 |
| Robin_Watts | paulgardiner: Indeed. Hence why I say 'construct our own font bbox'. | 14:50.03 |
| paulgardiner | What, run through all the glyphs, or something? | 14:50.37 |
| Robin_Watts | kens may have a better plan for this, but I'd try measuring glyphs 0 to 255 or something. | 14:50.59 |
| | And then use the union of that plus the measured bbox. | 14:51.22 |
| kens | You would need to enumerate the CharStrings dict for a type 1/2/3 font | 14:51.27 |
| | Wncoding is insufficeint | 14:51.38 |
| | CIDFonts are more complicated | 14:51.44 |
| | TrueTyp[e fonts qoudl mean looking at the GIDs | 14:51.56 |
| Robin_Watts | So if you have any glyphs in your string that lie outside the 0..255 range, the baseline may shift when you type them. | 14:52.02 |
| kens | There may well be a lot | 14:52.03 |
| | What do you need the BBox for ? | 14:52.11 |
| | Often the M is enough | 14:52.16 |
| Robin_Watts | kens: Right. 0..255 would be a heuristic; it's finite time, and covers latin fonts. | 14:52.32 |
| | The only time it fails is when we have a glyph entered into the string with a gid > 255 that has a larger bbox than any glyph in the 0..255 range, and the only 'failure' we'd see would be a shift in the baseline when we add it. | 14:53.52 |
| | Which feels like a pretty soft failure to me. | 14:54.08 |
| kens | Don't forget non-TT fonts don't have GIDs | 14:54.12 |
| paulgardiner | kens: I just need to set the y in "x y Td" so that the tails don;t get lost | 14:54.16 |
| kens | Often teh 'large' glyphs are the 'less usual' ones. | 14:54.34 |
| | Far Eastern fonts aere often fixed pitch | 14:54.41 |
| | SO any glyph will usually do | 14:54.48 |
| Robin_Watts | kens: For latin text, we can't just check 'M', cos that doesn't allow for descenders, which is specifically the problem. | 14:55.08 |
| kens | Right, which is why I was asking :-) | 14:55.19 |
| | If a type 1 fotn contains descender info, its usually reliable (IIRC) | 14:56.29 |
| Robin_Watts | "non-TT fonts don't have gids" - maybe I'm getting my terminology wrong here. | 14:56.33 |
| kens | character codes are what you see in the PDF file | 14:56.43 |
| | Character codes look up Encodings for non-TT fonts, which give you a glyph name. | 14:57.01 |
| | WHich you look up in teh CharStrings dict. | 14:57.10 |
| | for CIDFotns, character codes are looked up ni the CMap which gives you a CID, which you look up in the CharStrings dict. | 14:57.31 |
| | FOr TT fonts you map the character code to a GID | 14:57.40 |
| paulgardiner | This may be more detail than I should go into at this stage. I'm not handling every case, so it may be good enough to grab the existing font bbox. | 14:57.55 |
| kens | Its probably reliable enough for a starting point. | 14:58.15 |
| paulgardiner | Do I get that from a pdf_font_desc? | 14:58.46 |
| kens | Its in the font dictionary of a type 1 font. | 14:59.03 |
| | I think FontDescriptors have one too | 14:59.16 |
| Robin_Watts | paulgardiner: Font descriptors have an 'ascent' and 'descent' field. | 15:00.53 |
| kens | You can't just use T* ? | 15:00.55 |
| | Instead of Td | 15:01.30 |
| paulgardiner | kens: probably not. I need to set the baseline for the maximum text size, even if sufficient text has been typed in the field to require the text size to be reduced. | 15:02.43 |
| Robin_Watts | kens: No, the point is we have to choose where to move to based upon the string to be displayed in the appearance stream we are synthesising. | 15:02.57 |
| henrys | I have an appointment be back in an hour - I would think there would be someway to partially process the character in mupdf and just read out the metrics from some structure no? I'm sure Tor would know. | 15:03.01 |
| kens | OK well I woudl start with teh FontBBox | 15:03.08 |
| Robin_Watts | I'd look at the ascent/descent fields in the font_desc. | 15:03.34 |
| | as they are exposed already. | 15:03.41 |
| paulgardiner | Yeah, those sound good. | 15:03.54 |
| | Is a font_desc specific to a font and size, or just a font? | 15:04.28 |
| Robin_Watts | yes :) | 15:04.39 |
| paulgardiner | :-) Not the answer I was hoping for! | 15:04.59 |
| kens | Specific to font, not to size | 15:05.07 |
| henrys | back up to 6 bugs sigh. | 15:05.20 |
| kens | I htought I changed the transparencygroup to an enhancement.... | 15:06.01 |
| | Also I tihnk one should be closed, the appearance is 'wrong' I think Alex said | 15:06.43 |
| henrys | I got a new one. | 15:07.09 |
| | minutes before the report | 15:07.18 |
| | bbiab | 15:07.50 |
| paulgardiner | So I need to scale the descender value according to the font size. | 15:08.16 |
| kens | yes | 15:09.01 |
| paulgardiner | OK ta. I should be able to suss it out from there. | 15:09.54 |
| Robin_Watts | mvrhel: Found a problem, fixing it now. | 15:12.26 |
| mvrhel | Robin_Watts: ok | 15:16.25 |
| | do you want me to send you 2 files that differ in a spot channel? | 15:16.37 |
| Robin_Watts | mvrhel: That might be useful, thanks. | 15:17.30 |
| mvrhel | ok | 15:17.34 |
| kens | paulgardiner : Note that type 3 fonts need not have a Ascent or Descent entry | 15:19.20 |
| | But I'm hoping you won't be using a type 3 :-) | 15:19.32 |
| paulgardiner | kens: Are type 3s the evil ones that require full PS to interpret? | 15:22.02 |
| kens | paulgardiner : PDF type 3 fonts don't need a PS interpreter | 15:22.19 |
| | But they need a PDF itnerpreter :-) | 15:22.28 |
| paulgardiner | But they are evil, right? :-) | 15:23.13 |
| kens | I won't dispute it | 15:23.23 |
| | But they are also useful ... | 15:23.31 |
| | Only easy way to do a bitmap font | 15:23.40 |
| mvrhel | Robin_Watts: ok. so on casper in my folder called forrobin are two files that have 18 colorants | 15:33.44 |
| | and some real diffs between the trunk and my stuff | 15:33.57 |
| Robin_Watts | I've constructed a cmyk + spots one here with a horizontal shift between the two, and while it's detecting there are diffs, the saved output doesn't show any. | 15:35.48 |
| mvrhel | Robin_Watts: do you know what channel has the diffs? | 15:36.23 |
| | when you are detecting them? | 15:36.29 |
| Robin_Watts | All of them in my example. | 15:36.36 |
| mvrhel | ok. well my point is that maybe we (or you) can simply output the single channel images when you find a diff in a spot? | 15:37.22 |
| | I thought that was what you had talked about at one time | 15:37.29 |
| Robin_Watts | mvrhel: That's not easy. | 15:37.45 |
| mvrhel | and add in the channel number into the html (like you have the page for multi-page docs) | 15:37.53 |
| Robin_Watts | Yeah, I'd wondered about loading a w*h*n bitmap as n w*h bitmaps. | 15:38.21 |
| mvrhel | yes | 15:38.35 |
| Robin_Watts | but I've actually loaded it as a single w*h*n bitmap. | 15:38.39 |
| | because that was easier. | 15:39.03 |
| mvrhel | ok. oh and you cant loop on the n? | 15:39.16 |
| Robin_Watts | (and it means the cmyk -> rgb stuff all still works) | 15:39.19 |
| | It *should* all work exactly as we want, (with the exception that the spots won't be converted down when outputting the rgb versions) | 15:40.06 |
| | but the diff locations should be shown. | 15:40.13 |
| mvrhel | ah ok | 15:40.21 |
| Robin_Watts | but for some reason the diff locations aren't showing. | 15:40.23 |
| mvrhel | i see | 15:40.29 |
| | ok I misunderstood | 15:40.34 |
| Robin_Watts | I'm trying to see what silly typo I've made at the moment. | 15:40.36 |
| mvrhel | so you have a bug somewhere | 15:40.40 |
| Robin_Watts | yeah. | 15:40.48 |
| mvrhel | ok. i wont bother you. but I will be here if you need anything | 15:41.05 |
| Robin_Watts | D'Oh. >>8 does not divide by 8 :) | 15:42.54 |
| kens | :-) | 15:43.01 |
| mvrhel | hehe | 15:43.07 |
| Robin_Watts | OK. My example now works. Let me try yours | 15:43.18 |
| mvrhel | cool! | 15:43.23 |
| Robin_Watts | mvrhel: OK. I have something that seems to work. | 15:53.35 |
| mvrhel | Robin_Watts: ok great. is there a way to add in a fuzzy component too? | 15:54.12 |
| kammerer | Robin_Watts: hi Robin, look for this file as example http://www.mediafire.com/?ht40q6k9318cnl9 ,on first 10 page turn mucbz eat 128mb, on next 10 - 256mb | 15:54.20 |
| Robin_Watts | bmpcmp supports -w and -t already. | 15:54.37 |
| mvrhel | ok so refresh my mind on -w and -t? | 15:54.52 |
| Robin_Watts | and that should all work with the new psdcmyk stuff. | 15:54.55 |
| | -w and -t have the same mad values that fuzzy takes :) | 15:55.10 |
| | -w sets a window | 15:55.20 |
| | so -w 1 means 'just search 1 pixel', -w 3 means 'search a diamond shape 3 wide, 3 high centred on the current pixel. | 15:56.04 |
| | -t is a threshold. So -t 16 means 'allow pixels to match as long as they don't differ in any component by more than 16' | 15:56.46 |
| mvrhel | ok and t is the threshold diff it will use to report a diff? | 15:56.48 |
| | ok | 15:56.52 |
| | I am confused a bit on the window though | 15:57.05 |
| | but I likely will just use 1 | 15:57.15 |
| | with the window is is computing an average in the window? | 15:57.37 |
| | and comparing that? | 15:57.41 |
| | I could see where that would be ok for comparing halftones | 15:58.05 |
| | and trying to filter out diffs | 15:58.15 |
| kens | Intriguing that pdfwrite seems to cause GS to cache 'fm pairs' whereas rendering the same job does not. Resulting in much larger 'leakage' when using pdfwrite. Seems to be caused by getting glyph widths, I guess teh PCL interpreter never does thart. | 15:58.19 |
| Robin_Watts | mvrhel: The window is just to allow for small movements. | 15:58.57 |
| | (i.e. suppose we make a change that changes the rounding used, and various lines shift in the output by a pixel) | 15:59.59 |
| mvrhel | Robin_Watts: ah ok so it is used to filter out small spatial movements | 16:00.35 |
| | ok I will not be using that | 16:00.52 |
| | Robin_Watts: let me know when you get this committed | 16:01.03 |
| | please | 16:01.05 |
| | and thank you! | 16:01.11 |
| Robin_Watts | mvrhel: Committed. | 16:03.25 |
| | Now you may need to get marcosw_ to do some cluster fiddling to make psdcmyk called. | 16:03.43 |
| mvrhel | oh | 16:03.52 |
| | ok | 16:03.54 |
| | marcosw_? | 16:04.08 |
| | looks like marcosw_ is not here :( | 16:11.21 |
| Robin_Watts | Somewhere there needs to be something in the cluster code to say what devices are tested. | 16:12.52 |
| | Is psdcmyk tested usually? | 16:13.00 |
| mvrhel | yes it is tested | 16:13.05 |
| | I was just about to look at the code | 16:13.14 |
| Robin_Watts | And then there should be something to say which types get fed to bmpcmp. | 16:13.15 |
| mvrhel | yes | 16:13.19 |
| Robin_Watts | And I can't find that at the moment. | 16:13.27 |
| | Let me text marcosw. | 16:15.36 |
| marcosw_ | mvrhel: sorry, I wasn't paying attention to the computer. | 16:17.17 |
| mvrhel | well your computer was feeling neglected | 16:17.31 |
| | ;) | 16:17.36 |
| | marcosw_: so not sure if you follow everything above | 16:17.59 |
| Robin_Watts | marcosw_: I've just committed an updated bmpcmp that should do psd files. | 16:18.03 |
| marcosw_ | I think I understand, you need the cluster master to bmpcmp psdcmyk files. | 16:18.41 |
| Robin_Watts | So we'd like the cluster to feed the output from the psdcmyk device into bmpcmp too. And I can't see where to do that. | 16:18.43 |
| marcosw_ | probably in build.pl... | 16:18.55 |
| | yup, line 832 | 16:19.35 |
| | should be done. | 16:20.08 |
| Robin_Watts | Ah. I see it. Thanks. | 16:20.44 |
| | So now when the cluster falls in a heap, it'll be my fault :) | 16:21.05 |
| marcosw_ | I was the one to make the change, so you can blame me :-) | 16:21.40 |
| | you just told me what to do. | 16:21.50 |
| mvrhel | cool. thanks for you help on this | 16:22.00 |
| | hopefully I will be able to get this stuff wrapped up soon. | 16:22.12 |
| Robin_Watts | marcosw_: Yes, but I fear it will be bmpcmp that explodes, not the cluster :) | 16:22.51 |
| henrys | kens:didn't quite understand if I should look at hurd.pcl or it's something you need to at in pdfwrite? | 16:24.06 |
| kens | henrys, its a reminder to em | 16:24.19 |
| | me | 16:24.21 |
| henrys | okay | 16:24.23 |
| kens | Its fine when rendering but when run under Memento I see *lots* of corrupted memory bloacks | 16:24.45 |
| Robin_Watts | kens: Does Memento say how they are corrupted? | 16:25.10 |
| kens | I'm still trakcing down leaks at the moment though | 16:25.11 |
| Robin_Watts | overrun, underrun, write after deallocation etc? | 16:25.22 |
| kens | Robin_Watts : it says a great deal, I haven't read it :-) | 16:25.26 |
| | I just noticed the errors when chasing somethign else | 16:25.41 |
| Robin_Watts | ok. | 16:25.44 |
| | henrys: I have indeed broken stroking. I've got a fix for part of the problem here. | 16:30.09 |
| marcosw_ | henrys: do want to have a support meeting? I haven't checked open bugs in a couple of days, so am not sure we need one. | 16:34.30 |
| henrys | okay I still expect some residual problems that will have to addressed in gl/2 with the new filling. | 16:34.47 |
| | marcosw_:I don't think so | 16:34.57 |
| | marcosw_:3 new bugs this week sigh. | 16:35.24 |
| marcosw_ | sorry about http://bugs.ghostscript.com/show_bug.cgi?id=692970 | 16:35.38 |
| henrys | yes minutes before the stats report !!! it doesn't matter. | 16:36.26 |
| | it probably is a memory leak that should be fixed. | 16:37.14 |
| mvrhel | Robin_Watts and marcosw_: ok trying bmpcmp now.... | 16:47.18 |
| | with -5 5 | 16:47.39 |
| | with -t 5 | 16:47.44 |
| marcosw_ | standing by with the fire extinguisher... | 16:48.00 |
| Shyren | I am printing using ghostscript but output is not that sharp. How do I make it sharper? | 16:56.41 |
| marcosw_ | Robin_Watts: the bmpcmp isn't working, the nodes are reporting the following error: | 16:57.14 |
| | ./temp/bmpcmp/tests__Ghent_V3.0__051_Font_subset_PSnames_ident_x1a.pdf.psdcmyk.72.0.*: No such file or directory | 16:57.16 |
| | when trying to scp the diff binaries | 16:57.29 |
| | did you commit and push the bmpcmp.c changes? | 16:58.11 |
| Robin_Watts | I did. | 16:58.21 |
| marcosw_ | right, but the nodes didn't need to run that job since no files changed that affect ghostscript, so didn't do a fetch | 16:59.09 |
| mvrhel | oh | 17:00.08 |
| | so do I need to rerun my bmcmp marcosw_? | 17:00.21 |
| marcosw_ | mvrhel: yes you will, but first I need to either update the ghostpdl source on each node or force a cluster run. I think I'll do the latter. | 17:00.55 |
| mvrhel | I have done a cluster push since robins commit | 17:01.17 |
| | anyway, let me know when I am good to go please | 17:01.54 |
| | should I abort the current bmpcmp? | 17:02.11 |
| marcosw_ | mvrhel: it's not a clusterpush that's needed. bmpcmp.c is compiled from the master ghostpdl directory. The nodes need to do a git pull and git reset of the ghostpdl.git repository. | 17:03.58 |
| | I just aborted the job and force a cluster run. | 17:04.46 |
| | and requeued mvrhel's bmpcmp | 17:07.09 |
| mvrhel | oh wow thanks | 17:07.17 |
| marcosw_ | so the nodes have updated bmpcmp.c. I'll now abort the job since there's now point waiting 30 minutes. This should cause mvrhel's job to run next. | 17:09.30 |
| | oops, didn't wait long enough for the nodes to get the abort⦠I'll try again. | 17:10.12 |
| | mvrhel: I think everything is okay with the cluster now, but your new code is generating a lot of empty psd files. I.e. this command: | 17:24.12 |
| | ./gs/bin/gs -o test.psd -dMaxBitmap=30000000 -sDEVICE=psdcmyk -r72 tests_private/comparefiles/Bug690489.pdfGPL | 17:24.13 |
| | generates a psd file which is 368 bytes long | 17:24.26 |
| mvrhel | hmm. let me try that here | 17:27.20 |
| | files are ok on windoze | 17:36.33 |
| | let me try on ubuntu | 17:36.59 |
| | hmm something may have been wrong here | 17:41.31 |
| | well no just needed to clean | 17:43.31 |
| marcosw_ | mvrhel: I have to run to dinner, but will try and confirm the results I'm seeing on another cluster node. | 17:46.17 |
| | when I return. | 17:46.24 |
| mvrhel | ok. bmcmp -t 5 did not show any psdcmyk stuff | 17:46.43 |
| | dinner where are you? | 17:46.57 |
| | that file ran fine on windows. testing now on my ubuntu | 17:47.19 |
| | but it did *not* run ok on ubuntu. file is small like you said | 17:49.45 |
| | ugh! | 17:49.48 |
| | marcosw_ : so there is nothing for you to do. I will need to track this down | 17:50.06 |
| | what a pain | 17:50.21 |
| marcosw_ | mvrhel: I'm in Germany :-) | 17:50.30 |
| mvrhel | sehr gut | 17:50.42 |
| | I am going to go run some errands and then tackle this issue when I get back | 17:52.23 |
| | oh this is lovely. the debug version on ubuntu draws it just fine. but not the release version | 18:00.34 |
| | Robin_Watts: any clever ways to figure out what might be going on here? | 18:00.54 |
| | let me check the windows release actually | 18:01.33 |
| | ok windows release is fine. so it is just the ubuntu release version that fails to put anything meaningful in the file. I guess I can take a look at what it has with hexedit | 18:07.20 |
| Robin_Watts | mvrhel: Urm... | 18:07.59 |
| | printf? :) | 18:08.28 |
| mvrhel | yes. I fear that it might come to that | 18:08.40 |
| | first though, I am going to see what *is* in the file | 18:08.48 |
| | header info is the smae | 18:10.06 |
| Robin_Watts | My first guess would be that you have an uninitialised variable (or block of memory) | 18:10.38 |
| | The debug version may init memory to zero. | 18:10.54 |
| mvrhel | hmm valgrid should catch that | 18:11.12 |
| | yes? | 18:11.26 |
| Robin_Watts | yes. | 18:11.33 |
| vtorri | hey | 18:12.04 |
| ghostbot | hello, vtorri | 18:12.04 |
| vtorri | did you already see that error message : | 18:12.14 |
| | xps/xps_xml.c:379:3: error: format not a string literal and no format arguments [-Werror=format-security] | 18:12.24 |
| | ? | 18:12.25 |
| | mupdf 0.9 | 18:12.36 |
| Robin_Watts | Is it still there in mupdf 1.0 ? | 18:12.58 |
| vtorri | i don't know | 18:13.06 |
| | i've not tested mupdf git | 18:13.16 |
| | wait | 18:13.18 |
| | mupdf 1.0 has been released ? | 18:13.27 |
| Robin_Watts | We have an rc1 out for it. | 18:13.35 |
| vtorri | ha | 18:13.38 |
| mvrhel | hmm a issue in pds_write_image_data.... | 18:14.12 |
| vtorri | the fact is : we provide the mupdf source code in our project | 18:14.22 |
| | so usually, i'm waiting for a release to update | 18:14.35 |
| | i don't have the error myself | 18:14.47 |
| | but a guy is using gcc 4.7 for our project | 18:15.00 |
| | and he saw that error | 18:15.05 |
| mvrhel | found it! | 18:15.12 |
| Robin_Watts | Well, it would make sense for you to test with rc1. | 18:15.18 |
| | mvrhel: Fab. | 18:15.21 |
| mvrhel | Robin_Watts: thanks! | 18:15.23 |
| Robin_Watts | not sure I did much :) | 18:15.34 |
| mvrhel | well you got me thinking to try valgrind | 18:16.06 |
| vtorri | always try valgrind | 18:16.16 |
| mvrhel | that is the most amazing tool. | 18:16.24 |
| vtorri | it's a wonderful piece of software | 18:16.33 |
| mvrhel | Robin_Watts: question | 18:21.21 |
| | how do a do a cluster push followed by a bmp -t 5 all in one line. then I am going to run my errands | 18:21.41 |
| | I just did not want the bmpcmp that I do to cause the regular push to abort | 18:22.58 |
| | henrys: do you know how to do this? | 18:23.43 |
| | if no one is here, I will just go ahead and do the cluster push first | 18:25.04 |
| Robin_Watts | git cluster bmpcmp -t 5 pcl ? | 18:25.12 |
| mvrhel | just did the cluster push. if I did a clusterpush.pl with bmpcmp now, would it kill the current one I just did? | 18:26.07 |
| Robin_Watts | It won't kill it. | 18:26.14 |
| mvrhel | ok | 18:26.19 |
| Robin_Watts | Whether it will queue it or not... I don't know. | 18:26.24 |
| mvrhel | oh | 18:26.34 |
| | well I will try. at least the clusterpush will go through its stuff | 18:27.30 |
| | shows it on the queue | 18:27.57 |
| | ok bbiaw | 18:28.12 |
| Shyren | I am using hpdj340 and creating a pal to print to H470 but output is not that sharp. How can I get sharper output? | 19:04.59 |
| henrys | the driver contributed and we don't maintain it best thing it to try and track down the maintainers but it's quite possible they've moved on. Other that you need to study the device driver source code. | 19:28.52 |
| | Shryren:sorry the first words should be: The driver was contributed... | 19:29.42 |
| Shyren | henry: Thanks. Any idea which device would be best for H470 Officejet from HP. Its supposed to use HP PCL 3 enhanced PDL. | 19:40.22 |
| mvrhel | ok no diffs with -t 5. let me see what we get without -t | 19:55.18 |
| | hmm Robin_Watts and marcosw_ psdcmyk output does not seem to be showing up for me | 20:22.25 |
| | when I do the bmcmp | 20:22.29 |
| | any help on figuring out the issue would be greatly appreciated | 20:23.40 |
| | I know it is late though in Europe.... | 20:25.14 |
| | on a friday night | 20:25.29 |
| henrys | for linux: http://hplipopensource.com/hplip-web/models/officejet/officejet_h470.html but you could have googled that as well as I, I don't have further info - how good it is etc. | 20:25.46 |
| mvrhel | henrys: are you familiar enough with the bmpcmp calls from the cluster nodes to maybe see what the issue might be | 20:26.43 |
| | I wonder where it stores the files that it is going to compare | 20:27.09 |
| | then at least I can see if those are present | 20:27.17 |
| | logs are for the last cluster push not bmpcmp... | 20:28.26 |
| | henrys: not sure if I know how to get to any of the cluster nodes except for peeves and that one is down | 20:31.20 |
| | poking around in the cluster files for any sign.... | 20:38.51 |
| marcosw_ | mvrhel: I just got back and will take a look at one of the nodes. In theory there should be enough information on casper, but sometimes it's just easier to look at one of the nodes. | 20:40.31 |
| mvrhel | ok. I am looking on casper for any signs. | 20:40.54 |
| | bascially the clusterpush showed a lot of diffs iwith psdcmyk, but the bmpcmp gave nothing | 20:41.19 |
| | I found the bug that caused the earlier issue, where the new code had a tiny file (that was only the header) | 20:41.54 |
| marcosw_ | the psdcmyk appear to be correct... | 20:43.27 |
| mvrhel | oh why do I get the diffs though in the clusterpush I wonder. unless there is an issue in the non-image data | 20:44.13 |
| | a difference that is | 20:44.19 |
| | so the md5 is different | 20:44.41 |
| | but the image data is ok | 20:44.44 |
| | i can live with that | 20:44.54 |
| marcosw_ | i think the bmpcmp is not working, but I'm still checking. | 20:44.55 |
| mvrhel | oh | 20:44.58 |
| marcosw_ | as far as I recall there isn't anything in a psdcmyk file that should vary if the bitmap is the same. | 20:47.49 |
| mvrhel | yes. it is a pretty simple format | 20:48.08 |
| | and I did not change any part of the header code | 20:48.21 |
| henrys | I'll be checking in periodically sorry I missed you the first time but it looks like marcosw_ is around and he knows more than I do. | 20:49.19 |
| mvrhel | no problem. I just really want to get this wrapped up | 20:49.52 |
| marcosw_ | so if I manually compare a psdcmyk file generated with master vs. your code I get this error from bmpcmp: | 20:51.15 |
| | Can't compare images (w=612,612) (h=792,792) (s=2448,2448) (bpp=32,32) (cmyk=32700,4)! | 20:51.15 |
| mvrhel | huh? | 20:52.31 |
| | oh I see | 20:52.41 |
| marcosw_ | I presume that bmpcmp.c is saying the images don't match. | 20:52.52 |
| mvrhel | who had the 32700 and who had the 4 | 20:52.58 |
| | I can look | 20:53.02 |
| | I know exactly where this is set | 20:53.11 |
| | thanks marcosw_ | 20:53.19 |
| marcosw_ | I specified the new file first, so presumably the 32700 is from your updated code. | 20:53.27 |
| mvrhel | ok | 20:53.34 |
| marcosw_ | btw, this exposed a bug in the cluster code, the stderr of bmpcmp is not captured. I'll fix that... | 20:53.56 |
| mvrhel | I think the issue is with the reading in bmpcmp | 20:58.50 |
| | I am writing out 4 | 20:58.54 |
| marcosw_ | mvrhel: there is something odd going on. if I run bmpcmp twice I get different std err messages: | 20:58.56 |
| | bmpcmp ./temp/tests_private__comparefiles__Bug690489.pdf.psdcmyk.72.0 baselineraster/tests_private__comparefiles__Bug690489.pdf.psdcmyk.72.0 100 0 | 20:59.04 |
| | produces | 20:59.06 |
| | Can't compare images (w=1134,1134) (h=567,567) (s=4536,4536) (bpp=32,32) (cmyk=32614,4)! | 20:59.11 |
| | running it again | 20:59.16 |
| | Can't compare images (w=1134,1134) (h=567,567) (s=4536,4536) (bpp=32,32) (cmyk=32739,4)! | 20:59.19 |
| | is that at all reasonable? | 20:59.30 |
| mvrhel | no | 20:59.37 |
| | that would mean the header changed | 20:59.47 |
| | so I think the issue is in robins stuff | 21:00.03 |
| marcosw_ | which doesn't make any sense, since I didn't change the psdcmyk file between runs. | 21:00.06 |
| mvrhel | where is this code located | 21:00.08 |
| marcosw_ | ./ghostpdl/gs/toolbin/bmpcmp.c | 21:00.17 |
| mvrhel | ok let me take a look at that | 21:00.26 |
| | hmm he has a check fprintf(stderr, "We only support CMYK psd files!\n"); | 21:01.46 |
| | that should have caught any issue earlier | 21:01.57 |
| | let me build and step through the debugger to see | 21:03.02 |
| marcosw_ | um, it may be late and I may have had too much beer (as if there is such a thing) but where in the heck does the code set *cmyk in psd_read()? | 21:03.52 |
| mvrhel | in the read | 21:04.19 |
| | it passes and address | 21:04.27 |
| | cmyk and cmyk2 | 21:04.45 |
| | oh | 21:04.56 |
| | but it is not set | 21:04.59 |
| | should be at line 1096 | 21:05.16 |
| | good catch | 21:05.21 |
| marcosw_ | I think: *cmyk = c; | 21:05.21 |
| mvrhel | go ahead and fix | 21:05.36 |
| | and see if that does it | 21:05.40 |
| marcosw_ | I'm testing it on one of the nodes first. If it works I'll fix it in the repository but will have to trick casper into running a cluster job. | 21:06.19 |
| mvrhel | sounds good to me | 21:06.30 |
| marcosw_ | that fixed the error, but still no outputted difference files. | 21:07.56 |
| | btw the bmpcmp code only compares the first page... | 21:08.07 |
| | so if the difference was on the 2nd or later page it would act just like this. | 21:08.22 |
| mvrhel | that doesnt make sense. I have seen ps files that show other pages | 21:08.34 |
| | and the page number is given on the html page | 21:08.48 |
| marcosw_ | you think the comment in bmpcmp.c that says: | 21:09.01 |
| | /* There is only one image in each file */ | 21:09.02 |
| | is false? | 21:09.08 |
| mvrhel | depends upon how the call is made with ghostscript to get the page | 21:09.42 |
| | then bmpcmp would only do that one page | 21:09.49 |
| | I don't know how you all have constructed this rube goldberg set up ;) | 21:10.22 |
| marcosw_ | well the rubeiest (sp?) part is bmpcmp, and that's not my fault. | 21:10.56 |
| mvrhel | hehe | 21:11.02 |
| marcosw_ | god, the whole bmpcmp.c program is a hack... | 21:13.12 |
| | also has the annoying convention of: | 21:13.26 |
| | for (â¦) | 21:13.29 |
| | { | 21:13.30 |
| | } | 21:13.31 |
| | instead of the much better: | 21:13.36 |
| | for (â¦) { | 21:13.39 |
| | } | 21:13.40 |
| mvrhel | yes. when you are used to one, the other is hard to read | 21:14.09 |
| marcosw_ | well page 1 of the file I just checked is the same. I'll check the rest and see if I can one that isn't and try bmpcmp on that. | 21:16.21 |
| | okay. that worked. tests_private__pdf__PDFIA1.7_SUBSET__IA3Z1351.pdf.psdcmyk.72.0.gz has a difference on page 1 and bmpcmp produces a set of png files and a meta file. I'll go ahead and fix the copy in the repository and push the change to the nodes. | 21:20.35 |
| mvrhel | ok thanks marcosw_ | 21:21.44 |
| marcosw_ | I'm re-running the code now but am still seeing bmpcmp produce error on some files: | 21:43.37 |
| | tests_private__comparefiles__245-01.ps.psdcmyk.72.0 | 21:43.44 |
| | Can't compare images (w=612,612) (h=792,792) (s=2448,3060) (bpp=32,40) (cmyk=4,4)! | 21:43.45 |
| | and | 21:43.47 |
| | tests_private__comparefiles__470-01.ps.psdcmyk.72.0 | 21:43.53 |
| | Can't compare images (w=612,612) (h=792,792) (s=2448,3060) (bpp=32,40) (cmyk=4,4)! | 21:43.53 |
| mvrhel | oh interesting | 21:45.19 |
| | who has the 32 and who has the 40? these must have 5 channels | 21:45.44 |
| | hence the 40 bits | 21:45.50 |
| marcosw_ | baseline is second | 21:46.07 |
| mvrhel | let me check this file | 21:46.10 |
| | oh | 21:46.12 |
| | ok | 21:46.14 |
| | so that might be my goof up | 21:46.19 |
| marcosw_ | you mean we normally write 5 channel cmyk files? | 21:46.34 |
| mvrhel | this file could have a spot color | 21:47.25 |
| marcosw_ | right, i was thinking of the tiffsep format and these being the composite, which wouldn't have a spot color. but the psdmyk files have all the channels in one file. | 21:48.15 |
| mvrhel | yes | 21:48.25 |
| | still nothing in my bmpcmp html output | 21:49.38 |
| | after I fix the bpp issue I will run without -t | 21:49.59 |
| marcosw_ | hold on, there is still an issue with the cluster code. if I run bmpcmp manually I get output, even with -t 5 | 21:50.29 |
| mvrhel | oh | 21:50.37 |
| marcosw_ | I think bmpcmp is failing since it's trying to fseek() when reading psd file and that fails since we are calling it like this: | 21:54.26 |
| | ./bmpcmp <(gunzip -c ./temp/tests_private__comparefiles__Clarke-Tate-Manns-Chinese.ai.psdcmyk.72.0.gz) <(gunzip -c ./baselineraster/tests_private__comparefiles__Clarke-Tate-Manns-Chinese.ai.p | 21:54.27 |
| | sdcmyk.72.0.gz) | 21:54.27 |
| mvrhel | hmm. bpp diff means number channels is different | 21:54.54 |
| marcosw_ | I can hack the cluster to gunzip psdcmyk files and then pass them directly to bmpcmp, they'll be slower but at least they'll work correctly. | 21:55.29 |
| | more rube goldberg bits. | 21:55.40 |
| mvrhel | is there a place where I can see and catch issues like Can't compare images (w=612,612) (h=792,792) (s=2448,3060) (bpp=32,40) (cmyk=4,4)! | 21:56.29 |
| | I know it is getting late there. | 21:59.14 |
| | hmm I dont see why 470-01.ps would have 5 channels | 22:01.59 |
| | oh I see | 22:02.36 |
| | GenoaGreen | 22:02.43 |
| | Actually for this file, my fix is correct | 22:05.54 |
| | the trunk is wrong | 22:05.57 |
| marcosw_ | so I've hacked the cluster so that it now gunzips the input to bmpcmp before calling it rather than using redirection, so that should give you some output files. | 22:08.03 |
| mvrhel | ok. marcosw_ thanks | 22:08.50 |
| | what do I need to do to kick this off again? | 22:08.59 |
| | oh you already started it | 22:09.40 |
| marcosw_ | okay, it's now producing some output files from bmpcmp for the psdcmyk files. I'll fix the cluster so that bmpcmp std err output is captured so you can find the files that error out (since currently they act as if there were no differences). | 22:11.59 |
| mvrhel | great thanks | 22:12.11 |
| | where will I dind the err output? | 22:12.50 |
| | or will I get an email? | 22:12.54 |
| | s/dind/find/ | 22:13.17 |
| | ok yes, now I am seeing output | 22:17.18 |
| Robin_Watts | mvrhel, marcosw_: Do you guys need anything from me? | 22:17.46 |
| marcosw_ | Robin_Watts: a couple of questions/comments: | 22:18.00 |
| Robin_Watts | Yes, bmpcmp is frankensteined together out of some old code. | 22:18.30 |
| mvrhel | oh this is good. I am finding useful stuff now | 22:18.46 |
| marcosw_ | bmpcmp is normally called like this: bash -c "/bmpcmp $bmpcmpOptions <(gunzip -c $outputFilename.gz) <(gunzip -c $baselineFilename.gz) â¦" | 22:18.58 |
| | this fails with psdcmyk since fseek() doesn't work. | 22:19.15 |
| mvrhel | although I am not sure the -t is working | 22:19.22 |
| Robin_Watts | Ah. | 22:19.25 |
| | I can fix that. | 22:19.33 |
| marcosw_ | 2nd the psdcmyk part of bmpcmp is only comparing the first page, correct? | 22:19.38 |
| Robin_Watts | (I can remove the requirement for seeking - would that help?) | 22:19.47 |
| mvrhel | Robin_Watts | 22:20.49 |
| | so if you get a chance (I know it is late) | 22:20.59 |
| | look at my bmpcmp at 50 and 51 | 22:21.21 |
| Robin_Watts | Do we output more than one psd file into a single file? | 22:21.24 |
| marcosw_ | Robin_Watts: I hacked the cluster code so that it gunzips the files and calls it without the redirection, but that's a performance issue. | 22:21.32 |
| Robin_Watts | mvrhel: Well, that looks like I'm getting the spans wrong. | 22:22.27 |
| mvrhel | yes | 22:22.34 |
| | I think it might be when there are spot colors | 22:23.59 |
| | as number 84 I know has spots | 22:24.10 |
| | ok look like I have an issue with image masks | 22:25.39 |
| | 159 is just weird | 22:26.23 |
| | ok this was all a big help in isolating at least one issue | 22:27.50 |
| marcosw_ | mvrhel and Robin_Watts: I going to pack and go to bed. I'm traveling tomorrow and probably won't have much time to check email (only a short layover in Frankfurt), but will be around Sunday as well as all of next week. | 22:28.35 |
| Robin_Watts | marcosw_: Have fun. | 22:28.58 |
| mvrhel | marcosw_: thanks for your help | 22:29.32 |
| | safe travels! | 22:29.36 |
| marcosw_ | the seat map for my flight looks like the plane is > half empty, so should be a comfortable trip (as much as economy is ever comfortable) :-) | 22:29.55 |
| Robin_Watts | ok, so I've got a version here that removes the need for seeking. | 22:30.54 |
| | let's see if I can reproduce the 50/51 problem. | 22:31.15 |
| mvrhel | that is an interesting one | 22:31.23 |
| | i have to step out for a bit. you will probably be asleep when I get back Robin_Watts. just leave me a note on irc if you fix something. | 22:32.12 |
| Robin_Watts | mvrhel: bmpcmp diffs that file just fine for me :( | 22:47.53 |
| | mvrhel: I've commited a new bmpcmp. I can't reproduce the stripey problems here. | 22:54.41 |
| | If you can get 2 .psd files, then do: | 22:55.17 |
| | bmpcmp file1.psd file2.psd diffout | 22:55.33 |
| | That should produce various files starting with diffout. If those look stripey, then get me the psd files in question and I'll figure out why. | 22:56.12 |
| mvrhel | Robin_Watts: ok thatks | 23:45.11 |
| | Forward 1 day (to 2012/04/07)>>> | |
IRC Logs