| | <<<Back 1 day (to 2012/03/18) | 2012/03/19 |
| tkamppeter | kens, hi | 08:02.17 |
| kens | Morning Till | 08:02.27 |
| tkamppeter | chrisl, hi | 08:02.32 |
| | kens, chrisl has found a solution for the problem of Brother PostScript printers not printing PostScript generated from gedit's PDF via GS ps2write. | 08:03.30 |
| kens | tkamppeter, I know. | 08:03.41 |
| | We both worked on it over the weekend | 08:03.47 |
| tkamppeter | kens, he told that you need to do a change on Ghostscript to implement the workaround. | 08:04.06 |
| kens | Yes, there is no current way to disable CCITT compression on bitmap glyphs | 08:04.26 |
| tkamppeter | kens, can you do this so that I have a patch for GS 9.05 before Wednesday so that I can apply the workaround still in Ubuntu Precise beta2? Thanks. | 08:04.52 |
| kens | I will start on it shortly | 08:04.52 |
| | chrisl also sent me the request. | 08:05.02 |
| tkamppeter | kens, OK, great. | 08:05.14 |
| kens | Barring any nasty surprises I woudl expect it to be available today | 08:05.18 |
| | But I want to check 'regular' images as well, I think you shoudl disable CCITT compression for those too on the Brother printer. | 08:05.45 |
| | Just finished my email | 08:06.03 |
| | I'll get to it in a moment | 08:06.09 |
| chrisl | tkamppeter: I don't know what the plans are for the Freetype package in Precise, but there's a bug in Freetype 2.4.9 which breaks Ghostscript - my fix is in the FT repos, but is not released. So, I'd recommend not getting the latest Freetype for Precise. | 08:08.09 |
| tkamppeter | Our FreeType is 2.4.8. | 08:23.33 |
| chrisl | tkamppeter: good, as long as it stays that for the release, we're good. | 08:26.03 |
| kens | chrisl what do you know about GS command line parsing and parameter passing ? | 08:46.50 |
| | Nothin I do affects the MonoImageFilter setup :-( | 08:47.03 |
| tkamppeter | chrisl, we are after Feature Freeze, if there is no very severe (security) bug in 2.4.8 which can only be fixed by advancing to 2.4.9, the update will not happen. | 08:47.10 |
| chrisl | kens: pdfwrite should get a putparams with the parameter list pulled from the command line | 08:50.20 |
| kens | Sure, but do you have any idea where it gets processed ? Does it need to be done explicityly ? (I feel it muist) there is no actual code to read the parm 'MonoImageFilter' anywhere I can find which suggest it is not beign set, other than the default. | 08:51.22 |
| chrisl | It should happen in the Postscript world, I think. | 08:52.25 |
| kens | Hmm. | 08:52.33 |
| | But somehow it has to make its way into the pdfwrite device structure | 08:52.46 |
| chrisl | Which is where the putparams comes in | 08:53.07 |
| kens | Right, but put params therefore ought to have xeplicit code for 'MonoImageFilter' and it doesn't | 08:53.39 |
| | However this is massivley complicated in the pdfwrite world | 08:53.48 |
| | THere is some crazy code in gdevpsdp.c which might be doing it..... | 08:54.10 |
| chrisl | Yes, unless it's being handled by the generic version of put_params, which seems extremely unlikely..... | 08:54.23 |
| kens | That's what I though. | 08:54.35 |
| | OK I'll try and get my head round the weird code. | 08:54.49 |
| | Oh yes, its the crappy macros again :-( | 08:55.14 |
| chrisl | Isn't it in: psdf_put_image_params()? | 08:57.16 |
| kens | Yes, I just got ther | 08:57.27 |
| | Now working through it | 08:57.39 |
| chrisl | Seems to be ignoring MonoImageFilter, though :-( | 08:58.22 |
| kens | Yes, it certainly is | 08:58.30 |
| | It only handles MonoImageDict | 08:58.41 |
| chrisl | Which doesn't help us | 08:59.06 |
| kens | I think monoImageFilter is never processed | 08:59.10 |
| chrisl | I guess that pdfwrite does some nefarious nonsense to ignore unrecognised device options | 09:00.22 |
| kens | unrecognised device options are alway ignored by GS, try it out :-) | 09:00.44 |
| chrisl | Oh, yes, it's only when the *setting* isn't recognised we might generate an error/warning..... | 09:01.41 |
| kens | :-) | 09:01.46 |
| chrisl | What about EncodeMonoImages, what does that do? | 09:02.07 |
| kens | Stops them being compressed | 09:02.14 |
| | at all | 09:02.21 |
| | I was going to use that as a last resort | 09:02.33 |
| | But I wanted to know if the paramters worked first, seems like they don't and that's a bug | 09:02.51 |
| | :-( | 09:02.54 |
| | Yes well at least that actually works | 09:04.19 |
| | OK going to go with that for now. | 09:04.34 |
| chrisl | Oddly, MonoImageFilter *seems* to be handled for *get_params*, though....... | 09:05.36 |
| kens | Yes it is, which was one of the things puzzling me. | 09:05.49 |
| | But we need to handle all the paramters for a get | 09:05.58 |
| | It looks to me like this all needs rewriting. | 09:06.14 |
| chrisl | Yeh, it just seems silly to support it for get, and not for put..... | 09:06.23 |
| kens | The code in gdepsdi persists in handling all images as 'colour' too. | 09:06.29 |
| | Fortunately the masks work out because (surprise) they are handled as an exceptio. THis is due ot the way Acrobat works (undocumented of course) | 09:07.05 |
| chrisl | Well, as I said before, given that the entire file gets lzw compressed in ps2write, I don't *think* leaving bitmaps "uncompressed" is *such* a big deal. | 09:07.59 |
| kens | Yes I agree and its the easiest way ot proceed. Its also the only way to get something reasonably reliable to Till by Wednesday. I certainly don't want to rewrite the image handling just in time for a Ubuntu release! | 09:08.53 |
| chrisl | And if anyone complains about the PS being bigger, tell them to Brother to fix their cr*ppy printer! | 09:12.22 |
| kens | :-) | 09:12.28 |
| | I'm assuming Till will only add these to the Brother printers | 09:12.43 |
| chrisl | I did say that on the Ubuntu bug tracker, but worth reiterating when you give him the patch and parameter to use. | 09:13.52 |
| kens | Yes, will do. | 09:14.02 |
| | OK cluster push to make sure I haven't done anything truly dumb. Test show the parameter works as expected with teh sample file. | 09:20.57 |
| | tkamppeter I've commited the patch as | 10:07.01 |
| | d6f83dfa81a2073c3d1f67a30aee7e8407e4685a | 10:07.02 |
| | It would be great if you and Bruce could implement and test this with CUPS, just to be certain | 10:07.35 |
| | You cna get a diff of the patch here: | 10:08.09 |
| | http://ghostscript.com/pipermail/gs-cvs/2012-March/014381.html | 10:08.09 |
| tkamppeter | kens, can I simply apply the patch to 9.05? And what is the PostScript code equivalent of using the command line options "-dNoT3CCITT -dEncodeMonoImages=false" (to add it to the Brother workaround PS code injection, so there is only one point for applying the complete workaround in pdftops). | 10:24.17 |
| kens | tkamppeter you can apply the patch to 9.05 I'm sure. | 10:24.39 |
| | I'm not sure there is a PostScript equivalent to -dNoT3CCITT | 10:25.04 |
| tkamppeter | kens, does -dXXX not mean that some PS variable XXX gets defined? | 10:26.28 |
| kens | tkamppeter it will be a setuser param hang on a minute and I'll get it for you | 10:26.43 |
| chrisl | tkamppeter: you can't prepend this to the PS being sent to the printer, this changes how Ghostscript emits the PS | 10:28.51 |
| kens | Oh yes, you need to add it to the ps2write command line | 10:29.15 |
| | For productin of the PostScript. | 10:29.35 |
| tkamppeter | kens, chrisl, thank you very much. | 10:29.54 |
| kens | FWIW I can't find a method of setting the user parameters that works :-( | 10:32.17 |
| | So for now its command line only | 10:32.26 |
| tkamppeter | kens, the GIT went away. | 10:36.05 |
| | kens, chrisl, copied the patch from the e-mail notification and it applies to 9.05, building the Precise package ... | 10:41.55 |
| kens | Great, thanks Till | 10:43.08 |
| tkamppeter | kens, new Ghostscript package is uploaded to Precise, comments and test files added to the bug. | 11:13.54 |
| | chrisl, ^^ | 11:14.03 |
| kens | OK hopefully it will be OK | 11:14.19 |
| chrisl | tkamppeter: great, we'll keep our fingers crossed! | 11:14.46 |
| tkamppeter | kens, chrisl, cups-filters upstream is now appropriately updated. | 11:49.31 |
| kens | Cool. Has anyone tested it for real ? | 11:50.08 |
| Robin_Watts | kens, chrisl: I just got a flier through the post for Sign and Digital UK 2012. | 12:11.45 |
| kens | had an email one last week | 12:11.59 |
| Robin_Watts | It's while I'm on holiday, so I can't visit it (27th-29th). | 12:12.04 |
| | ah, fair enough. | 12:12.26 |
| chrisl | I wasn't terribly enamoured with the show, anyway..... | 12:13.42 |
| kens | I think once was enough | 12:14.30 |
| Robin_Watts | I feel the same, I think. | 12:16.02 |
| galtgendo | What is the proper way of setting up CID font substitutions ? AFAICT, I followed the docs, still neither of Japanese examples works. | 12:45.10 |
| kens | Have you supplied -I and a path to your modified cidfmap ? | 12:45.32 |
| | What versionm of GS are you using ? | 12:45.43 |
| galtgendo | 9.05 | 12:45.48 |
| kens | And have you set the -I switch | 12:46.29 |
| galtgendo | well, not quite, there's a /usr/share/ghostscript/9.05/Resource/Init/cidfmap.ja with AFAICT correct content, that should be read by cidfmap in the came dir | 12:48.42 |
| kens | And have you supplied that as a command line paramter using -I ? | 12:49.04 |
| | Or compiled Ghostscritp without built-in resources ? | 12:49.14 |
| | Why do you think hte cidfmap.ja will be read by cidfmap ? | 12:49.39 |
| galtgendo | shouldn't that be read automatically ? | 12:49.45 |
| kens | No. | 12:49.48 |
| | Recent versions of GS have the resources built into a ROM file system | 12:50.02 |
| | You either need to rebuild without that option, or supply additional include directories on teh command line | 12:50.24 |
| galtgendo | well, there's '(cidfmap.ja) .runlibfileifexists' in cidfmap | 12:50.44 |
| kens | Why have you not simply modified cidfmap ? | 12:51.23 |
| galtgendo | that cidfmap is from the distro - I have a rather poor grasp of ghostscript, so I'd rather not do too many modifications on my own (I only changed the preferred truetype font for the substitution) | 12:56.17 |
| kens | The whole point of the file is to be modified :-) | 13:01.30 |
| galtgendo | anyway, /usr/share/ghostscript/9.05/Resource/Init is among paths printed by 'gs --help'; shouldn't that be enough ? | 13:01.41 |
| kens | Yes, shoudl be. | 13:02.04 |
| | So try modifying the cidfmap rather than adding things in a separet file | 13:02.16 |
| chrisl | galtgendo: if the file and layout are dictated by your distribution, why don't you take this up with the maintainer? | 13:02.19 |
| galtgendo | printing herd is significantly understaffed here, when you add cjk to to the mix...:roll: | 13:03.58 |
| chrisl | galtgendo: the problem is *our* cidfmap does not contain '(cidfmap.ja) .runlibfileifexists', so clearly that's a modification made by the GS maintainer on the distro. It's hard for us to guess how he/she intended for this stuff to be used. | 13:06.18 |
| galtgendo | also, a few days ago, something odd has been reported about ghostscript and freetype, so I wonder if it's not somehow related | 13:06.24 |
| chrisl | galtgendo: no, it's not related - the "something odd" is that Freetype 2.4.9 is broken...... | 13:06.54 |
| | galtgendo: can you post a link to the contents of the cidfmap.ja file? | 13:07.33 |
| galtgendo | it wasn't CID font related, but (it seems) font matching related (https://bugs.gentoo.org/show_bug.cgi?id=408513) | 13:09.19 |
| | as for the content, let me pick a pastebin | 13:09.41 |
| chrisl | galtgendo: no the freetype thing is not related to this, like I said, Freetype 2.4.9 is broken - see https://savannah.nongnu.org/bugs/index.php?35847 and https://savannah.nongnu.org/bugs/index.php?35833 | 13:11.03 |
| galtgendo | http://pastebin.ca/2129985 | 13:13.06 |
| chrisl | galtgendo: well, the contents do *look* okay. As a test, I would suggest you copy the contents from cidfmap.ja into cidfmap and see if that works. If it does, raise a bug with Gentoo (I'm assuming you're using Gentoo.....) | 13:15.08 |
| | galtgendo: FWIW, .runlibfileifexists appears to be an addition - I can't find it defined in *our* sources..... | 13:16.32 |
| galtgendo | chrisl: well, .runlibfileifexists seems to be some RedHat/Fedora import, but even renaming cidfmap.ja to cidfmap doesn't help - the font still isn't getting substituted correctly | 13:20.51 |
| chrisl | galtgendo: do the font files it's pointing at actually exist? | 13:21.54 |
| galtgendo | they definitely do | 13:22.42 |
| chrisl | Okay, try adding -I/usr/share/ghostscript/9.05/Resource/Init to your gs command line | 13:23.09 |
| galtgendo | doesn't help - rightnow, I'm testing on examples/cjk/gscjk_aj.ps and the displayed results are still "error in findfont" for the three Japanese fonts used | 13:25.56 |
| chrisl | Well, you're using configuration files we don't supply, which use an operator that we don't implement - I'm struggling to see how we can help any more...... | 13:27.23 |
| | galtgendo: can you post the entire output in a pastebin? | 13:28.45 |
| galtgendo | chrisl: the last test is still with only cidfmap.ja content in cidfmap - so, no custom operators there | 13:28.55 |
| chrisl | galtgendo: nevertheless, I can't guess at else the maintainers might have changed | 13:29.53 |
| galtgendo | chrisl: http://pastebin.ca/2129992 | 13:31.16 |
| chrisl | galtgendo: can you run that again with the extra parameter -dDisableFAPI and post the output, please? | 13:33.51 |
| galtgendo | chrisl: not counting gsdjvu stuff, there;s about 6k of patches (about 2k of that is .runlibfileifexists) - that doesn't look like much | 13:34.51 |
| | chrisl: http://pastebin.ca/2129996 | 13:38.06 |
| chrisl | galtgendo: using the cidfmap contents you posted (modified only to change the paths, which are different on my system), gscjk_aj.ps runs to completion with no errors for me, on 9.05 | 13:42.44 |
| galtgendo | well, the annoying thing here is that I do recall those example files working at some point in the past | 13:44.40 |
| chrisl | galtgendo: I'd like to help, but since *our* release works, and the gentoo package doesn't it's clearly something that's happened outside our control or knowledge...... | 13:47.53 |
| Robin_Watts | We've moved to openjpeg from jasper in gs, right? | 13:49.09 |
| chrisl | Robin_Watts: erm, sort of...... | 13:49.23 |
| Robin_Watts | sort of ? | 13:49.50 |
| kens | A version of... | 13:49.56 |
| | Its the in-development rather than released code | 13:50.12 |
| Robin_Watts | Right. | 13:50.19 |
| galtgendo | OK, I'll try to work it out on my own, just a little thing: any chance this too is something related to freetype 2.4.9 ? | 13:50.24 |
| Robin_Watts | But when I attempt to set a breakpoint on opj_malloc, it won't stop. | 13:50.40 |
| | And the VS solution still lists jasper, rather than openjpeg. | 13:51.05 |
| chrisl | galtgendo: no, for the *third* time, the freetype problem is entirely unrelated, and is a freetype bug..... | 13:51.09 |
| | Robin_Watts, kens: the openjpeg we have is not the in-development code, it's the release code with features back-ported from the in-development code..... | 13:51.54 |
| | Robin_Watts: VS solution doesn't necessarily reflect the build! | 13:52.37 |
| kens | Oops sorry. | 13:52.40 |
| | Yes, I suspect alex didn't change it | 13:52.51 |
| Robin_Watts | chrisl: Indeed. Just mentioning it here, in the hopes that our collective brains can forget it less efficiently than my single one. | 13:53.11 |
| kens | optimist.... | 13:53.24 |
| | Will you be online Wednesday Robin, or busy packing ? | 13:53.42 |
| Robin_Watts | online. I hope. | 13:53.55 |
| Robin_Watts | foods. | 13:54.10 |
| chrisl | Robin_Watts: OpenJPEG *should* be using the gs memory manager, could that be why opj_malloc doesn't get called? | 13:54.19 |
| kens | Must think up some deilish questions for Wednesday, to torment Robin on holiday >:-) | 13:54.30 |
| Robin_Watts | chrisl: Yeah, opj_create_decompress gets called. | 13:55.53 |
| | So I can breakpoint that. | 13:56.03 |
| chrisl | Having said that, I'm not seeing *where* OpenJPEG gets setup to use out memory manager..... :-( | 13:57.02 |
| tkamppeter | kens, chrisl, is there any bug report for the problem of freetype 2.4.9 with Ghostscript? | 14:06.25 |
| kens | In GS Bugzilla ? no | 14:06.45 |
| chrisl | tkamppeter: see https://savannah.nongnu.org/bugs/index.php?35847 and https://savannah.nongnu.org/bugs/index.php?35833 | 14:07.23 |
| | tkamppeter: as I said earlier, my patches for both those problems are committed to the FT repos, but are not in a released FT yet. | 14:09.03 |
| tkamppeter | chrisl, thanks, until which hour will you be available today? | 14:10.10 |
| chrisl | tkamppeter: probably until around 5-ish UK time. | 14:11.03 |
| chrisl | wonders why the Gentoo bug tracker won't send me the e-mail to create an account....... | 14:12.17 |
| kens | Might take a while, I've had that before | 14:12.35 |
| chrisl | Well, it's been well over half an hour | 14:13.09 |
| Robin_Watts | Ah. | 14:33.00 |
| | We have a file that works in gs, but not in mupdf. | 14:33.16 |
| | And it seems to work in gs by the using a mysterious 3rd arg to opj_decode that isn't in openjpeg 1.5.0 | 14:33.56 |
| | I wonder if this is a backported bugfix. | 14:34.07 |
| chrisl | It's a backported feature, I believe | 14:34.41 |
| Robin_Watts | ooh. new feature on the blame page of git.ghostscript.com; it puts initials in to say who to blame. | 14:35.55 |
| | I wonder if we should adopt the same openjpeg version for mupdf. | 14:36.49 |
| chrisl | Oh, crap, the OpenJPEG v2 branch doesn't have the extra parameter for opj_decode() - that's not good..... :-( | 14:38.28 |
| Robin_Watts | http://groups.google.com/group/openjpeg/browse_thread/thread/f70f582fe45631d?pli=1 | 14:39.40 |
| | So it looks like v2 will be done slightly differently. | 14:41.08 |
| chrisl | Oh, so what we've got is just a fork. That's not great. | 14:42.17 |
| galtgendo | chrisl: after a bit of tinkering, I've reached an odd result - one of the files sort of works, the other segfaults | 14:48.36 |
| chrisl | galtgendo: well, I only tried the one file you indicated earlier. | 14:49.52 |
| galtgendo | a simple question first: is it that the search paths reported by 'gs --help' are of no relevance for CMaps ? | 14:50.03 |
| chrisl | galtgendo: the CMaps should be in the <path to Init>/../CMaps - for example: /usr/share/ghostscript/9.04/Resource/Init/../CMaps | 14:51.35 |
| galtgendo | that is: /usr/share/poppler/cMap/Adobe-Japan1 is listed, but unless I create a symlink in /usr/share/ghostscript/9.05/Resource/CMap the CMaps contained in the dir aren't detected | 14:51.59 |
| chrisl | galtgendo: I don't know of a way to point GS at a particular directory just for the CMaps, but I'm not definitive on that | 14:53.32 |
| kens | You cna't | 14:54.21 |
| | all resources must be under Resource I htink | 14:54.30 |
| | So you cna point to a resource directory but not to a CMap directory. | 14:54.48 |
| chrisl | galtgendo: what other distributions, who want to share CMap data, so is make a softlink from Resource/CMap to the shared CMap directory | 14:55.55 |
| galtgendo | chrisl: well, the problem here is that poppler installs cMap/Adobe-CNS1, cMap/Adobe-GB1, cMap/Adobe-Japan1, cMap/Adobe-Japan2, cMap/Adobe-Korea1, while ghostscript seems to expect only a single dir - yes, this could be worked around by a symlink forest, but I'm asking if it must be | 15:00.17 |
| chrisl | galtgendo: Well, use the CMap directory we ship, would be my suggestion | 15:02.22 |
| | galtgendo: in the gentoo ebuild script it says: "remove internal CMaps (CMaps from poppler-data are used instead)". But clearly the CMaps files from poppler are clearly not being setup in such a way that GS can use them - THIS IS A PACKAGE BUG, NOT A GS PROBLEM! | 15:05.54 |
| kens | GS expects all cmaps to be in a 'resource' directory. You can have multiple resource directories | 15:06.23 |
| Robin_Watts | Actually... openjpeg-1.5 may have gained the required feature. | 15:16.09 |
| chrisl | Robin_Watts: I was wondering about that - might be worth asking Alex to check it..... | 15:17.05 |
| Robin_Watts | Well, it works enough to have solved the bug in mupdf. | 15:17.26 |
| chrisl | It's just that it would be nice if we could use released code in the GS world, too..... | 15:18.24 |
| Robin_Watts | Yes. I'll send an email when I've tested this properly. | 15:20.36 |
| galtgendo | chrisl: OK, it seems it's the symlink forest option then - as I said, this sort of works for cjk/all_aj1.ps and cjk/all_aj2.ps, but segfaults for cjk/gscjk_aj.ps - I'll try to check why later | 15:21.07 |
| | I'll file a bug about it in Gentoo in a while | 15:21.52 |
| chrisl | galtgendo: it might be related to not finding a CMap - that kind of error condition gets very little testing. | 15:22.05 |
| | galtgendo: FWIW, I *strongly* suggest using the CMaps we ship - not least because we supply at least one non-standard CMap which gets used in some cases when substituting a Truetype font for a CIDFont | 15:23.44 |
| galtgendo | chrisl: doesn't seem that way - both CMaps (RKSJ-V and RKSJ-H) are present | 15:24.21 |
| chrisl | galtgendo: well, again I can't reproduce the crash - but I'm certainly not using the same third party libraries that you are. | 15:27.36 |
| henrys | alexcher:of 692850 why don't you do a bisect or ask marcos? | 15:30.58 |
| galtgendo | chrisl: most likely not; anyway, due to the lack of debug symbols, backtrace isn't that interesting, though it seems to confirm it's something CID font related | 15:40.43 |
| chrisl | galtgendo: I'm not sure it will help, but could you pastebin the backtrace - such as it is? | 15:52.16 |
| henrys | kens:so 689487 was a bug and not just a heap of left over allocations? | 15:54.11 |
| | kens:responding to your mail here. | 15:54.34 |
| kens | erm, whichh email ? | 15:55.51 |
| henrys | Saturday | 15:56.53 |
| | subject "pdfwrite memory" | 15:57.24 |
| kens | henrys its not exaclty 'left over' allocations. | 15:58.53 |
| | THey ar GC tracked allocations | 15:58.59 |
| | SO no leak in PostScript mode | 15:59.06 |
| henrys | I see. | 16:02.33 |
| kens | I've found the first one today I'm just tryong to find out where to free it | 16:03.16 |
| henrys | sorry "left over" was a bad way to put it - not explicitly deallocated. | 16:08.24 |
| kens | :-) | 16:08.29 |
| | THere may stuill be leaks | 16:08.37 |
| henrys | mvrhel:I started poking at the planar stuff today I think to meet their memory requirements we'll have to halftone before banding. As it is now we use high level images or rectangles if high level images are disabled. Is that a substantial code change to make? | 16:19.55 |
| mvrhel | henrys: no this should be pretty easy | 16:20.15 |
| galtgendo | chrisl: sure, http://pastebin.ca/2130078 | 16:21.31 |
| henrys | I wonder if we want that to be the default. | 16:21.33 |
| mvrhel | oh wait | 16:21.33 |
| | henrys: so we want to have another type, not rectangles, and not high level | 16:21.55 |
| | a high level but already halftoned | 16:22.09 |
| Robin_Watts | Hmm. I suspect we want to be smarter. | 16:22.29 |
| mvrhel | I didnt say we were not smart... | 16:23.20 |
| Robin_Watts | We want to say "How big will the halftoned version of this be?" and use that if it's smaller. | 16:23.22 |
| mvrhel | of course | 16:23.28 |
| henrys | well my thought was it would reduce to copy_color but maybe robin_watts has another idea. | 16:23.28 |
| chrisl | galtgendo: hmm, that's very odd - there's no third party libs calls in the way there, but not real clue as to what the problem might be. Can you discuss with the package maintainer about reproducing it in such a way that we could look at it? | 16:24.02 |
| Robin_Watts | Because blindly halftoning on an upscaled image could easily produce a larger data set. | 16:24.09 |
| mvrhel | of course. we talked about that when we started that | 16:24.25 |
| | there is the issue of color space size and bit depth | 16:24.34 |
| Robin_Watts | mvrhel: Sorry. Fair enough then. (but it seems that "of course" hasn't always applied in such things... :) ) | 16:24.52 |
| mvrhel | if it gets bigger we would not do it | 16:24.58 |
| | henrys: I don't see this being too hard to do | 16:25.42 |
| | I will start on it when I get this tiffsep planar stuff wrapped up which hopefully will not be much longer | 16:26.05 |
| henrys | there are other performance reasons not do it though which concerns me -- multiprocessing is shot. | 16:26.15 |
| chrisl | I thought halftoning pre-clist was problematic when rops were involved? | 16:26.22 |
| mvrhel | henrys: you mean mutlithreading. yes. we will still have the sse2 stuff going on | 16:26.57 |
| henrys | halftoning alone is problematic when rops are involved | 16:26.58 |
| | yes threading sorry | 16:27.19 |
| Robin_Watts | mvrhel: There is scope to make use of multithreads in such circumstances. | 16:28.30 |
| mvrhel | Robin_Watts: we (or I) will probably make that a phase 2 aspect of this | 16:28.54 |
| Robin_Watts | If an image is large enough to fit into several bands, we could send the task of halftoning for each thread into a separate worker thread or something. | 16:29.28 |
| mvrhel | yes | 16:29.35 |
| henrys | chrisl:I worked at a printer company 20 freakin' years ago and we found gdb on the printer indespensible. These clowns should stop everything and get that working before they do another thing. | 16:29.41 |
| Robin_Watts | (If the data is available all at the same time etc) | 16:29.51 |
| mvrhel | right | 16:29.55 |
| Robin_Watts | mvrhel: But I completely agree about that being a phase 2 thing :) | 16:30.03 |
| chrisl | henrys: I rather agree - but I'm not going to risk Miles' wrath by saying that....... | 16:30.29 |
| henrys | no of course not - the whole situation is rather frustrating. | 16:33.33 |
| mvrhel | the file that he sent is that the full output? I would have expected to see something to do with patterns at the time of the crash | 16:35.39 |
| | patterns and transparency | 16:35.48 |
| | It just seems to be chugging along with each band | 16:36.28 |
| | the output he sent doesnt really tell us a thing | 16:37.19 |
| chrisl | It's possible the Len was right about the crash happening when there's still buffered output. I'm trying to get the simulator to produce the debug output to compare it | 16:37.30 |
| mvrhel | good idea | 16:37.44 |
| chrisl | Seems to be harder than it ought to be..... as always..... :-( | 16:41.55 |
| mvrhel | I think henrys is right though. being able to step through on the printer is the only way to do this | 16:42.11 |
| | at some point you have to dig in on the real thing | 16:42.43 |
| Robin_Watts | Does the crash actually happen on the printer with a debug build ? | 16:43.20 |
| mvrhel | I think so | 16:43.36 |
| | they are getting output from -Zv | 16:43.41 |
| | so they are running a debug version | 16:43.50 |
| chrisl | We don't know that it's easy to add -DDEBUG to the CFLAGS, and Len only states "no optimization" in the latest mail | 16:44.57 |
| Robin_Watts | Yeah, he definitely said that he'd tested "-DDEBUG" in his mail of 17/03/2012 15:18. | 16:46.10 |
| | So that doesn't rule out it being a compiler bug. But his latest mail (in which he says he's tested without optimisation) does make it less likely. | 16:46.57 |
| chrisl | Robin_Watts: that was the reason I asked him to test that way - it does feel a bit like a compiler bug.... | 16:47.58 |
| henrys | chrisl:Miles is completely ready to turn this back to them. It is you and ray_laptop that have decided to work on it. My position is somewhat in-between, just so you know where we are all at on this. | 16:49.28 |
| chrisl | henrys: well, frankly, I'm out of ideas, anyway - other than actually debugging the target | 16:53.30 |
| henrys | so go ahead and punt it back to them and I'll call Miles so he's ready. Or if you want somebody else to respond Len let me know. | 16:55.40 |
| chrisl | I'll reply- I'm only going to be honest....... but I feel we can't ignore them if they ask for advice. | 16:56.44 |
| henrys | fair enough. | 16:57.46 |
| | bbiab | 17:10.41 |
| chrisl | henrys: (when you get back) Shelly pinged me to ask if there was anything he could do - I vaguely remembered you mentioning pushing a couple of x11 or x11alpha bugs his way, but I don't know if that's still the case. | 17:13.11 |
| diverdude | Hello, what is the simplest way to combine all pdf-files in a folder into a single pdf? | 17:13.15 |
| Robin_Watts | chrisl: We were going to make a bounty bug to remove all warnings from the jbig2dec build, IIRC, but I (for one) never got around to it. | 17:14.57 |
| kens | diverdude, add them all to GS on teh command line | 17:15.14 |
| Robin_Watts | diverdude: gs -o out.pdf -sDEVICE=pdfwrite in1.pdf in2.pdf in3.pdf ... | 17:16.08 |
| chrisl | Robin_Watts: Oh, that would be good, but we should resolve the situation with the jbig2dec repository before that kind of wide ranging change | 17:16.22 |
| diverdude | ahhh pdftk *.pdf cat output collection.pdf | 17:17.01 |
| kens | Goodnight all | 17:21.38 |
| henrys` | I gave shelly a pcl driver bug to work on. I'll work on making some other bountiable. | 17:24.58 |
| malc_ | Robin_Watts: any idea if ARM ARM is still not available without registration? | 17:30.27 |
| chrisl | henrys': okay, thanks! I think he's bored....... | 17:31.02 |
| Robin_Watts | malc_: I believe the ARM ARM is no longer the latest reference. | 17:31.23 |
| | but I have ARM ARM revision I. | 17:31.37 |
| malc_ | Robin_Watts: thing is, tor did fix the text issue with (40ae12884335856f803dc76bfbe97b1c8743b9b9) but what mupdf does with text DDI0406B_arm_architecture_reference_manual_errata_markup_8_0.pdf is simply criminal.. just searching for ARM on page 1 showcases the issue nicely | 17:32.58 |
| Robin_Watts | malc_: Can you mail me that file please? | 17:34.47 |
| malc_ | Robin_Watts: It's 12Mb | 17:35.09 |
| Robin_Watts | That's fine. | 17:35.17 |
| malc_ | Robin_Watts: @artifex.com? | 17:35.59 |
| Robin_Watts | please. | 17:36.06 |
| henrys` | chrisl:when did you get 3 customer bugs - just noticed in the weekly aging? | 17:37.42 |
| malc_ | Robin_Watts: sent, please tell me when it gets to you | 17:37.56 |
| chrisl | henrys: only one is a recent one, the other two are older ones I inherited. | 17:38.32 |
| Robin_Watts | malc_: It hasn't arrived yet, and I have to pop out for ~40mins to an hour. | 18:06.28 |
| malc_ | Robin_Watts: as i suspected, spam filters do not like me it seems | 18:09.28 |
| galtgendo | chrisl: well, I've rechecked things and that crash came from a completely different spot than I originally expected | 18:11.53 |
| | namely from FAPIcidfmap | 18:12.12 |
| malc_ | when ps2pdf-ing a file is getting range check error something that's possible (.ps was produced by html2ps fwiw)? | 18:13.05 |
| galtgendo | chrisl: does an entry '/Ryumin-Light << /Path (/usr/share/fonts/ipamonafont/ipag-mona.ttf) /CIDFontType 0 /FAPI /UFST /CSI [(Japan1) 2] >> ;' look correct for you ? | 18:13.40 |
| | or am I misinterpreting the purpose of FAPIcidfmap ? | 18:14.57 |
| chrisl | galtgendo: No, that's completely wrong...... except in very special circumstances (which this isn't!) FAPIcidfmap should be empty (except for some comments) | 18:15.23 |
| | Admittedly, it shouldn't crash, though. | 18:16.06 |
| galtgendo | OK, in such case, except for those CMap dir issues, it was a false alarm then | 18:16.30 |
| | I'll file about it in the distro bugzilla in a bit | 18:17.27 |
| | chrisl: thanks for the help | 18:17.53 |
| chrisl | galtgendo: Well, you've found a real crash, which I should fix, but FAPIcidfmap shouldn't be used in your case | 18:17.58 |
| | galtgendo: it wasn't much help, but you're welcome anyway! | 18:18.19 |
| galtgendo | chrisl: sometimes even a sounding board is enough | 18:23.05 |
| chrisl | galtgendo: can you do me favor, please? | 18:23.20 |
| galtgendo | chrisl: namely ? | 18:23.50 |
| chrisl | On this Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=408513 that you pointed out earlier...... | 18:24.20 |
| | Can you add a comment (credit to me, if you like) that it is caused by a Freetype bug, and add the following links: | 18:25.15 |
| | https://savannah.nongnu.org/bugs/index.php?35847 | 18:25.42 |
| | https://savannah.nongnu.org/bugs/index.php?35833 | 18:25.50 |
| | Both are fixed in the Freetype repos, but not in a release yet. | 18:27.39 |
| | I did try to get an account on the Gentoo bug tracker to post it myself, but the alleged e-mail never arrived....... | 18:28.24 |
| galtgendo | chrisl: OK, I've just added the short comment - is its content sufficient ? | 18:33.34 |
| chrisl | galtgendo: perfect, thanks! No sense having those guys chasing down something that's already resolved..... | 18:37.43 |
| | galtgendo: if there's any follow-up to that post, just point them here for answers. | 18:45.17 |
| chrisl | is off now.... | 18:53.33 |
| Robin_Watts | malc_: Have spoken to tor8 about that file - currently we just give blocks in the order we get them in the file. | 19:43.36 |
| | So that file (which gives the last line on the page first) ends up sorting that way too. | 19:44.00 |
| mvrhel | ok. my fixes on the tiff sep device seem to be working for simple files. need to check transparency, patterns and gradients. off to run a couple errands now | 19:48.27 |
| malc_ | Robin_Watts: i see, thanks for looking | 20:18.34 |
| | Forward 1 day (to 2012/03/20)>>> | |
IRC Logs