| | <<<Back 1 day (to 2011/09/21) | 2011/09/22 |
| madcrow | quick question | 02:08.51 |
| | does ghostpcl include an intellifont rasterizer at all? | 02:09.13 |
| | some things i've seen say that it has a really basic one | 02:09.27 |
| | others say that it doesn't | 02:09.38 |
| | anyone? | 02:14.44 |
| | bah. i gotta go. please answer if you see this and i'll find the answer in the logs ;) | 02:22.23 |
| henrys | madcrow:yes it supports a basic intellifont rasterizer. | 02:40.26 |
| cryptopsy | im convert a doc that's taking too long, about 1 hour for a ps2pdf conversion | 02:47.16 |
| | cpu usage at 50% | 02:47.24 |
| | can i get some debug information? | 02:47.32 |
| mvrhel2 | good night all | 05:38.53 |
| kens | cryptopsy its impossible to say how long a conversion to PDF 'should' take, since it depends on many things. One of them being whether anything needs rasterised (eg transparecny). There is no useful debug information for performance. If the inpu tis a PDF file tehn it may be that -dPDFDEBUG would be helpful. If the input is PostScript hen you can instrument teh PostScript file. | 06:37.15 |
| chrisl | kens: which of the test jobs with a MM font are you using? I assume you're using the simplest job, just now. | 07:50.14 |
| kens | I'm creating my own. | 07:52.31 |
| | As well as using test-setweightvector.ps an tpc2.ps | 07:52.46 |
| | BTW It looks like MM fonts *do* work correctly with FAPI | 07:53.02 |
| chrisl | Oh? So Freetype is doing *something* with the MM data then? | 08:02.00 |
| kens | It seems to be, yes. | 08:02.08 |
| | I have a hand-crafted test file using AdobeSansMM and the results using FAPI are basically the same as Acrobat. | 08:02.31 |
| | 2 different instances, and the results are OK | 08:02.44 |
| chrisl | So the job you had that looked wrong was an aberration? | 08:02.57 |
| kens | Well, that one is test-setweigthvector, and to be perfectly honest I'm not sure what the *right* answer is anyway | 08:03.18 |
| | I may re-test it, but I'm not going to worry about that one, its a hacked about job (by Igor), so its not clear its a reasonable test | 08:03.44 |
| chrisl | Okay, well I shall move on - if you stumble on another problem, let me know. | 08:03.53 |
| kens | I will, but it all looks OK at the moment | 08:04.04 |
| chrisl | Is that job using a modified $Blend procedure or something? | 08:04.46 |
| kens | I don't think so, but its hard to tell | 08:05.00 |
| chrisl | Well, if there others are okay, yes, let's not worry about it, unless something else pops up. | 08:05.31 |
| kens | All the Adobe jobs supply their own makeblendedfont which is onl;y used if there is no existing definition of makeblendedfont, and teh Adobe definition redefines $Blend. | 08:05.36 |
| | Several different ways under conditions that I haven#'t bothered to investigate | 08:06.05 |
| | My current code *nearly* works. I have a capital I that comes out looking like someone has sat on it. | 08:06.31 |
| | But otherwise OK. | 08:06.39 |
| chrisl | Sounds good. Shame it's been such a pain...... | 08:07.07 |
| kens | Yeah, its just slow going. Its hard to figure out what the number ought to be, which makes it hard to work out what is wrong. | 08:07.35 |
| | Plus the exciting use of othersubrs which has to be corrected | 08:07.48 |
| Robin_Watts_ | Morning mvrhel2. | 13:57.39 |
| kens | chrisl ? | 14:08.29 |
| | ping ? | 14:08.31 |
| chrisl | kens: Yo! | 14:17.28 |
| kens | chrisl I think that report from Jasper Neuman is a FreeType thing | 14:18.09 |
| chrisl | Probably is, yes. | 14:18.23 |
| kens | OK as long as you | 14:20.03 |
| chrisl | I'm not going to look at it until marcosw_ has done his thing. | 14:21.24 |
| kens | Fair enough :-) | 14:21.34 |
| | Hmmm that should have said as long as you know... | 14:21.52 |
| chrisl | I assumed as much.... | 14:22.08 |
| kens | :-) Doorbell went and I rushed it | 14:22.18 |
| mvrhel2 | good morning | 14:23.53 |
| | bbiab have to help make the kids some breakfast | 14:24.19 |
| henrys | mvrhel2 is early he loves this rop stuff so much he can't stay away ;-) | 14:59.04 |
| Robin_Watts_ | He's got a power lunch with Mq today. Probably wants to work up an appetite. | 15:00.01 |
| henrys | right now I see simple text with plank has non black contributions. you can run pcl with a plane text file to see it. | 15:05.48 |
| | plain | 15:05.52 |
| | actually I think that is true for any cmyk device. | 15:07.03 |
| Robin_Watts_ | henrys: Yes. That's down to halftoning. | 15:10.14 |
| | Oh, sorry, if the text is black, then the halftone should be K only, I guess. | 15:10.45 |
| henrys | kens so you were saying global got away with calling the fonts by their trademark names on the status page and such? Monotype came after one of our customers for doing that but now I've discovered they only own a few of the trademarks. | 15:10.52 |
| kens | henrys I'm not sure about calling the fonts that way. | 15:11.20 |
| | They fonts have the Stream names, but are aliased with the copyrighted names. | 15:11.34 |
| henrys | there shouldn't be halftoning at all should go to copy mono and be treated as a bit mask right? | 15:11.39 |
| Robin_Watts_ | henrys: presumably. | 15:11.50 |
| mvrhel2 | Robin_Watts: thanks for the email about where MQ left off with you. I will get him moving again. | 15:34.29 |
| | henrys: are the text fills coming from an RGB color space fill or a gray color space fill? | 15:35.31 |
| | if they are a gray color space fill, they should by default be done as K only when going to CMYK device | 15:35.52 |
| | we fixed that in 9.04 | 15:36.09 |
| | at least for PDF and PS.... | 15:36.18 |
| | but it should work in PCL too | 15:36.25 |
| | as it is part of the graphics library | 15:36.32 |
| | now if the fill were RGB, then it will end up being composite black from the profile | 15:36.49 |
| | does PCL have a gray color space? | 15:37.11 |
| ray_laptop | mvrhel2: I saw the comment on 692339. I guess we never ran across the 'strip' form of halftone at CalComp. Not sure why we didn't | 15:42.31 |
| mvrhel2 | Yes. I was wondering what was going on with the order had a height of 1 and a width of 905 | 15:43.47 |
| henrys | mvrhel2:I'll check that. | 15:44.00 |
| mvrhel2 | makes for an interesting threshold array | 15:44.05 |
| henrys | mvrhel2:I mean I'll check if we are doing setgray for text I thought we were. | 15:45.55 |
| mvrhel2 | yes | 15:47.47 |
| kens | Night all | 16:09.55 |
| ray_laptop | Robin_Watts_: I responded to your email question about 'colors_used' | 16:22.56 |
| | Robin_Watts_: basically, I think the hooks are there, but it was never finished. IIRC this was something Stefan had worked on | 16:23.51 |
| henrys | hmm if it is just mono it will go through copy_mono. Why do you need help from the clist? | 16:26.54 |
| Robin_Watts_ | henrys: this is in regard to 'render mono only files as mono only' ? | 16:27.41 |
| henrys | the mono files the customer sent are intended to be sent to the printer when it is in a monochrome mode. The customer will set a mono device before sending those files. | 16:29.59 |
| marcosw_ | henrys and ray_laptop: support meeting today? | 16:30.23 |
| Robin_Watts_ | That pdf implied to me that they spot that there is no color information in the file, and therefore know to use a mono device. | 16:30.26 |
| | rather than the driver setting the appropriate device before sending the file. | 16:31.35 |
| | but I'll be the first to admit I don't understand PCL. | 16:31.47 |
| henrys | marcosw_:whatever you want to do. | 16:32.12 |
| | I take that to be marketing hype. We clue into the color space right? if we do setgray it goes to K else it goes to rgb | 16:35.28 |
| Robin_Watts_ | henrys: I thought the key invention they were touting was that they only bother carrying the CMY planes around if they are actually used. | 16:37.06 |
| henrys | it isn't a pdf you don't have access to the entire page, so you think they can switch the device color model on the fly at any time. I think that would be difficult in our architecture. | 16:39.47 |
| Robin_Watts_ | henrys: Hence my suggestion about the clist. | 16:40.22 |
| | If you can spot "color or not" in the clist writing phase, then we could maybe do the clist reading phase to a different target? | 16:41.04 |
| | But possibly (probably) not. | 16:41.21 |
| mvrhel2 | have to reboot. back shortly | 16:42.10 |
| henrys | marcosw_:did you want a meeting? | 16:42.46 |
| Robin_Watts_ | (I bet the clist writing pickles stuff into the clist in different ways according to if it's a cmyk or just a k device) | 16:42.49 |
| marcosw_ | no, I think we're good. | 16:43.04 |
| henrys | marcosw_:we got all excited about getting the bugs to zero at the meeting and now 10 new ones. | 16:43.36 |
| | ray_laptop:anything for the meeting? | 16:43.56 |
| marcosw_ | there was that large batch of XPS issues. | 16:44.14 |
| henrys | Robin_Watts:one of my concerns is while we've been working on this I think the requirements have changed I see 1200 dpi and 2 bpp now on their latest models. So we may have to do some serious performance improvements of which your idea might be one of the needed changes. | 16:49.52 |
| Robin_Watts_ | OK. lj5200_pcl6_mono_PWTW51DC.prn 600dpi, no banding plank used to take 58seconds. | 17:07.09 |
| | Now takes 22. | 17:07.13 |
| ray_laptop | Robin_Watts_: the colors get pickled into the clist as (compressed) color_index values, so you can't change the target 'depth' without confusing it. | 17:10.14 |
| Robin_Watts_ | OK, so we'd need to do something where we 'lazily' initialise the CMY planes if required. | 17:10.46 |
| ray_laptop | Robin_Watts_: but there is nothing that says the target device has to actually have a buffer | 17:11.07 |
| | Robin_Watts_: a memory (buffer) device can be smart about allocating planes it actually needs to paint into | 17:11.48 |
| Robin_Watts_ | ray_laptop: It's not actually the allocation that takes the time. | 17:12.09 |
| | We could allocate (and even blank them). | 17:12.24 |
| | But if we knew that no painting operation had actually marked the C,M,Y planes, we could be cleverer about rops. | 17:12.49 |
| ray_laptop | The cust 532 device doesn't even have ANY buffers -- it paints using ASIC instructions that "magically" get printed somwhow | 17:12.50 |
| henrys | mvrhel2:I see so pclxl is okay it uses the gray color space and text is fine. pcl uses a 2 entry indexed space for text and that does not work - is that a special case you want to handle in the graphics library or should I change pcl to detect that palette and do setgray? | 17:13.28 |
| mvrhel2 | henrys: oh interesting. | 17:14.00 |
| | grumble grumble. two entry index space... | 17:14.17 |
| ray_laptop | Robin_Watts_: IF the 'colors_used' worked correctly, you would know that CMY had not been marked for that band | 17:14.28 |
| henrys | you can see this running any simple text through pcl. | 17:14.37 |
| mvrhel2 | henrys: a color space like that really should be converted to gray (assuming the entries are black and white and not inverted) | 17:16.05 |
| | I am torn on where that should be handled | 17:16.28 |
| ray_laptop | Robin_Watts_: a 'smart' device could also keep track of that info for a buffer (band?) with whatever granularity is desired (down to individual pixel). This device could change the treatment for an area only after that area had CMY painted | 17:17.04 |
| henrys | well if comes up in the other languages it should be in the library otherwise pcl. | 17:17.06 |
| mvrhel2 | I have not seen that in pdf/ps, but it could occur | 17:17.23 |
| | I will go ahead and make the optimization in the library. do you have a test file that I can use? | 17:17.50 |
| ray_laptop | using a two color indexed space for gray seems bonkers to me (just MHO) | 17:18.45 |
| henrys | thinking about it we should create a ps/pdf example and see what adobe does | 17:18.51 |
| mvrhel2 | oh good point | 17:19.04 |
| | they do treat gray -> to K but I wonder if it is indexed what they do | 17:19.22 |
| | well, I think if the base space is gray, they probably still go to K | 17:19.47 |
| | actually we should do that too | 17:19.52 |
| ray_laptop | it's easy enough for an indexed color palette to be checked to see if it is really just gray | 17:19.53 |
| Robin_Watts_ | marcosw_: You still here? | 17:19.55 |
| marcosw_ | yes. | 17:20.04 |
| mvrhel2 | is the base space for the indexed space gray henrys? | 17:20.09 |
| | or is it RGB? | 17:20.22 |
| | with a white and black entry | 17:20.32 |
| Robin_Watts_ | You sent out pcl timings for pamcmyk4 vs plank with michaels fast halftoning stuff enabled. | 17:20.43 |
| henrys | ray_laptop:all pcl colors are indexed with one exception for contone raster so it sort of makes sense. | 17:20.50 |
| ray_laptop | even if it is RGB we can scan the palette (once) and make it into gray | 17:20.56 |
| henrys | mvrhel2:rgb | 17:21.00 |
| mvrhel2 | ok. I am certain PDF/PS will treat that not to go to K | 17:21.13 |
| Robin_Watts_ | Did you ever send out timings for gs pamcmyk4 vs plank without that code enabled ? | 17:21.14 |
| mvrhel2 | if we want PCL to treat that to go to K, it should be handled in the interpreter | 17:21.40 |
| marcosw_ | about 8 minutes ago | 17:21.45 |
| Robin_Watts_ | marcosw_: Ah, thanks. | 17:21.53 |
| mvrhel2 | to replace the index space with a gray space | 17:21.55 |
| henrys | okay will do. | 17:22.18 |
| Robin_Watts_ | Could I trouble you for a new run of the pcl pamcmyk4 vs plank without the fast halftoning please? | 17:22.22 |
| marcosw_ | sure, running it now. | 17:26.48 |
| Robin_Watts_ | Thanks. | 17:27.02 |
| | plank now outperforms pamcmyk4 on that file, just | 17:58.10 |
| henrys | Robin_Watts:nice speedup Robin_Watts! | 18:00.44 |
| Robin_Watts_ | The gs figures are disapointing through. | 18:01.21 |
| | We are between the same, and 4 times slower. | 18:01.59 |
| | In the slowest of the files (tests_private/comparefiles/knight.pdf) 77% of the cpu time is spent in mem_planar_copy_color_4to1 | 18:06.28 |
| cryptopsy | kens: it has been running for 24 hours now | 18:11.48 |
| | surely there must be a gcc option to quit a program when it spend so long on a loop or if statement | 18:12.28 |
| | < cryptopsy> im convert a doc that's taking too long, about 1 hour for a ps2pdf conversion | 18:12.56 |
| | now at 12+ hours, and constantly at 50% usage | 18:13.06 |
| | everything is in a tmpfs so it's not hard-drive IO the bottleneck | 18:13.20 |
| Robin_Watts_ | cryptopsy: How would you implement such an operation? | 18:13.28 |
| cryptopsy | have it time every statement in the lang | 18:14.02 |
| Robin_Watts_ | Would you build timing into ALL your code on the offchance that some of it might go wrong? You'd take a huge penalty for something that should never help! | 18:14.15 |
| cryptopsy | its a debug step | 18:14.28 |
| | you don't build it in all your programs in hope that something will go wrong in a year | 18:14.46 |
| Robin_Watts_ | cryptopsy: Better to run under a profiler and look where the time is spent. | 18:14.46 |
| | Or to run under a debugger, and pause the code. | 18:15.04 |
| cryptopsy | yes | 18:15.04 |
| | valgrind | 18:15.07 |
| Robin_Watts_ | Valgrind would not be my tool of choice. | 18:15.22 |
| cryptopsy | maybe ps should put in timers where they suspect things can freeze this way, i've seen this before | 18:15.30 |
| Robin_Watts_ | ps ? | 18:15.40 |
| cryptopsy | gs* | 18:15.42 |
| | but then i supose that noticing it not progress after 12+ hours of run time conveys the message, i still rather not wait that long | 18:16.28 |
| | i guess this is a new requirement for source based distros | 18:16.46 |
| | our CPU time is precious | 18:16.56 |
| | kens said if the input file is pdf -dPDFDEBUG may help, but i'm using ps2pdf | 18:17.32 |
| Robin_Watts_ | mvrhel2: You gone to lunch yet ? | 18:24.40 |
| mvrhel2 | leaving in a couple minutes | 18:35.51 |
| | Robin_Watts: just printed your email | 18:36.17 |
| Robin_Watts_ | I was going to ask you to hae a quick look at a routine to see if you thought SSE could speed it up. | 18:36.43 |
| | but don't worry if you're about to leave. | 18:36.53 |
| | I'll ponder on it a bit more. | 18:36.58 |
| mvrhel2 | ok. if you want, send me an email and I can glance at it when I retrun | 18:37.11 |
| | or post a link on IRC | 18:37.15 |
| Robin_Watts_ | Thanks. | 18:37.17 |
| tkamppeter | I have got three crash bugs on GS 9.04: https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/842411, https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/842435, https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/853918 | 20:00.20 |
| | They look very similar and are triggered by more or lees the same GS command line: CUPS Raster with 600x300 dpi and RGBW color space (for HP inkjets). | 20:01.31 |
| kens | Do we have GS Bugzilla reports ? | 20:01.56 |
| tkamppeter | Perhaps these three bugs are one bug in reality. | 20:02.04 |
| | kens, no, I am still waiting for the users to supply input files. | 20:02.28 |
| kens | Ah, OK. No problem. It does sound suspiciously liek the same problem | 20:02.45 |
| tkamppeter | kens, but the Launchpad reports all contain symbolic stack traces. | 20:02.57 |
| kens | I'm afraid that probably won't mean anything to me, but its probably not my field anyway, sound more like Michael | 20:04.22 |
| tkamppeter | kens, now I succeeded to get a segfault, but do not know yet which of the three bugs. I will submit it now to Launchpad, so that it gets associated with one of the three bug reports. | 20:05.19 |
| kens | OK. | 20:07.07 |
| tkamppeter | kens, I have submitted the bug report, it is https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/856766 | 20:17.39 |
| kens | OK tkamppeter, thanks | 20:17.52 |
| tkamppeter | It tells to have crashed at another place than the other three. Seems to be the same problem though. Will add the info to reproduce. | 20:18.27 |
| kens | It may be the smae thing, but manifesting slightly differently | 20:18.50 |
| tkamppeter | kens, input file and command line added. | 20:26.33 |
| kens | We'll really need a GS bug report | 20:26.48 |
| tkamppeter | kens, reported it also as http://bugs.ghostscript.com/show_bug.cgi?id=692532, to have it on your TODO list. | 20:37.02 |
| kens | Well, someone's :-) | 20:37.21 |
| | crashes get peiority | 20:37.36 |
| | priority | 20:38.46 |
| henrys | show args | 22:16.53 |
| | ignore that | 22:17.21 |
| Robin_Watts_ | I think I just doubled the speed of the slowest plank result under gs (rewrote the copy_color) | 23:53.56 |
| | Will commit in the morning if it tests out ok. | 23:54.15 |
| | Forward 1 day (to 2011/09/23)>>> | |
IRC Logs