| | <<<Back 1 day (to 2012/07/22) | 2012/07/23 |
| cryptopsy | it seems FirstPage and LastPage in my offset command make it so that only those offset pages are output, isntead of the whole document with offsets in only certain pages | 00:07.40 |
| | is there an option to produce the entire document instead of only the affected pages? | 00:08.05 |
| Robin_Watts | henrys: 9th and 10th. | 00:09.59 |
| | I fly in on the 8th and out on the evening of the 10th | 00:10.11 |
| cryptopsy | gs -sDEVICE=pdfwrite -o /tmp/print-"$i"-"$j" -dFirstPage=$j -dLastPage=$j -dPDFSETTINGS=/prepress -c "<</PageOffset [-72 0]>> setpagedevice" -f /tmp/print-"$i" | 00:11.17 |
| | $i is for the current document, $j is for it's pages | 00:11.27 |
| | is it possible to add left-padding to a page with gs, or do i have to offset and use a different paper ize? | 00:26.09 |
| | size* | 00:26.13 |
| ray_laptop | cryptopsy: ghostscript can run pages with PostScript commands, then you can apply actions to individual pages or groups of pages. | 04:07.44 |
| | cryptopsy: but if you want to fit and center pages on an input PDF into a PDF with some fixed page size, you may want to try -dPDFFitPage with -dFIXEDMEDIA and media size specified on the command line. | 04:09.04 |
| cryptopsy | can i have the solution please? | 04:09.32 |
| | adding a margin shouldn't have me calculate page widths | 04:09.45 |
| | i had a solution for this before which i lost in a disk crash | 04:09.54 |
| ray_laptop | cryptopsy: to process pages programmatically using the PS interpreter, use: (____) (r) file runpdfbegin % where ____ is the file path | 04:10.01 |
| cryptopsy | the final goal is to offset pages left and right for book printing on double-sided sheets | 04:10.08 |
| | not sure how to use your command | 04:10.31 |
| | what flag do i pass it to 'gs' | 04:10.38 |
| ray_laptop | cryptopsy: then set the PageOffset or do the Install page proc with setpagedevice, then process the selected group of pages with: N M dopdfpages % where N is the first page and M is the last page | 04:11.07 |
| | cryptopsy: you can feed the entire PS script to gs using the -c operator, but it would be easier to put the PS script into a temp file and just tell gs to execute that PS file (which then opens the input PDF and runs) | 04:12.24 |
| | if it's in a temp file just put it after the -f | 04:13.01 |
| | cryptopsy: if you want a margin on ALL pages, then you can just use the single Install proc (or PageOffset, which I never use, but I think works) | 04:14.09 |
| cryptopsy | i want a margin on one page at a time without burst the original | 04:14.20 |
| ray_laptop | but if you need a different offset for different pages then the: N M dopdfpages is the only approach | 04:14.52 |
| cryptopsy | Pageoffset places the page outside of the paper boundary | 04:15.02 |
| ray_laptop | cryptopsy: I haven't played with PageOffset, so I don't know if that is correct, or why you are using it | 04:15.35 |
| cryptopsy | it's correct, using it because i saw it in an exaple on how to offset pages | 04:15.50 |
| | [the fact that it places pages outside of boundary is correct] | 04:16.07 |
| ray_laptop | cryptopsy: why do you need different offsets for different pages | 04:16.13 |
| cryptopsy | which is not desired | 04:16.16 |
| | ray_laptop: book printing | 04:16.22 |
| | the spine of the book makes it hard to read text near the spine | 04:16.35 |
| | you know what i mean? | 04:16.39 |
| ray_laptop | cryptopsy: it's outside the page area because you told it -72 0, right ? | 04:16.43 |
| cryptopsy | what? | 04:16.52 |
| | how do you propose i move the page 72dpi left (thus increasing the paper width by 1 inch) ? | 04:17.24 |
| ray_laptop | cryptopsy: There is another setpagedevice proc that is often used to 'place' pages depending on page number | 04:17.28 |
| cryptopsy | am so confused, sorry | 04:17.42 |
| ray_laptop | if you want to increase the page size, you need to use /PageSize [ W H ] , possibly also with an offset | 04:18.19 |
| cryptopsy | no ... | 04:18.27 |
| | i don't want to increase it | 04:18.30 |
| | it should do it by itself | 04:18.33 |
| ray_laptop | cryptopsy: you just said "thus increasing the paper width by 1 inch" | 04:18.58 |
| cryptopsy | yea, because you added a margin | 04:19.05 |
| | pretend you cut a strip with scissors out of paper and placed it next to your page | 04:19.17 |
| | the final area of the page is now larger, yes? | 04:19.23 |
| ray_laptop | the /Install { -72 0 translate } or the /PageOffset [ -72 0 ] keep the same page size, but move the image on the page one inch left, presumably leaving 1 inch to the right blank, but it may make the image 'clip' to the left since you can't image at Y < 0 | 04:20.50 |
| | so along with pasting a 1 inch strip to the right, it also trims one inch off the left of the page | 04:21.57 |
| | so the page size ends up the same size | 04:22.07 |
| cryptopsy | the page size should become bigger because we're adding | 04:22.20 |
| | shift are dangerous because you don't know if the text will not be visible | 04:22.38 |
| ray_laptop | NO! Only PageSize can add to the page size | 04:22.43 |
| | so if you want to keep the position of the image on the page the same distance from the left edge AND add a 1 inch right margin, you need to make the PageSize one inch wider | 04:23.39 |
| cryptopsy | yes | 04:23.46 |
| | pagesize can figure it out by itself, or i have to get initial page width? | 04:24.03 |
| ray_laptop | it DOESN'T do it by itself | 04:24.08 |
| | you can programatically with PS since the | 04:27.20 |
| | currentpagedevice operator can be used to get the current PageSize, then you can modify it and give to back to setpagedevice | 04:27.57 |
| | and as I said, you can do different pages differently if you want. | 04:28.58 |
| | I have to run and errand now -- I'll be back later.... (sorry) | 04:29.20 |
| cryptopsy | what's the cropbox? | 04:30.10 |
| | Page 2 MediaBox: [ 595 842 ] CropBox: [ 297.646 419.524 ] | 04:30.17 |
| | is the cropbox the minimum sized box that doesn't contain uniform colums or rows? | 04:30.40 |
| | tnx | 04:33.00 |
| ray_laptop | cryptopsy: the CropBox is supposed to be the "inked area" (if you trust the PDF creator). In my experience, books have the left pages (bound to the spine on the right) shifted left, and the right pages (bound to the left of the page) shifted right, with the same imaged area (maybe CropBox) width on both. | 05:32.01 |
| mvrhel | hi ray_laptop: so I fixed at least one of the issues that was going on with the psdcmyk device. although this particular one was related to transparency usage in the separation devices | 05:36.23 |
| | I still have one pesky *.ps file to deal with (a CET test) | 05:36.43 |
| | any luck with getting the proc switched over?' | 05:37.06 |
| ray_laptop | so if the page images are centered on the page, you may want "ImageShift" where the offset is applied differently to the 'recto' (front) and 'verso' (back) side of pages even/odd to allow for stapling/binding. | 05:38.48 |
| | but UNFORTUNATELY, in looking at ghostscript, we don't implement this :-( | 05:39.20 |
| | cryptopsy: however, we _do_ implement the BeginPage procedure which (according to the PLRM) can "Shift the positions of even- and odd-page images differently for binding" | 05:41.26 |
| | thus, I recommend that you use this. Note that the BeginPage proc can be more general than just even/odd pages in case the pages need different offsets -- the page number is available in the proc so that every page can have a unque offset. This is used for N-up printing on some printers | 05:43.11 |
| | mvrhel: I have fixed the NumRenderingThreads issues (the final commit is coming soon) | 05:43.44 |
| | one caused the SEGV because the device wasn't set up in planar mode at the correct time. | 05:44.30 |
| | the second was a BUNCH of messed up calculations of the buffer start address, and potential SEGV that I haven't verified | 05:45.25 |
| | the first fix is committed. the second is coming | 05:45.38 |
| | mvrhel: I also have the commit for the fill_rectangle_hl_color change coming -- let me know if you want a patch. My latest localcluster regression is with that change. | 05:47.15 |
| | it is still running at this time | 05:47.41 |
| mvrhel | ray_laptop: I wonder if those are the source of the issue with 12-07C.PS | 05:47.53 |
| ray_laptop | mvrhel: I don't know -- the results of the mixup between fixed and int coordinates _should_ not cause writing outside of a buffer since all writers are supposed to use 'fit_fill' to clip to the bounds | 05:49.06 |
| mvrhel | no not that | 05:49.22 |
| | "the second was a BUNCH of messed up calculations of the buffer start address, and potential SEGV that I haven't verified" | 05:49.32 |
| ray_laptop | by 'writers' I mean memory devices that write memory | 05:49.36 |
| mvrhel | I am seeing a clist issue with 12-07C.PS | 05:50.05 |
| | I have not dug into it yet | 05:50.17 |
| ray_laptop | mvrhel: that was ONLY with NumRenderingThreads > 1 (already committed was fix for SEGV when NumRenderingThreads=1) | 05:50.21 |
| mvrhel | I will start at it tomorrow | 05:50.22 |
| | ray_laptop: ok I understand. probably a different issue then | 05:50.47 |
| ray_laptop | I should have the first commit tonight (for NumRenderingThreads). The other I have a format-patch I can send you | 05:51.08 |
| mvrhel | my other segv was related to the fact that for the sep devices, transparency is handled in a special way | 05:51.15 |
| | and there was much confusion about that when we were dealing with a pattern within a softmask which had an RGB transparency group | 05:51.42 |
| ray_laptop | mvrhel: right. I didn't delve into the details, but understood the nature of the problem and oyur fix | 05:52.13 |
| mvrhel | I am curious what Gemma is talking about with respect to performance. | 05:53.02 |
| | I wonder if she is still doing the tiff scale up | 05:53.29 |
| ray_laptop | mvrhel: hard to tell -- they have (AFAICT) such a bastardized build that it's hard to reproduce | 05:53.40 |
| | if they send their command line, it should help. Also, we should (once I get the problem fixes committed) get them to try NumRenderingThreads (they probably have at least 4 core machines) | 05:55.19 |
| mvrhel | right | 05:55.32 |
| ray_laptop | but I have not wanted to mention that until getting the problems sorted out | 05:55.43 |
| | and also until I have a chance to try some of their files to see if performance is helped. | 05:57.09 |
| | Since they are using tiffsep (iirc) the problems caused by rendering multiple times for each plane should not be an issue | 05:58.08 |
| | I have to go -- I may check back before sleep. My regression is at 40% | 05:58.56 |
| | bbiab | 05:59.07 |
| | mvrhel: got a bunch of 1 pixel differences -- pretty much the same as previous runs... | 06:18.40 |
| | be back in the morning. | 06:18.51 |
| | grr... git is "close" but still so easy to get screwed up | 07:46.55 |
| kens | you're up late ray_laptop | 07:47.07 |
| ray_laptop | yep... so close, but now can't get my commits straightened out. :-( | 07:51.38 |
| kens | I'm afraid neither Robin_Watts nor tor is here :( | 07:52.00 |
| ray_laptop | I so a "git reset xxxxxx" and it still shows many modified files that I don't want to commit | 07:52.20 |
| | I guess I'll try reset --hard | 07:52.33 |
| kens | I use git gui and select the ones I want to add to the commit | 07:52.42 |
| ray_laptop | kens: the changes are all in local commits -- I just want to make sure and 'push' the right thing | 07:53.34 |
| kens | ray_laptop : then I don't know I'm afraid | 07:53.52 |
| | I am a very simple user of Git | 07:54.02 |
| ray_laptop | well, it looked OK after the git reset --hard so I went ahead and pushed it | 07:54.36 |
| kens | Then we shall see shortly :) | 07:54.50 |
| | Looks like its what you intended | 07:55.18 |
| ray_laptop | kens: please pull (git up) the current HEAD and see if the only files you see modified are gxclist.h and gxlcthrd.c | 07:55.40 |
| kens | ray that's what teh commit message says | 07:55.55 |
| ray_laptop | HURRAY !!! | 07:56.03 |
| kens | If I pull I expect I will get other files, I'm a bit behind | 07:56.08 |
| ray_laptop | that should resolve the NumRenderingThreads issues with psdcmyl | 07:56.29 |
| kens | 2 files changed, 15 insertions(+), 7 deletions(-) | 07:56.35 |
| | Exellent news ray_laptop | 07:56.44 |
| ray_laptop | s/psdcmyl/psdcmyk/ | 07:57.00 |
| kens | Time for bed, said Zebedee :-) | 07:57.42 |
| ray_laptop | Zebedee ??? not a reference I know, I'm afraid. | 07:59.06 |
| kens | The Magic ROundabout | 07:59.13 |
| | A children's programme from my youth | 07:59.21 |
| ray_laptop | thanks, I'll check it out. | 07:59.30 |
| kens | :-) | 07:59.36 |
| | Very surreal | 07:59.40 |
| | Was French, but with an English narration invented by the narrator | 07:59.54 |
| | So no relatyion to the (apprarntly very boring) French version | 08:00.08 |
| ray_laptop | oh, boy... a book with subtitles ??? | 08:00.19 |
| kens | A book ? | 08:00.36 |
| ray_laptop | or a TV show ??? | 08:00.36 |
| kens | TV show | 08:00.40 |
| | No subtitles though | 08:00.49 |
| | THe original French soundtrack was removed and replaced by English | 08:01.06 |
| ray_laptop | I see -- sort of like Thomas the Train -- with VERY boring english accent narrator speaking | 08:01.21 |
| kens | In a way :-) | 08:01.30 |
| ray_laptop | ;-) | 08:01.35 |
| kens | assumes Thomas the Train == Thomas the Tank Engine | 08:01.53 |
| ray_laptop | my 13 yr old boy is looking over my shoulder and says this sounds a lot like him and his friend texting back and forth (except maybe faster) | 08:02.33 |
| | kens: right | 08:02.45 |
| kens | Could be | 08:02.48 |
| | My dughter texts a lot, but now she facebook's endelssly too | 08:03.00 |
| ray_laptop | my 13yr old daughter has started tweeting a lot (I have to really keep an eye on her) | 08:03.43 |
| kens | We barred Facebook and Twitter until Melanie was 16 | 08:03.58 |
| | (blocked in the router) | 08:04.05 |
| ray_laptop | she's also the one that wants to be an author and is several chapters into two books | 08:04.09 |
| kens | Cool | 08:04.17 |
| | Most authors seem to start young | 08:04.24 |
| ray_laptop | kens: I very may well have to do that. | 08:04.27 |
| | (router block) | 08:04.35 |
| kens | 'Cruel and unusual punishment' Ray :-) | 08:04.41 |
| | So I'm told | 08:04.48 |
| | 'everyone in on Faebook' | 08:04.56 |
| | When we unblocked it we made it a condition that one of us (me & Stella) had to be a friend | 08:05.19 |
| ray_laptop | as long as I can monitor it, I guess we'll let it go for a bit (on twitter NOT facebook) | 08:05.34 |
| kens | Well, we felt 16 was old enough.... | 08:06.04 |
| | Got to let them have some freedom sometime | 08:06.15 |
| ray_laptop | my daughter's time is up for reading -- I have to go take her nook away. then go to bed myself. g'nite | 08:06.45 |
| kens | goodnight ray & fmaily | 08:06.58 |
| | family* | 08:07.03 |
| tor8 | Robin_Watts: more font tweaks on tor/master whenever you've got a few moments to spare | 10:36.19 |
| Robin_Watts | ok. | 10:39.43 |
| | Oh color handling, how do I love thee? Let me count the ways... | 11:48.31 |
| | It's far too early for that to really be mvrhel. | 11:59.09 |
| JediMaster | hi all, I'm trying to convert a pdf to a png, and it's been working fine until I've recently changed the fonts in the pdf. I've been using imagemagick to convert it, but the problem appears to be in ghostscript | 12:28.23 |
| | everything but the line of text in a particular font seems to show | 12:28.35 |
| | it's an embedded ttf font | 12:28.47 |
| kens | Sounds liek a font problem, any messages in the console window ? | 12:28.52 |
| JediMaster | none | 12:29.00 |
| kens | We will probably need to see the file though | 12:29.06 |
| JediMaster | it works fine in adobe reader | 12:29.08 |
| | sure, I can upload it | 12:29.17 |
| kens | OK give us a URL and I'll take a look. Which version of GS are you suing ? | 12:29.35 |
| JediMaster | 9.05 (2012-02-08) | 12:30.03 |
| | the default from Ubuntu 12.04 LTS | 12:30.13 |
| kens | Nice to see someone using an up to date version :-) | 12:30.13 |
| JediMaster | =) | 12:30.27 |
| | http://www.admiralcharitycards.org/test.pdf | 12:34.30 |
| kens | OK give me a moment | 12:35.01 |
| JediMaster | thanks for your help | 12:35.06 |
| | I've been trying to manipulate/convert/re-encode the font in fontforge but it hasn't helped | 12:35.33 |
| | you should see red text on the right | 12:35.53 |
| kens | Hmm, getting some warnings about the font | 12:36.16 |
| | loca length > NumGlyphs | 12:36.24 |
| chrisl | JediMaster: what text is missing? | 12:36.29 |
| JediMaster | I fixed that, but it still did it | 12:36.31 |
| kens | chrisl was about to ask that :-) | 12:36.39 |
| | Its oK for me with current code | 12:36.44 |
| | also command line you are using please JediMaster ? | 12:36.54 |
| JediMaster | chrisl: "With Best Wishes for Christmas" and new line "and the New Year" | 12:37.04 |
| kens | Yeah that's all tjhere in curren code and the display device | 12:37.19 |
| | But not in 9.05 | 12:37.36 |
| | So its a bug that's been fixed I woudl think | 12:37.42 |
| JediMaster | gs -dNOPAUSE -sDEVICE=jpeg -sOutputFile=image%d.jpg -dJPEGQ=100 -r300x300 -q test.pdf -c quit | 12:38.04 |
| | or /usr/bin/convert -antialias -density 300x300 test.pdf -resize 960x800 test.png | 12:38.30 |
| kens | THe next release 9.06 will be out in a few weeks I'd suggest you use that, or if you are confident about building GS you can pull a snapshot of the latest source | 12:38.34 |
| JediMaster | from imagemagick | 12:38.35 |
| chrisl | kens: I assume that's with our 9.05 release? | 12:38.56 |
| JediMaster | yes | 12:39.04 |
| kens | chrisl yes, I believe so | 12:39.11 |
| | The 9.05 release code has the text missing, the 9.06 pre-release code is OK | 12:39.30 |
| JediMaster | ok, glad to know I'm not doing something stupid | 12:39.35 |
| chrisl | Okay, so no point in me trying any shared libraries, or anything....... | 12:39.41 |
| kens | chrisl I wouldn't think so, I tried it on Windows :-) | 12:39.52 |
| | Sorry I can't give you a work-around JediMaster | 12:40.27 |
| JediMaster | might it work with an older version? | 12:42.10 |
| | I'm wondering if it's a 9.05 only issue? | 12:42.19 |
| chrisl | JediMaster: ah, as a *very* temporary workaround, you could use -dDisableFAPI - but that sends you through deprecated and unsupported code, so it is *not* a good long term solution. | 12:42.22 |
| kens | does that work chrisl ? | 12:42.34 |
| JediMaster | chrisl: let me try that, thanks | 12:42.50 |
| chrisl | Yes. I think I know what the problem was.... | 12:42.50 |
| kens | Yes, it does work for me, at least its a good work-around | 12:43.02 |
| chrisl | I *think* the problem was a couple of bytecode program errors I wasn't trapping properly, so we fallback to the notdef, instead of retrying with hinting disabled. | 12:43.49 |
| kens | Oh yes, that sounds familiar | 12:44.02 |
| JediMaster | sweet, that worked | 12:44.26 |
| kens | Sounds like the font is the real culprit, but its nice to be able to get round the problem. | 12:44.36 |
| JediMaster | yeah, it's happened to 3 out of 5 google fonts I've tried | 12:45.00 |
| | 2 of them work fine | 12:45.05 |
| chrisl | JediMaster: nevertheless, your font is broken...... btw, the DisableFAPI will disappear in a couple of releases..... | 12:45.18 |
| JediMaster | chrisl: ok, thanks for the heads-up | 12:45.42 |
| | and thanks for the work-around | 12:45.50 |
| | I'll go with jpeg format for the moment to save converting it twice | 12:46.09 |
| chrisl | JediMaster: Unfortunately, there are *so* many such broken fonts, we have to handle them :-( | 12:46.20 |
| JediMaster | chrisl: any idea what was broken in it? | 12:46.45 |
| | I tried validating it in fontforge and it passed | 12:46.55 |
| | and tried chopping & changing formats and back to ttf and still had the same issue | 12:47.13 |
| chrisl | JediMaster: it's erm, complicated...... | 12:47.32 |
| | TrueType fonts contain bytecode "programs" which (amongst other things) are supposed help to grid-fit and drop-out control the contours in the glyph. One or more of those is at fault. | 12:48.51 |
| JediMaster | heh, I had no idea the fonts had bytecode in them | 12:49.50 |
| kens | TrueType fonts are complex beasts.... | 12:50.07 |
| JediMaster | well thanks you very much for both of your help, it's taken me all morning to get to this point | 12:50.38 |
| chrisl | JediMaster: given what you say, it sounds like it might be fontforge's own bytecode creation which is at fault - but it may also be whatever is embedding the font in the PDF | 12:50.59 |
| JediMaster | and thanks for teh quick replies too (not something you expect in a lot of IRC channels) | 12:51.06 |
| chrisl | To be more specific about the error it would take me some hours to track it down - and I can't really be bothered! | 12:51.39 |
| JediMaster | chrisl: well it was doing it before I opened it up in fontforge, and it's TCPDF PHP library that's embedding it, so that's possibly at fault, but it uses various scripts like ttf2ufm to convert them | 12:52.12 |
| kens | I suspect that the original font has the problem, probably because it too was created by FontForge, and FontForge is creating broken bytecode, btu that is totally a guess | 12:52.55 |
| chrisl | JediMaster: Hmm, well, it's probably not worth the effort of tracking down the actual culprit. For future reference, though, any kind of font "technology" conversion is a really bad idea. | 12:53.50 |
| rsc | Uhm...Ghostscript 8.70 vs. 9.05. Older creates PDFs with Font: DejaVuLGSSans, Type: TrueType, Coding: Identity-H while second has a font "DejaVuLGCSans-Bold-Identity-H, Type: Type 1, Coding: Custom | 12:55.27 |
| | the configuration is actually the same for both versions. Ideas? | 12:59.12 |
| | so it doesn't do TrueType, but uses a Type1 font | 12:59.12 |
| chrisl | rsc: so what's actually wrong with the PDF from 9.05? | 13:02.22 |
| rsc | chrisl: it uses a Type1 font instead of the TrueType | 13:03.12 |
| chrisl | Type 1 fonts are allowed in PDF | 13:03.28 |
| rsc | yes. But I use the font name "DejaVuLGCSans-Bold-Identity-H", 8.7 does splitting to Font: DejaVuLGSSans, Type: TrueType, Coding: Identity-H (correct) | 13:03.57 |
| | but the 9.0 does font "DejaVuLGCSans-Bold-Identity-H, Type: Type 1, Coding: Custom | 13:04.06 |
| | and thus it just puts in monospace characters instead of the DejaVu font | 13:04.18 |
| | it feels like a bit it doesn't find the font anymore | 13:04.28 |
| chrisl | If it doesn't find the font, you'll get a warning about not finding the font | 13:05.29 |
| rsc | /DejaVuLGCSans « /FileType /TrueType /Path (/usr/share/fonts/dejavu/DejaVuLGCSans.ttf) /SubFontID 0 /CSI [(Unicode) 0] >> ; | 13:05.35 |
| kens | That's your cidfmap ? | 13:05.52 |
| rsc | yes. | 13:05.54 |
| | actutally « | 13:06.03 |
| | gna. so < < ;) | 13:06.08 |
| chrisl | rsc: are you using our release code (rather than a distribution package)? | 13:07.08 |
| rsc | chrisl: Fedora, but should be nearly unpatched | 13:07.58 |
| chrisl | rsc: Fedora patches probably more than any other distribution.... but it shouldn't affect this. Are you using -dSAFE or -dSAFER? | 13:08.40 |
| rsc | chrisl: good question, let me see | 13:09.22 |
| | chrisl: yes. | 13:11.51 |
| chrisl | rsc: try without either of them | 13:11.59 |
| rsc | chrisl: then it doesn't find the font, I think | 13:12.17 |
| | chrisl: can I somehow check, if it does find the font, like on a ghostscript prompt or so? | 13:13.18 |
| chrisl | rsc: if it doesn't find the font, you'll get a warning to that effect | 13:13.42 |
| rsc | so can I see the resolve from DejaVuLGCSans-Bold-Identity-H with what it looks up etc? | 13:13.43 |
| | chrisl: actually a script triggers that within a daemon :( | 13:13.52 |
| | so can I somehow run that myself by cause a font lookup? | 13:14.09 |
| chrisl | rsc: what happens if you run gs manually | 13:14.17 |
| rsc | using which arguments? | 13:15.00 |
| chrisl | rsc: the same ones the script uses | 13:15.11 |
| rsc | I don't have that *.ps here, let me see. But can't I simply do a load/lookup of the font? | 13:16.05 |
| chrisl | You can, hang on..... | 13:16.35 |
| | rsc: start gs, get the gs prompt, and do: /DejaVuLGCSans-Bold-Identity-H findfont | 13:17.48 |
| rsc | gs wants to start X... | 13:18.53 |
| chrisl | rsc: gs -dNODISPLAY | 13:19.14 |
| rsc | Can't find (or can't open) font file /usr/share/ghostscript/9.05/Resource/Font/DejaVuLGCSans-Bold-Identity-H. | 13:20.15 |
| | Loading NimbusSanL-Bold font from /usr/share/fonts/default/Type1/n019004l.pfb... 2610000 1271404 2112396 821249 1 done. | 13:20.30 |
| chrisl | So, it doesn't find the font, and falls back to the default. Are you sure gs is finding your modified cidfmap? | 13:21.09 |
| rsc | how do I figure out this best? | 13:22.24 |
| JediMaster | thanks again chrisl & kens | 13:22.32 |
| rsc | I'm setting GS_LIB="$GS_LIB:/etc/ghostscript/foo" where /etc/ghostscript/foo/cidfmap contains the cidfmap from above | 13:22.59 |
| chrisl | rsc: try setting the patch on the GS command line: gs -dNODISPLAY -I/etc/ghostscript/foo | 13:24.02 |
| | s/patch/path | 13:24.11 |
| rsc | chrisl: ouch...doesn't honor it? | 13:29.42 |
| | simply the same... | 13:29.51 |
| | it's just looking in /usr/share/ghostscript/9.05/Resource/Font/ for the font file as it seems | 13:35.02 |
| | but not in /usr/share/fonts/dejavu, even it scans it before?! | 13:35.20 |
| | http://fpaste.org/7gUS/ | 13:36.03 |
| chrisl | Hang on, you're trying to use "DejaVuLGCSans-Bold-Identity-H" but your cidfmap entry is for "DejaVuLGCSans" | 13:36.32 |
| rsc | yes, but that worked on 8.70 fine | 13:37.42 |
| | because the *.afm mentions DejaVuLGCSans-Bold-Identity-H | 13:37.51 |
| chrisl | As far as I'm aware, substitution only works on matching names | 13:38.56 |
| rsc | "FontName DejaVuLGCSans-Bold-Identity-H" in the *.afm. And all of that definately worked in 8.70 | 13:39.53 |
| | means I need some additional entries in my cifmap? | 13:42.06 |
| | but putting "DejaVuLGCSans-Bold-Identity-H" into the cidfmap doesn't work eitehr. | 13:43.03 |
| | *either | 13:43.08 |
| chrisl | rsc: no, but putting DejaVuLGCSans-Bold in it will work | 13:43.27 |
| | rsc: Identity-H is the name of the CMap to be used with the fake CIDFont made out of the truetype font | 13:43.57 |
| rsc | chrisl: but the Identity-H stuff is automagically appened by the software that calls it. And it already worked... | 13:44.35 |
| | could it be the broken freetype stuff? | 13:45.06 |
| | https://bugs.gentoo.org/show_bug.cgi?id=408513 | 13:45.10 |
| chrisl | rsc: I'm looking in the gs documentation, and it makes no mention (that I can see) of interrogating afm files to find substitute fonts | 13:46.05 |
| kens | AFM = Adobe Font Metric files nad are mostly useless to PostScript interpreters | 13:46.52 |
| | We certainly don't use them | 13:47.08 |
| rsc | yes, bt the fscking application server uses them | 13:47.16 |
| | the application server does some calculation based on the *.afm files. | 13:47.31 |
| kens | Yes, that I would expect | 13:47.41 |
| | But the font name in he PostScript must be the same as the font name you define in cidfmap | 13:48.17 |
| | So if the application generates PostScript asking for DejaVuSans-Bold, then you need to have a cidfmap for DejaVuSans-Bold, not DejaVuSans | 13:49.09 |
| | chrisl do we have a sample file (and ideally, font) from rsc ? | 13:53.48 |
| chrisl | No | 13:53.56 |
| kens | Oh, well can't really look at the problem then | 13:54.04 |
| chrisl | He said he does't have the PS file to try himself...... | 13:54.31 |
| rsc | kens, chrisl: http://fpaste.org/Lazv/ that's my complete configuration | 13:54.31 |
| | I'll try to grab a *.ps out of it. | 13:54.42 |
| kens | That woudl be good | 13:54.49 |
| | I can use a random TTF as a substitute for the font, though it would be good if we culd have that too | 13:55.17 |
| chrisl | I've got the dejavu fonts here, but the names don't seem to match between Ubuntu and Fedora.... | 13:56.15 |
| kens | Exellent, who needs consistency :-) | 13:56.28 |
| rsc | there's DejaVu and DejaVuLGC ;) | 13:56.46 |
| kens | I hesitate to ask, but what's LGC ? | 13:57.15 |
| rsc | The derivative called DejaVu LGC covers only Latin, Greek and Cyrillic | 13:57.46 |
| kens | OK, I gues that makes sense.... | 13:57.58 |
| chrisl | Well, substitution works as expected for me, just doing a /DejaVuLGCSans-Bold-Identity-H findfont at the gs prompt | 13:59.04 |
| rsc | chrisl: why does it for you - but not for me? | 13:59.34 |
| kens | Ah, I think you may have to put the cidfmap in a sub-directory called 'Resource' or possibly 'Resource/Init' | 13:59.35 |
| rsc | oh? | 13:59.41 |
| | but that's new then, right? | 13:59.48 |
| kens | DPerhaps, resource handling has changed several times. | 14:00.01 |
| | I'm not saying that for definite you understand | 14:00.12 |
| | Just a guess | 14:00.16 |
| | But I htink the cidfmap follows the Resource stuff, and so it looks in the search path for a folder called 'Resource' | 14:00.45 |
| chrisl | No, I'm using a different directory for it - having been caught that way for something else in the past | 14:00.52 |
| kens | Oh well, thre you go then | 14:01.01 |
| Robin_Watts | tor8: Just had a quick look at your patches. | 14:01.26 |
| | They all look fine. Minor points: Last one has an extra tab in it. | 14:01.50 |
| rsc | kens: so /etc/ghostscript/foo/Resource/cidfmap? | 14:01.58 |
| kens | rsc chrisl says that is not required, so I'm wrong | 14:02.10 |
| Robin_Watts | For some of the others, where we're adding 'special case heuristics', it would be nice if the details of those heuristics were actually in the code in comments, rather than us having to first lookup the commit message from the code, then having to look at the google code link etc. | 14:02.43 |
| rsc | chrisl: but the substitution works for you as expected, I thought? | 14:02.49 |
| chrisl | rsc: yep, works just fine | 14:03.01 |
| rsc | chrisl: by using the same configuration like me? | 14:03.25 |
| chrisl | rsc: as close as I can get running on Ubuntu | 14:03.39 |
| kens | Can you try running PostScript to list the CIDFont resoruces ? | 14:04.17 |
| | To see if the cidfmap is having any effect. | 14:04.32 |
| chrisl | Mind, I do get another error with the standard Ubuntu install - missing Identity-UTF16-H CMap | 14:05.24 |
| rsc | kens: how? | 14:05.31 |
| kens | rsc one minute | 14:05.38 |
| | (*) {==} 256 string /CIDFont resourceforall | 14:06.14 |
| | Let me just test that | 14:06.22 |
| | Ys that works | 14:06.49 |
| | FOr me it giv es 2 CIDFOnts, CIDFallBack and ArtifexBullet | 14:07.07 |
| | But it will be different on earlier versions | 14:07.21 |
| chrisl | And I get the extra one (DejaVuLGCSans-Bold) from my cidfmap | 14:07.29 |
| rsc | http://fpaste.org/0ssc/ | 14:08.07 |
| chrisl | So, all your expected fonts are listed | 14:08.40 |
| kens | So lets try a composefont | 14:08.59 |
| | Grr silly irc | 14:10.12 |
| | "/DejaVuSans-Identity-H /Identity-H [/DejaVuSans] composefont" | 14:10.41 |
| | Try that without the "" | 14:10.48 |
| | I'll just try it here too | 14:10.54 |
| | OK that leaves a dict on the stack | 14:11.36 |
| rsc | Error: /undefinedresource in findresource | 14:11.51 |
| kens | Ah | 14:11.56 |
| | MY guess is it can't find Identity-H | 14:12.07 |
| rsc | possible? | 14:12.52 |
| kens | Lets try this: | 14:12.57 |
| | "/Identity-H /CMap findresource" | 14:12.57 |
| | wihtout the "" again | 14:13.05 |
| rsc | Error: /undefinedresource in findresource | 14:13.25 |
| kens | Well it sounds like your GS can't find any CMaps, which is going to be fatal | 14:13.48 |
| rsc | http://fpaste.org/6chW/ | 14:13.51 |
| chrisl | rsc: do you know where on your filesystem the GS resources are stored? | 14:14.12 |
| rsc | chrisl: /usr/share/ghostscript/9.05/Resource/ from how I understand? | 14:14.48 |
| chrisl | rsc: ok, in there should be either a directly or a symlink called CMap | 14:15.21 |
| kens | Might be nice to know what *is* in there | 14:15.36 |
| chrisl | I'm wondering if Fedora have also tried to merge the GS and poppler CMaps, like Gentoo did | 14:16.05 |
| kens | That's possible | 14:16.15 |
| | Did they get that to work ? | 14:16.27 |
| rsc | chrisl: there is /usr/share/ghostscript/9.05/Resource/CMap/, an empty directory. | 14:16.47 |
| chrisl | I've no idea - it would have meant creating a symlink for *every* cmap file..... | 14:17.01 |
| kens | Well, that's why you get no CMaps, nad can't create composed CIDFonts then | 14:17.07 |
| chrisl | rsc: well, there you go..... | 14:17.14 |
| rsc | oh. But it's filled on 8.7x. | 14:17.19 |
| | aha! | 14:17.21 |
| | chrisl: so Fedora failure, yes? | 14:17.28 |
| kens | would not go so far as to say that | 14:17.40 |
| | But it *is* a problem | 14:17.46 |
| | If you want to use CIDFonts | 14:17.53 |
| chrisl | rsc: Possibly - CMaps are often in a separate package, called something like "gs-cjk-resource", for example..... | 14:18.14 |
| ray_laptop | one thing that changed (I think in 9.05) was defaulting to -P- (don't search . ) Maybe Fedora didn't take that change ? gs -h is your friend to see what the paths are | 14:20.50 |
| | morning, all | 14:21.27 |
| chrisl | ray_laptop: good morning! | 14:21.43 |
| kens | HI ray_laptop | 14:21.53 |
| rsc | ray_laptop: http://fpaste.org/5zSm/ that? | 14:22.07 |
| chrisl | the -P- thing shouldn't make a difference to substitutions in cidfmap, though..... | 14:22.14 |
| | Uh-oh - /usr/share/poppler/cMap/Adobe-CNS1 | 14:23.22 |
| rsc | chrisl: but there is no Identity-H in | 14:24.12 |
| chrisl | rsc: look in /usr/share/poppler/cMap | 14:24.27 |
| rsc | find /usr/share/poppler/cMap/ -name "*Identity*" returns nothing | 14:24.57 |
| chrisl | Hmm, for me /usr/share/poppler/cMap/Identity-H and /usr/share/poppler/cMap/Identity-V both exist | 14:25.40 |
| rsc | I'm currently looking if it's maybe another package | 14:26.00 |
| | no Fedora package at all provides "Identity-H" | 14:26.16 |
| kens | Well you can get our sourecs, they contain the CMaps ;-) | 14:26.37 |
| chrisl | rsc: Maybe poppler has started to build in the Identity cmaps, anyway that's (one of) your problem(s). And you'll have to take it up with the Fedora packagers | 14:27.52 |
| kens | is pleased to see that recent regression runs seem to have many fewer indeterminisms. And none in pdfwrite/ps2write :-) | 14:28.29 |
| rsc | chrisl: yes. But I could ship Identity-H myself. Any special directory? | 14:29.27 |
| kens | The Resoufce/CMap directory :-) | 14:29.49 |
| | Resource* | 14:29.58 |
| rsc | kens: so /etc/ghostscript/foo/Resource/CMap/Identity-H? | 14:30.01 |
| kens | rsc assuming that's where your resoruces are stored, yes | 14:30.16 |
| | You can try it yourself | 14:30.22 |
| | With the PS code from earlier | 14:30.34 |
| chrisl | I'm really not happy with this munging of our CMaps with the poppler ones - with the size of hard disks these days, it's already cost us more time than it's worth to save 6.3Mb!!! | 14:32.15 |
| ray_laptop | I assume that the distros don't use COMPILE_INITS=1 ? | 14:33.40 |
| chrisl | ray_laptop: none that I know of use COMPILE_INITS, no | 14:35.57 |
| ray_laptop | what a bummer. Maybe we should just always build in the %rom%Resource stuff and not tell them ;-) | 14:36.49 |
| chrisl | ray_laptop: it had crossed my mind, but they'd just hack it out again - at least now we know *how* they avoid using it...... | 14:38.13 |
| ray_laptop | well, we could make enough places in the PS code depend on their being a %rom file system that it would make it harder to hack than C code ;-) | 14:39.11 |
| | just irritated that we end up fixing problems that the distros cause in the first place with their misjudged priorities (not likely that the Fedora folks would have bothered to figure out what was broken -- they would have just said, well if poppler works, gs must be buggy, so we won't use it) | 14:41.32 |
| rsc | chrisl: https://bugzilla.redhat.com/show_bug.cgi?id=842351 - done | 14:41.34 |
| | chrisl, kens: Thank you *very* much for all your time and efforts and help. It's highly appreciated! | 14:41.53 |
| ray_laptop | rsc: thanks for griping to them | 14:42.27 |
| chrisl | rsc: there are actually (I think) three more CMap files missing - first of all Identity-V | 14:42.33 |
| ray_laptop | chrisl: we could open a bug for each missing file and keep them busy adding them one by one ;-) | 14:43.08 |
| rsc | ray_laptop: sounds like a deal :D | 14:43.22 |
| chrisl | ray_laptop: I would be perfectly happy with that ;-) | 14:43.27 |
| | rsc: you're probably also missing: Identity-UTF16-H and UniHojo-UCS2-H (which are non-standard CMaps used as part of our CIDFont substitution code). | 14:44.13 |
| ray_laptop | chrisl: do they even provide DroidSansFallback ? | 14:46.33 |
| ray_laptop | isn't sure of the caps on a linux system | 14:47.06 |
| chrisl | ray_laptop: No idea, I suspect it's on the system, just whether GS can find it, I don't know. *But* those two custom CMaps are used for cidfmap substitutions as well as the DroidSansFallback case, so whether DroidSans is there or not, those CMaps are needed. | 14:48.08 |
| Robin_Watts | mvrhel_laptop: Aha. | 14:50.32 |
| mvrhel_laptop | hi Robin_Watts | 14:51.11 |
| Robin_Watts | mvrhel_laptop: Sorry to swoop on you, but I've been digging through a regression that was caused by the planar colors stuff, and I think I've got to the point I need to discuss it. | 14:51.22 |
| mvrhel_laptop | ah ok | 14:51.37 |
| Robin_Watts | mvrhel_laptop: Is now a good time? | 14:51.45 |
| mvrhel_laptop | Robin_Watts: I have about 10 minutes, then I have to get the kids off to swim lessons which start this morning | 14:52.17 |
| Robin_Watts | Probably better when you get back then ? | 14:52.36 |
| mvrhel_laptop | uh oh must be a fun one | 14:52.47 |
| Robin_Watts | I'd love to think this can be solved in 10 mins, but I fear it's unlikely :) | 14:52.49 |
| | It's to do with pattern fills in hl colors. | 14:53.08 |
| mvrhel_laptop | ok. Lets shoot for later then. | 14:53.15 |
| Robin_Watts | Yell when it's a good time. | 14:53.22 |
| mvrhel_laptop | ok | 14:53.26 |
| rsc | chrisl: hm. Just putting a copy of the file to /etc/ghostscript/foo/Identity-H doesn't seem to solve it. | 14:54.21 |
| chrisl | rsc: you probably need to tell gs to search there | 14:55.50 |
| rsc | chrisl: I thought, I would do that with -I/etc/ghostscript/foo | 14:56.28 |
| chrisl | rsc: when you say "solve it" are you using checking it "manually" just not, not using the script? | 14:57.32 |
| | s/not/now | 14:57.38 |
| rsc | chrisl: manually. | 14:58.26 |
| chrisl | rsc: Okay, try making it /etc/ghostscript/foo/CMap/Identity-H | 14:59.03 |
| rsc | ah! I tried Resource and Resource/CMap, not CMap only. | 14:59.53 |
| chrisl | Well, either should work, I'd think. | 15:00.33 |
| ray_laptop | rsc, chrisl: CMaps are Resources so are searched for in the GenericResourceDir/CMap directory ONLY | 15:01.16 |
| | we don't search all the LIBPATH path for Resource files | 15:01.48 |
| chrisl | ray_laptop: then Fedora's configuration to share the CMaps with poppler won't work at all? | 15:02.07 |
| ray_laptop | it will if the set the GenericResourceDir | 15:02.28 |
| | s/the/they/ | 15:02.41 |
| rsc | chrisl: CMap works, thanks :) | 15:03.00 |
| chrisl | ray_laptop: they several paths to the search path for the CMap "subsets" (chinese, japanese etc) | 15:03.49 |
| | s/they/they add | 15:03.56 |
| ray_laptop | at one point we were going to allow multiple paths for GenericResourceDir (like with ':' separators) but that got too hideous, iirc | 15:03.58 |
| chrisl | rsc: good - phew! | 15:04.04 |
| ray_laptop | alexcher has been taking care of the Resource paths and finding resources, so I may be out of date | 15:04.57 |
| chrisl | ray_laptop: if you look at the output that rsc posted http://fpaste.org/5zSm/ - if you're right, that won't work? | 15:05.15 |
| ray_laptop | easy enough to try: /Adobe-Japan1-4 /CMap findresource | 15:06.33 |
| | chrisl: didn't work for me. I have a Resource/CMap directory with /UCS2-90ms-RKSJ in it, and I put that on my LIBPATH with -I (and verified it was there). Then /UCS2-90ms-RKSJ /CMap findresource gave me undefined Resource | 15:13.24 |
| chrisl | ray_laptop: I didn't think it would work. Like I said, this sharing CMaps with poppler is a recipe for disaster :-( | 15:14.13 |
| kens | I'm inclined to agree | 15:14.23 |
| ray_laptop | chrisl: so unless Fedora also hacked the PS resource machinery (a daunting task) it shouldn't work for rsc either | 15:14.51 |
| | general Resource files aren't easy to share -- fonts are a different matter since we use "extended" rules to search for fonts (that are documented) | 15:16.10 |
| | yet another reason to switch to compiled in fonts (maybe like mupdf) that are harder for them to rip out | 15:17.12 |
| henrys | wow alexcher now has 5 bugs on the aging list ? | 15:17.14 |
| chrisl | ray_laptop: actually, that's strange because I think there is *horrid* code in the initialisation which resets GenericResourceDir if your -I has the string "Resource" in it | 15:17.23 |
| ray_laptop | sorry: yet another reason to switch to compiled in CMaps (maybe like mupdf) that are harder for them to rip out | 15:17.27 |
| henrys | certainly the MAX_COMPONENTS should go to mvrhel_laptop | 15:17.48 |
| Robin_Watts | I thought that was with me... which one ? | 15:18.15 |
| henrys | 693207 | 15:18.27 |
| ray_laptop | chrisl: yes, there is, but I defeated that by having -I%rom%Resource -I/My/Resource/CMap on the command line, so LIBPATH { = } forall showed it second and the GenericResourceDir got set in the usual place %romesource/ | 15:19.00 |
| | that is %rom%Resource/ | 15:19.11 |
| chrisl | ray_laptop: ah, okay. Anyway, I think we're agreed, trying to save a paltry few megabytes in this fashion is just crap of the highest order! | 15:20.08 |
| henrys | this is the first time I noticed "blockers" in the aging list. thanks marcosw1 | 15:20.13 |
| ray_laptop | henrys: it's all a question of testing to make sure that whatever we set it to doesn't blow things up (like > 64 might) and that it doesn't slow us down like it used to | 15:20.14 |
| | chrisl: yes, I heartily agree | 15:20.32 |
| henrys | ray_laptop:okay then give it marcosw to do a full comparison isn't that the usual procedure? | 15:21.20 |
| | I can do it if you want. | 15:21.37 |
| chrisl | ray_laptop: I guess we'll have to take a harder line when users query us about it - which is a shame: I hate penalising users for maintainer's idiocy :-( | 15:21.50 |
| Robin_Watts | ray_laptop, henrys There is a bug open for the problems we see when we go to 32 or 64 max components. | 15:21.53 |
| | I've been looking at it. | 15:22.00 |
| | I've solved the SEGVs at 32, but there are still some diffs. | 15:22.13 |
| | There are more diffs when we push it to 64. | 15:22.31 |
| chrisl | Robin_Watts: are the diffs all in PS files? | 15:23.07 |
| Robin_Watts | at 64, no. | 15:23.37 |
| ray_laptop | henrys: I finally found (I hope) the last of the miscalculations in the multi-threaded rendering for psdcmyk and closed my blocker (bug 692542) | 15:24.19 |
| chrisl | Robin_Watts: Shame. They way mvrhel had to handle PS means it will influence band boundaries in clist mode..... | 15:24.26 |
| henrys | ray_laptop:great news. | 15:24.43 |
| Robin_Watts | My current bmpcmp is of the 64 differences, I believe. | 15:24.57 |
| henrys | Robin_Watts:so it seems you should absorb 693207 as well right? | 15:25.41 |
| Robin_Watts | That should probably depend on whatever bug it was I was looking at. | 15:26.06 |
| | which I think may technically belong to michael. | 15:26.22 |
| chrisl | Robin_Watts: hmm, yes, there are some oddities in there, outside what I would expect :-( | 15:27.15 |
| henrys | okay michael I just want to avoid alexcher jumping on this when he has other bugs in his domain | 15:27.22 |
| tor8 | Robin_Watts: extra tab where? | 15:27.59 |
| Robin_Watts | Actually... it's 693185, and it's assigned to alex. | 15:28.19 |
| | So I could take both 693185 and 693207 | 15:28.32 |
| henrys | yes or assign them to michael and continue working on them. | 15:29.03 |
| Robin_Watts | I'll assign them to michael then :) | 15:29.16 |
| ray_laptop | 693207 could be handled by marcos (IMHO) since it is mostly testing | 15:29.38 |
| | I don't think anyone has a need (at this time) for > 64, so changing it to 64 and testing is easy | 15:30.10 |
| | even I could do it ;-) | 15:30.20 |
| | and I don't want to distract mvrhel | 15:30.29 |
| henrys | ray_laptop:I got the impression there was no point in testing until Robin_Watts fixed something so ta marcosw1 assignment would be confusing. | 15:30.34 |
| Robin_Watts | ray_laptop: I've tested, and there are problems. | 15:30.51 |
| | I need to track down what's causing the problems. | 15:30.58 |
| | It may need to go back to michael (if I run out of my depth), but I can't at least triage it for him. | 15:31.14 |
| | s/can't/can/ | 15:31.26 |
| ray_laptop | Robin_Watts: sorry I thought you were past those -- I know you resolved several (or several dozen) | 15:31.32 |
| Robin_Watts | I resolved all the SEGVs. | 15:31.40 |
| | but there are a few diffs left. | 15:31.47 |
| ray_laptop | Robin_Watts: thanks. Sorry for the confusion. | 15:33.54 |
| | oh, great -- now we are getting suggestions to improve our error messages from a "triager" at debian | 15:34.58 |
| kens | ray_laptop : yeah, but it does make 'some' sense | 15:36.01 |
| | Of course the users won't read the extra info.... | 15:36.12 |
| ray_laptop | if it makes sense, why doesn't the OS produce a warning/alert that the disk filled ? | 15:37.00 |
| kens | It might do, but it makes some szense for other errors too | 15:37.22 |
| ray_laptop | then if a program fails, you have a clue | 15:37.24 |
| henrys | alexcher:693115 looks to be forgotten. | 15:37.43 |
| kens | And our Windows (and MSDOS!) code already does it.... | 15:37.49 |
| ray_laptop | I wonder if bastien is french -- the bug reports sort of suggest that | 15:38.34 |
| kens | Well its French name | 15:38.58 |
| ray_laptop | kens: our windows code says "disk full" ? Obviously I've avoided that one by upgrading disks often enough | 15:39.24 |
| kens | No, but it uses strerror, which the Unic code doesn't | 15:39.39 |
| | That propagates through .oserrorstring to pritn extra information on OS errors | 15:39.56 |
| | Only the Windows and MSDOS code (afaict) do this. | 15:40.27 |
| | Or that was hte case before chrisl's change | 15:40.44 |
| | brb | 15:40.59 |
| chrisl | It seemed silly to have the code there, and not use it when we can...... | 15:41.14 |
| kens | Yeah, I'm inclined to agree, which si why I mentioned it in the thread | 15:45.26 |
| chrisl | And we were already reporting the OS error, we just weren't "decoding" it. | 15:46.23 |
| alexcher | henrys: No, I'm working on the bug 693115. | 15:46.38 |
| ray_laptop | chrisl: kens: (not sure who commented) multi-threaded rendering won't cause a disk full error in a thread since the 'main' thread writes the output file and the threads only read. This will be true until we allow multiple main instances each in a thread | 15:48.03 |
| kens | ray_laptop : it was me, nad I *thought* that was hte case, but, not being the expert.... | 15:48.24 |
| chrisl | ray_laptop: if it ever becomes an issue, we can add support for the thread safe variant of strerror - it won't be a big deal | 15:50.25 |
| Robin_Watts | ray_laptop: Unless the threads render by calling a device that writes to disk maybe? | 15:52.05 |
| ray_laptop | Robin_Watts: threads render to 'buf devices' that are supposed to write the pixels to a memory buffer, but I suppose if a funky buf device were used ... | 15:54.00 |
| | Robin_Watts: note that the funky buf device that I did for cust 532 doesn't write to disk, but also doesn't actually render any data to the memory buffer | 15:54.48 |
| chrisl | To be honest, I don't really see it being an issue - if several threads hit a several terminal conditions near simultaneously, the worst we'll get is writing out a partial error message. | 15:55.36 |
| ray_laptop | chrisl: right -- or interleaved messages | 15:56.35 |
| kens | I'm inclined to say to Bastien that bug files need to be attached to *our* bug tracker, and not referenced in other bug trackers | 15:57.58 |
| | We've had problems with that in the past where the fiels disappear | 15:58.08 |
| | That file was also not entirely produced by GS 5. | 15:59.06 |
| | It has a bunch of 'PTEX@ stuff in it which can only have got there byb pdfmarks or later edirting | 15:59.24 |
| ray_laptop | kens: well, if the file disappears from their bug tracker we can automatically close our bug ;-) | 15:59.35 |
| chrisl | kens: I didn't look that closely at the internals of the file - with so many other consumers showing identical resolution based differences, I didn't care enough. | 16:00.30 |
| kens | In fact the Producer is pdfTeX-1.10b | 16:00.33 |
| | chrisl agreed, I was curious abouit why that's all | 16:00.46 |
| | the /Creator is TeX too | 16:01.02 |
| | Oh, nice a 5 page file to demonstrate the problem too.... | 16:01.39 |
| chrisl | Good grief, there's 4 (I think) producers - I guess each page was created as an individual file, and then they were munged together | 16:02.26 |
| kens | Looks lthat way :-( | 16:02.47 |
| | It 'looks' like the frame is not linework, it looks like its a stretched image | 16:03.21 |
| | Oh no, mayb enot | 16:03.35 |
| Robin_Watts | chrisl: Urm... isn't strerror one of those functions that returns a pointer to a string? And that pointer is guaranteed to be valid until the next call to strerror ? | 16:04.48 |
| | In which case if 2 threads call it and then read the results out you can get a race condition SEGV. | 16:05.23 |
| chrisl | Robin_Watts: AIUI, all (common) implementations use a static buffer, the *contents" of which are guaranteed to remain until the next call - but the address should be the same. | 16:06.18 |
| Robin_Watts | Right, but that's not the word of the spec. | 16:06.32 |
| chrisl | Robin_Watts: Actually, it doesn't matter at all from a device perspective....... | 16:08.00 |
| kens | chrisl well I don't really see what's causing the problem, but it does draw the rectangle in a form, and the form seems to be overly complicated, draws multiple elements | 16:08.07 |
| ray_laptop | even if the buffer is in the same place, if the second string writes the terminating NULL BEFORE where the second (suspended) thread is reading, and happens to write something over the NULL in the string, then when the suspended thread resumes ... | 16:08.21 |
| | but that is really grasping at straws | 16:08.49 |
| chrisl | ray_laptop: if one rendering thread errors, presumably we clean up the other threads before returning to the interpreter? | 16:09.43 |
| ray_laptop | chrisl: we use the clist_teardown_render_threads which waits for other threads to complete | 16:11.56 |
| chrisl | Robin_Watts: the strerror call is initiated at the interpreter level, and currently we've no way to run multiple interpreter threads...... | 16:12.18 |
| | ray_laptop: thanks, that's what I thought. | 16:12.30 |
| ray_laptop | chrisl: so, right, if the strerror doesn't happen in the thread, we are OK | 16:12.30 |
| | I mean if the reading of the string returned by strerror doesn't happen in the thread. But in our case, a a thread would just be setting errno -- the interp does the strerror and reads it to print it out | 16:13.49 |
| chrisl | Yes, exactly. | 16:14.38 |
| | Like I said, it won't be rocket science to switch to using the thread safe variant when required. | 16:19.49 |
| kens | chrisl it looks to me like the problem is teh fact that the 'frame' is clipped to the boundingbox of the Form. The BBox is an integer, the path describing the rectangle is not, Depending on the resolution and rounding, the bottom edge of the stroke either just fits into the clip, or just doesn't quite. | 16:26.50 |
| | If I increase the BBox by 1 then the problem goes away. So yes, its a badly constructed PDF file | 16:27.16 |
| | And I see thre's someone else now using a linewidth of 1 and wondering why it sometiems disappears depending on the resolution :-) | 16:28.19 |
| | OK off ofr the night now, bye all | 16:29.10 |
| kens | hopes Bugzilla and IRC will be quieter tomorrow.... | 16:29.32 |
| chrisl | Aw, what is this - "Weird Sh*t Monday", or something? Bug 693212 that just came in...... | 16:36.40 |
| apineda | Does gs turn off icc completely when using tiffsep device? I need the cmyk colors cm processed but not the spots. | 16:37.24 |
| henrys | I wonder if we shouldn't have a backlog@artifex.com assignee on bugzilla. | 16:40.52 |
| Robin_Watts | whatever@artifex.com | 16:42.22 |
| chrisl | blackhole@artifex.com | 16:42.40 |
| henrys | Actually it is a concern that the regular interruptions are effecting important project schedules. | 16:43.52 |
| chrisl | apineda: according to the documentation, that is how it will work: the CMYK plates will be managed, and the "spot" plates won't - but for a totally definitive answer, you need to wait for mvrhel to reply when he's about. | 16:45.48 |
| ray_laptop | without an ICC profile for spot colors, we have to trust the tint transform when munging the spot color to form the composite CMYK image (not the individual separations that are "gray" planes). but AIUI the rules for CM conversion (or not) get applied depending on the colorspace of the tint transform | 17:08.43 |
| | so I think if the /Alternate tint transform is RGB, then RGB to CMYK color management will be applied, but not if the tint transform is in DeviceCMYK colorspace | 17:09.46 |
| | but I will look forward to mvrhel making sure this is the approach we take | 17:10.17 |
| chrisl | Ah, yes, I should have qualified that I was talking about what tiffsep writes to the spot plates - given that we can't realistically write "un-processed" spot colors to the CMYK preview...... | 17:12.04 |
| Robin_Watts | wonders if mvrhel is back yet. | 17:43.46 |
| | Hi mvrhel_laptop | 17:49.18 |
| | mvrhel_laptop: (For the logs if you're not here). I think I've found the problem with bug 693204. | 17:51.38 |
| mvrhel | Robin_Watts I am back | 17:53.00 |
| Robin_Watts | We're plotting text filled with a pattern. It tries to do it one way, and fails because it can't serialise a masked device n color. (The old code that worked with pure device n colors failed there in exactly the same way). | 17:53.13 |
| | So, we try to use an imagemask. We end up in copy_portrait. | 17:53.36 |
| | The old code called gx_dc_default_fill_masked, which did a lot of work and ended up calling gx_device_color_fill_rectangle. | 17:54.45 |
| | The new code calls gx_dc_devn_fill_masked, which does identical work, but ends up calling the device proc for high level color rectangle filling. | 17:55.21 |
| mvrhel | ok | 17:55.33 |
| Robin_Watts | The problem is that the clist_fill_rectangle_hl_color tries to serialise the masked color, and that fails again. | 17:55.54 |
| mvrhel | hmm it should serialize the devn color | 17:56.20 |
| | and why would that fail? | 17:56.30 |
| | oh its a pattern? | 17:56.34 |
| Robin_Watts | Yes. | 17:56.40 |
| | I think that gc_dc_devn_fill_masked should call the device color proc to fill rectangle. | 17:56.47 |
| | exactly the same as the old code did. | 17:56.55 |
| mvrhel | yes | 17:56.58 |
| Robin_Watts | The device color proc ends up calling the hl color fill thing, but sidesteps the need to serialise the devn_masked color. | 17:57.24 |
| | My bmpcmp shows 66 changes, all progressions. | 17:57.36 |
| | Are you happy with that? | 17:57.45 |
| mvrhel | sounds great | 17:58.46 |
| Robin_Watts | ok, I'll get that committed. | 17:58.56 |
| mvrhel | good catch | 17:58.58 |
| | I should have seen that in the cluster push from the original commit | 17:59.18 |
| | Robin_Watts: So what is going on with 693185? | 18:01.35 |
| | and 693207? | 18:01.50 |
| Robin_Watts | 693207 is about a file that has too many spot colors. | 18:02.12 |
| | So the fix is to up max components, and we can't do that until we fix 692185. | 18:02.30 |
| | 693185 even. | 18:02.37 |
| | 693185: we no longer segv, but there are some differences there. | 18:02.51 |
| | My next(ish) job is to figure why we still get differences at 32. | 18:03.30 |
| mvrhel | ok. that was those odd vertical lines? | 18:03.44 |
| Robin_Watts | Then I'll look at 64. (More differences at 64 than at 32, so I suspect multiple issues). | 18:03.50 |
| | The reason I say next(ish) is that I have an outstanding patch that I haven't committed yet. | 18:04.10 |
| | The patch is the thing that calculates color usage for the clist. | 18:04.28 |
| | and that patch seems to be enough to cause the differences in vertical lines. | 18:04.40 |
| mvrhel | Is 693207 solved by bumping up the number to 17+ but less than 32? | 18:04.55 |
| Robin_Watts | but I want to retest it. | 18:05.01 |
| | Maybe. | 18:05.09 |
| mvrhel | or is there something more there | 18:05.13 |
| Robin_Watts | we could try 24 or something. | 18:05.17 |
| | but there are only a few differences at 32, so I'd like to try to get it fixed for the release. | 18:05.39 |
| mvrhel | sure | 18:05.49 |
| ray_laptop | darn. Had a question for kens. I get 1085/7241 single pixel differences out of pdfwrite with the fill_rectangle_hl_color changes, but I looked at a couple and when I compare the pdf output (pdfclean'ed -d) they are the same :-( | 18:05.57 |
| Robin_Watts | Alex reports that 20 was enough to give differences. | 18:06.23 |
| mvrhel | an issue that bothers me though | 18:06.32 |
| | is that the content should not be missing if we run over the amount | 18:06.45 |
| | at least in the composite view | 18:06.50 |
| | the separations will not be generated though | 18:06.59 |
| Robin_Watts | Right. You're trusting my dodgy bmpcmp code though, remember? :) | 18:07.18 |
| mvrhel | as we should be using the alternate tint transform and pushing the extra spots to CMYK | 18:07.19 |
| | I mean with bug 693185 | 18:07.39 |
| | oh hold on | 18:07.54 |
| | this is even going out to a ppmraw device | 18:08.09 |
| ray_laptop | mvrhel: the appearance might be different in the composite view maybe ? And with overprint ? | 18:08.12 |
| mvrhel | we should not have to fool with eht GS_CLIENT_MAX_COMPONENTS | 18:08.23 |
| ray_laptop | mvrhel: oh, ppmraw doesn't do overprint and always uses the tint transform. NM | 18:08.42 |
| mvrhel | the comments on 693185 dont match the original report | 18:08.53 |
| | the original report is about going out to ppmraw | 18:09.09 |
| Robin_Watts | Yes, that's very odd. | 18:09.21 |
| | marcosw, marcosw1: Ping? | 18:09.28 |
| mvrhel | The comments from Alex dont match the report | 18:09.37 |
| | did alexcher post to the wrong bug? | 18:10.21 |
| Robin_Watts | I don't know. | 18:10.41 |
| marcosw | Robin_Watts: morning | 18:11.20 |
| ray_laptop | there _was_ a file from a cust (393 ?) that had 17 spot colors | 18:11.42 |
| Robin_Watts | ray_laptop: That was more recent. | 18:11.56 |
| ray_laptop | and I have a test file from a guy that has 40 | 18:11.57 |
| Robin_Watts | marcosw: We are confused by bug 693185 | 18:12.06 |
| | The original bug report (from you) talks about ppmraw. | 18:12.26 |
| ray_laptop | Robin_Watts: more recent than Alex's Jul 17 comment (if he posted to the wrong bug ?) | 18:12.33 |
| Robin_Watts | ray_laptop: Yes. | 18:12.52 |
| | I think :) | 18:13.04 |
| | marcosw: And alex says he can cure it by bumping GS_CLIENT_COLOR_MAX_COMPONENTS, which shouldn't be an issue here, should it? | 18:13.29 |
| | ray_laptop: Did you have any comments on my color_usage patch ? | 18:13.58 |
| ray_laptop | Robin_Watts: sorry -- I haven't looked at it (I started to but got interrupted and it fell of the end of my stack) | 18:15.07 |
| | istr the patch was up on casper | 18:15.31 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/ghostpdl.git/.git;a=commitdiff;h=47cf40c87f20f12d8f35528adedb102d2d0dcef2 | 18:15.58 |
| | ray_laptop: No worries. I'm just reclusterpushing it now. | 18:16.14 |
| marcosw | The customer who reported 693185 always uses tiffsep as the output device. In this case I used ppmraw because the file also failed with that device and I use that as my default testing device. Perhaps alexcher tested with psdcmyk since he knows that customer 393 uses a planar device? | 18:16.17 |
| mvrhel | ok I ran it and sure enough lots of stuff missing | 18:16.31 |
| | when going out to ppmraw | 18:16.39 |
| Robin_Watts | Ok, so there are twin issues here? | 18:16.43 |
| mvrhel | perhaps | 18:17.03 |
| Robin_Watts | I'll keep looking at the problems with pushing components max higher. | 18:17.19 |
| mvrhel | ok. I am going to dig into this thing | 18:18.04 |
| marcosw | Speaking of bug GS_CLIENT_COLOR_MAX_COMPONENTS <http://bugs.ghostscript.com/show_bug.cgi?id=693207>, what is the downside of increasing that value to something large (i.e. 50)? Are the significant performance or memory issues? | 18:19.07 |
| ray_laptop | marcosw: if it fails with the ppmraw device, that can't be cured with more the MAX_CLIENT_COLOR_COMPONENTS (as far as we can imagine) | 18:19.09 |
| | marcosw: we are talking about evaluating performance impact of 64 | 18:19.50 |
| mvrhel | gawd GS_CLIENT_MAX_COMPONENTS does effect ppmraw | 18:20.01 |
| | hehe | 18:20.10 |
| | ok I will look into this | 18:20.14 |
| | some reason we are not doing the alternate tint transform | 18:20.29 |
| ray_laptop | there used to be significant performance issues due to the 'image_init_clues' allocation and initialization | 18:20.35 |
| marcosw | alexcher's comment #3 regarding changing GS_CLIENT_COLOR_MAX_COMPONENTS to 20 and seeing differences in output is ominous. | 18:21.07 |
| ray_laptop | mvrhel: that's a surprise | 18:21.13 |
| | marcosw: Robin_Watts has been improving some of that | 18:21.41 |
| | marcosw: and Robin_Watts has already fixed the SEGV's when setting it to 64 | 18:22.24 |
| Robin_Watts | 32. | 18:22.39 |
| | Not sure what the SEGV situation is like at 64. | 18:22.51 |
| ray_laptop | Robin_Watts: sorry again. I was recalling the discussions about 64, so I thought that's what you tested | 18:29.13 |
| | bastien is getting to be a pain. He just posted a duplicate to bug 689805. | 18:30.02 |
| | which I closed as such. but that wayback machine hoop I had to jump through to get the file was a pain, so I griped about it. | 18:30.41 |
| | rather than lettiing me 'save link as...' from the link in our bug report I had to open that link, wait for the wayback to machine to load the file (and mozilla to feed it to my PDF renderer) then save the page :-( | 18:32.21 |
| mvrhel | that looks like an interesting one | 18:33.01 |
| marcosw | ray_laptop: I remember when we didn't have browsers and we had to use gopher to download files over a 300 baud modem. So stop complaining about have to hit control-s rather than being able to right-click :-) | 18:35.15 |
| ray_laptop | marcosw: no it was the delay while wayback told me -- just wait a minute while we dig up your file. Ken commented the same thing to this guy. | 18:37.29 |
| | marcosw: it's about as | 18:37.56 |
| | marcosw: irritating | 18:38.02 |
| | marcosw: as | 18:38.07 |
| | marcosw: waiting for | 18:38.15 |
| | marcosw: me to finish my sentence | 18:38.26 |
| ray_laptop | can't believe I got that out without interruption ;-) | 18:39.06 |
| | bbiaw. Gonna try more of the pdfwrite differences to see what might be going on with the fill_rectangle_hl_color differences | 18:40.24 |
| Robin_Watts | Ah, right. | 18:50.54 |
| | My color_usage patch just completed with no diffs showing. | 18:51.07 |
| | So ray_laptop, I'll commit it as soon as you say you're happy. | 18:51.32 |
| | And tomorrow I'll go looking for the differences caused when the max components goes to 32. | 18:52.01 |
| ray_laptop | Robin_Watts: where is the patch, again ? | 18:53.09 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/ghostpdl.git/.git;a=commitdiff;h=47cf40c87f20f12d8f35528adedb102d2d0dcef2 | 18:53.17 |
| ray_laptop | OK. Thanks. I'll look at it and email you today | 18:53.34 |
| Robin_Watts | thanks. | 18:54.16 |
| ray_laptop | first comment -- you say 'collate' -- I think 'collect' would be better in the first sentence ;-) | 18:54.22 |
| mvrhel | this is weird | 19:16.23 |
| | bbab | 19:16.27 |
| t4nk790 | Trying to fix a clipping path problem for the PCL device - is there any way I can set the clipping path or have some page setup PS executed for every page being rendered as PCL? | 19:54.41 |
| mvrhel_laptop | alexcher you there? | 23:33.44 |
| | or Robin_Watts? | 23:33.50 |
| | or henrys? | 23:33.58 |
| Robin_Watts | hi | 23:34.00 |
| mvrhel_laptop | so recall the weird file that is not drawing spot colors even with ppmraw? | 23:34.23 |
| Robin_Watts | yes. | 23:34.35 |
| mvrhel_laptop | it appears to me that the tint transform functions are not getting handled properly by the interpreter | 23:34.49 |
| | but I may be wrong | 23:35.39 |
| | about the interpreter, | 23:35.47 |
| Robin_Watts | Is it something silly like only the first CLIENT_COMPONENT_MAX tint transforms are being stored in an array somewhere? | 23:36.08 |
| mvrhel_laptop | that is what I am wondering | 23:36.20 |
| Robin_Watts | It'd be hard to see how that could be the case purely in the interpreter. | 23:36.34 |
| mvrhel_laptop | digging further on this now | 23:36.35 |
| | right | 23:36.38 |
| Robin_Watts | gxcdevn.h line 36 ? | 23:37.33 |
| mvrhel_laptop | this is just a guess right now based upon what I am seeing. it wants to do to the tint transform. It seems to be failing on the separation all case, which is where it should do all the colorants. A somewhat special case | 23:38.23 |
| | anyway. I have to dig a bit more | 23:38.33 |
| Robin_Watts | no, probably not that, that's devn. | 23:38.34 |
| | How about icremap.h line 35 ? | 23:38.45 |
| mvrhel_laptop | I don't think this issue was caused by my change though | 23:38.49 |
| Robin_Watts | FWIW, I reckon the vertical lines is us reading off the edge of images into unset memory. | 23:40.05 |
| | I'm going to dig more into that tomorrow. | 23:40.12 |
| mvrhel_laptop | sounds good | 23:40.26 |
| | I may be up working on this when you get up | 23:40.37 |
| | have to go to a baseball game in a bit | 23:40.49 |
| | this is a crazy week of activities here | 23:40.57 |
| | hmm this damn thing is doing the remap but nothing is getting drawn. | 23:42.40 |
| | I am going to have to step through the fill code | 23:42.52 |
| | weird. a bunch of fills are getting clipped | 23:50.21 |
| | ok. need to run | 23:50.25 |
| Robin_Watts | I'm off to bed. Enjoy the ball game. | 23:50.42 |
| | Forward 1 day (to 2012/07/24)>>> | |
IRC Logs