| | <<<Back 1 day (to 2014/10/07) | 2014/10/08 |
| chrisl | kens: in 695577, is the cross-hatching drawn as a type 1 pattern? | 07:35.51 |
| kens | chrisl not sure yet, I'm still waiting for Bugzilla to deliver the file | 07:36.09 |
| chrisl | Is bugzilla slow, or the file big? | 07:36.30 |
| kens | Bugzilla is often slow for me, the file is 750k or so | 07:36.43 |
| | I do a have a copy already, but its on my laptop, I was hoping downloading ti would be faster than booting it ujp | 07:37.13 |
| | ha retried the download and its done.... | 07:37.47 |
| | As usual its an immesne media size | 07:38.03 |
| chrisl | Hmm, from the screenshot, it doesn't *look* like the issue I was thinking about - cust 532 stumbled over a tiling issue ages ago | 07:38.12 |
| kens | I'm *very* doubtful its anything to do with the PDF interpreter, it sounds more like clist to me | 07:38.45 |
| chrisl | Could be - like I say, from the description it sounded like it might be a tiling problem | 07:39.41 |
| kens | Well its possible, its going to take quite a long time to investigate in any event. It would be a lot easier if they would get their customer to make up a simpler test file :-( | 07:40.27 |
| | Oh and the decompressed file is 45Mb | 07:40.53 |
| chrisl | I guess you could try the customer's resolution and set a large enough frame buffer to render without the clist | 07:41.03 |
| kens | I was going to try the opposite, try a lower resolution with clist | 07:41.23 |
| | Because a 36x33 inch page at 300 dpi uses a lot of memory | 07:41.35 |
| | Hmm, what's the magic runes to force clist mode ? | 07:43.50 |
| chrisl | Erm...... | 07:44.03 |
| kens | Oh, it is -dMaxBitmap | 07:44.42 |
| | and if I use that at 100 dpi the result is correct | 07:44.55 |
| | So it seems like its not a clist problem | 07:45.22 |
| chrisl | Oh, "test.pdf" - really?? I find that irrationally annoying | 07:46.29 |
| kens | Everyone calls their files that. Whats annoying is that it can't have been called that originally, or if they made a special test one, they oculd have reduced the complexity | 07:47.03 |
| chrisl | I know. I just wonder how it doesn't occur to people that we might get a lot of files called "test.pdf"..... | 07:48.07 |
| kens | Well, I tried pushing the maxbitmap up to 120Mb and its still incorrect. | 07:48.41 |
| chrisl | If it's drawn with a pattern, it could be a clist pattern issue | 07:49.25 |
| | Or even a pattern clist problem | 07:49.36 |
| kens | pattern clist is a possibility | 07:49.46 |
| chrisl | So you could bump up the value of MaxPatternBitmap | 07:50.42 |
| kens | Good point, I hadn't thought of that | 07:50.59 |
| | Hmm current default is 8Mb (!) | 07:51.52 |
| chrisl | Well, I *would* expect that would enough, but..... | 07:52.32 |
| kens | I just bumped it to 32Mb, I'm trying again | 07:52.50 |
| | Still wrong | 07:53.17 |
| | OK time to start laboriously hacking it down | 07:53.43 |
| | Annoyingly marcos is correct, if I remove anything from the page using Acrobat, teh problem disappears | 07:55.37 |
| | So first I have to hand edit a 45Mb PDF file. | 07:55.51 |
| chrisl | Hopefully in a file of that size, you might be looking at image data, or forms etc | 07:56.26 |
| kens | I don't immediately see any images, there's a lot of vector data (its an architect's drawing) | 07:56.58 |
| | This is going to take some time | 07:57.11 |
| chrisl | Oh, they sometimes use image masks...... | 07:57.21 |
| kens | Hmm, it has optional content | 07:58.07 |
| | and a ton of marked content | 07:58.20 |
| | The page content stream is 45076441 bytes in length..... | 07:58.58 |
| | Yep, it really does contain 45Mb of vector data | 08:00.06 |
| | and no patterns | 08:00.21 |
| | OK hand editing works, guess I have a long slow job ahead | 08:05.42 |
| chrisl | Strangely, 400dpi works...... | 08:19.28 |
| | And 600dpi is wrong | 08:23.49 |
| kens | suspects a matrix problem | 08:30.57 |
| t4nk667 | hey all, i am extracting jpegs out of a pdf and getting the following warnings: WARNING in tgt_create tree->numnodes == 0, no tree created. WARNING: No incltree created. WARNING in tgt_create tree->numnodes == 0, no tree created. WARNING: No imsbtree created. | 14:15.28 |
| | is this a bug in openjpeg? | 14:15.40 |
| | is there any workaround? i've been sitting on this issue all day | 14:16.15 |
| kens | Which appplication are you using, GS or MuPDF ? How are you 'extracting JPegs' ? Does the PDF file give an error when rendered with the relevant application ? | 14:16.42 |
| henrys | kens:what exactly is left to be done for color management? I'm writing the newsletter. | 14:17.13 |
| kens | henrys lots of stuff, just a moment | 14:17.24 |
| | Bug 695302 is my tracker for this | 14:17.43 |
| rayjj | t4nk667: and what version of the app? | 14:17.45 |
| kens | need to handle images > 8 bpc, convert ICCBased spaces to CIE spaeces for ps2write, alter transparency belding group colour spacfes | 14:18.27 |
| | blending* | 14:18.40 |
| | Oh and finally get PCL->PDF/A working | 14:18.57 |
| rayjj | t4nk667: if you are using an older version of the mupdf tools (mutool extract ...) as I expect, then it might be using an old openjpeg | 14:18.59 |
| henrys | kens:it sounded like PDF/A-1 part of the bug might be fixed? | 14:19.49 |
| kens | henrys yes, the ICC v2 profiles is done | 14:20.02 |
| t4nk667 | i'm using 9.15 on os x 10.9.5 | 14:20.28 |
| kens | Michael found he needed that for XPS as well, os it was handy to have it already completed | 14:20.29 |
| | t4nk667 : so you are using Ghostscript ? | 14:20.43 |
| t4nk667 | yes | 14:20.48 |
| kens | Right so to continue with my questions; how are you 'extracting JPegs' using Ghostscript ? | 14:21.12 |
| t4nk667 | gs -dSAFER -dBATCH -dNOPAUSE -r200x200 -sDEVICE=jpeg -dTextAlphaBits=4 -dLastPage=1000 -sOutputFile= | 14:21.13 |
| kens | THat isn't 'extracting JPegs' that's rendering the PDF file to a JPEG output | 14:21.29 |
| henrys | kens:that bug title spelling is not proper is it? ;-) | 14:21.52 |
| kens | Works for me :-) | 14:22.03 |
| chrisl | "Improvemensts"? | 14:22.24 |
| kens | t4nk667 : if the input PDF contains a JPEG, then rendering to JPEG will introduce nasty artefacts | 14:22.27 |
| | chrisl, Still works for me :-) | 14:22.38 |
| | If someone is bothered they can edit it | 14:22.47 |
| | *I* know what it means, and its my bug..... | 14:22.59 |
| | t4nk667 : We do already have at least onebug open which is 'similar' to what you are reporting, but we cannot possibly comment without seeing the file in question. | 14:23.49 |
| t4nk667 | is there any way for me to upload the file? | 14:24.24 |
| kens | Yes, open a bug report | 14:24.31 |
| | Attach the file to the report | 14:24.40 |
| | Does anyone remember where the Luratech library is ? If so can you email me the location please ? | 14:25.21 |
| | I was going to see if it would handle the JPEG from the bug henrys made bountiable the other day, Shelly was asking me about it | 14:25.53 |
| t4nk667 | will do, thanks a lot | 14:26.49 |
| chrisl | kens: this new subversion repo format makes it hard to find the location :-( | 14:27.24 |
| kens | Oh, that's unfortunate. I could install Tortoise Suversion again I guess | 14:27.45 |
| chrisl | It's somewhere in svn-private - oh, give me sec.... | 14:28.47 |
| kens | On casper ? | 14:28.59 |
| | ah, svn-private/luratech | 14:29.27 |
| | Oh, or not..... | 14:29.37 |
| chrisl | Yeh, svn-private/luratech/trunk | 14:30.17 |
| kens | I don't see a trunkn directory in there, on casper | 14:30.33 |
| | conf, dav, db, hooks, locks | 14:30.50 |
| chrisl | That's a bare repo, not a working copy | 14:31.02 |
| kens | So where are you looking ? | 14:31.16 |
| kens | checks peeves | 14:31.56 |
| | Hmm no svn-private on peeves | 14:32.11 |
| henrys | should be trunk ldf_jb2 and another they have weird names | 14:33.52 |
| | svn ls svn+ssh://svn.ghostscript.com/var/lib/svn-private/luratech/trunk/lwf_jp2 | 14:47.38 |
| kens | Yes, but that needs a copy of svn installed first :-) | 14:48.03 |
| kens | has a copy by alternative means now though | 14:48.18 |
| henrys | can't be much work to get these things into git. That would really be best. | 14:48.54 |
| chrisl | henrys: you can't (easily) do partial checkouts in git | 14:50.01 |
| henrys | well ufst and luratech can have separate repos. Your concern is test files chrisl ? | 14:51.39 |
| chrisl | henrys: I thought the repository was at the svn-private level | 14:52.17 |
| jogux | iirc, it's easy enough to convert an svn repos into multiple git ones. | 14:53.11 |
| chrisl | There's really no reason not to have one or more private git repos, AFAIK | 14:53.16 |
| jogux | certainly that's what we did wiith the picsel cvs :-) | 14:53.18 |
| henrys | chrisl: it is I'm assuming we'd break that apart ... is there some reason other than "private" those things are grouped together. We know the ufst is a private so I don't think it adds a lot | 14:53.33 |
| chrisl | henrys: I certainly don't have any objection to svn-private being purely for test files | 14:54.31 |
| henrys | chrisl: having cluster machines in my house I don't worry about test files I just run them from marcos cluster directory as needed. | 14:55.41 |
| kens | Hmm, internal library error -71, I wonder what that means :-) | 14:55.45 |
| henrys | kens: better than 42 | 14:56.08 |
| kens | Now I need a working jp2 file to see if I have a working demo or not.... | 14:56.28 |
| henrys | chrisl: I'll make a bug or add it to the agenda... low priority. | 14:56.41 |
| | I was hoping norbert would check in to see if my patch helped him at all. | 14:57.26 |
| chrisl | henrys: it'll probably need tor8's attention - he's most adept at that kind of repo wrangling | 14:58.09 |
| henrys | chrisl: we never need the history for ufst and luratech but I guess it would be good to have. | 14:59.00 |
| chrisl | henrys: we kind of do need the history, as we maintain our own patches for both | 14:59.27 |
| henrys | chrisl: ah yes the dreaded patches | 15:00.01 |
| chrisl | henrys: I was a little bemused by your pcl dictionary change: I was seeing the two versions spending different amounts of time in the dictionary lookup function. | 15:00.33 |
| henrys | chrisl: yea we could chase that down but spending the bulk of time in searching is the big problem. | 15:01.58 |
| chrisl | henrys: I just wonder why we appear to creating more entries in later versions | 15:02.38 |
| henrys | chrisl: I didn't notice that are you sure? | 15:03.30 |
| chrisl | henrys: well, I am assuming that more time spend looking up entries indicates more entries to be searched...... | 15:04.16 |
| henrys | chrisl: the pcl id's for the macros go up into the 1000's so I don't see how we wouldn't create a ridiculours number of entries. | 15:04.34 |
| chrisl | henrys: I found HEAD was spending 55 seconds longer doing the dictionary lookups than 9.10 | 15:05.25 |
| | No, 45 seconds longer, sorry | 15:05.46 |
| henrys | chrisl: okay I'll have another look but the pcl file itself would demand the list to have as many entries as there are id's ... I just assumed we were scanning through dictionary an extra time someplace in the new code. | 15:07.48 |
| chrisl | henrys: fair enough - as I said, I only poked it long enough to see it wasn't my problem! | 15:08.56 |
| tor8 | henrys: chrisl: I have already (several years ago) converted the svn-private repos for ufst and luratech into git... | 15:09.00 |
| henrys | my patch is faster becasue we do the linear search only once ... | 15:09.03 |
| | when deleting | 15:09.11 |
| tor8 | but I don't remember where I stowed my scripts | 15:09.11 |
| kens | henrys, the file in 695533 I was talking to shelly about. I tried 2 different JPEG2000 decoders on the file that OpenJPEG complains about, and they also threw errors. I'm inclined to say that the file doesn't work because the image is broken. | 15:09.34 |
| henrys | chrisl: but he's redone all this with binary trees so I doubt it's going to be worth anything from him. | 15:09.37 |
| | s/from/for | 15:09.46 |
| Robin_Watts | henrys: Have you considered splay trees? | 15:10.40 |
| henrys | miles agreed to skip the newsletter but now has changed his mind, so I'm trying to fluff up what we have. | 15:11.34 |
| Robin_Watts | The post lookup rotations result in recent additions being close to the root. | 15:12.14 |
| henrys | Robin_Watts: splay trees would work. The thing is if these dictionaries are getting longer than 30 or so entries the driver writer is at fault. It's very rare to see something like norbert has dropped on us. | 15:12.49 |
| chrisl | Robin_Watts: if lookup times were *that* critical, then hashing and a sparse array is probably a better bet | 15:13.26 |
| Robin_Watts | Right. The nice thing about splay trees is that the 'forgotten' ones fall to the bottom of the trees and don't affect the average lookup time. | 15:13.35 |
| henrys | what norbert did is quite reasonable also, the binary tree we should probably just integrate his code. | 15:14.18 |
| Robin_Watts | chrisl: yes, though you'd have to rebuild the hash table when it got full. | 15:14.43 |
| henrys | kens: did you check adobe? | 15:28.57 |
| kens | Acrobat opens it and renders it. Possibly (Chris's suggestion) the image has multiple resolution levels and Acrobat only uses up to the one it needs (low res) or stops and uses the last one when it encounters an error. Maybe, perhaps...... | 15:30.00 |
| henrys | kens: apple preview is slow but okay also | 15:31.46 |
| kens | Again that will be low res I expect | 15:32.05 |
| | Luratech, OpenJPEG and another viewer all throw errors for me | 15:32.34 |
| henrys | kens: but in acrobat you can render it as 600 dpi tiff or something right? | 15:32.48 |
| | or you tried that and it doesn't work? | 15:33.01 |
| kens | COuld do, I haven't tried that. And as I said, it may simply stop when it gets an error and use the last working resolution | 15:33.13 |
| | I'm inclined to leave it with Shelly to see why OpenJPEG throws an error. I could work on it, but he's more up to speed on OpenJPEG than me | 15:33.45 |
| henrys | kens: I got image too wide to output writing 300 dpi tiff from acrobat | 15:36.05 |
| kens | Oh yes, Acrobat does that, its a *massive* page size | 15:36.23 |
| | 140x100 inches | 15:37.03 |
| henrys | kens: oh this isn't a bug at all why are we talking about it, why isn't it closed? I didn't see it worked in the latest | 15:44.29 |
| kens | It doesn't 'crash' in the current code | 15:44.41 |
| | But the output doesn't match Acrobat. I assumed that's why you made it bountiable for SHelly to look at | 15:45.04 |
| henrys | kens: oh he said in comment 2 it renders fine, so that info is wrong then? | 15:45.41 |
| kens | Well it certainly doesn' render correctly for me, have ago yourself, maybe its OK on Mac or Linux | 15:46.07 |
| | Looks like I may have made an error ripping out the image | 15:51.05 |
| | Luratech decodes it, but its 100% black, I wonder if its supposed to be :-) | 15:51.39 |
| | Ah no that was the other decoder, Luratech gets it right,so it looks like htere is an OpenJPEG bug there | 15:52.11 |
| | It won't affect commercial customers of course, since Luratech gets it right. | 15:52.36 |
| | The tiff file comes out at 1.1 Gb, so its ahrdly surprising its slow..... | 15:53.06 |
| kens | goes back to reducing monstrous files. | 15:54.39 |
| | OK I@moff, night all | 16:05.29 |
| henrys_ | wedges his mac with that damn file... | 16:10.27 |
| henrys | oh it's back from swap hell | 16:10.49 |
| | tor8: how is the awk stuff coming? | 16:19.01 |
| mvrhel_laptop | henrys: quick question for you | 16:35.06 |
| henrys | yup | 16:35.19 |
| mvrhel_laptop | The document that our website references here http://www.artifex.com/files/Ghostscript_Color_Architecture.pdf is way out of date. Where is this thing hosted so I can drop in the proper one | 16:35.44 |
| | or who can do that. I am guessing I dont have the proper login | 16:36.19 |
| henrys | mvrhel_laptop: I thought ray had the keys to that | 16:36.36 |
| | rayjj? | 16:36.45 |
| | mvrhel_laptop: you can also just send it to ron I suppose. | 16:37.04 |
| chrisl | henrys: artifex.com should be on the goddady host now, but, IIRC, it's a managed site. | 16:37.23 |
| henrys | mvrhel_laptop: I'll handle it with ron - what's in the gs tree is good right? | 16:38.04 |
| mvrhel_laptop | yes. henrys. thanks! | 16:38.16 |
| henrys | mvrhel_laptop: sure | 16:38.24 |
| chrisl | henrys: here where I'd got messing with the revised ghostscript.com : http://www.ghostscript.com/~chrisl/ghostscript.com/ | 16:38.40 |
| henrys | chrisl: well I guess if you aren't far off it isn't worth tor8 fooling with the awki business... | 16:41.30 |
| chrisl | henrys: I just keep chipping at it when I have a moment. | 16:42.07 |
| rayjj | henrys: sorry -- I'm here. | 16:42.12 |
| henrys | chrisl: it seems like everytime I look at the original site I find something wrong or slightly off at least... | 16:43.20 |
| rayjj | miles has the info to upload files I thought. I just have the DNS info -- not sure where artifex.com is actually hosted | 16:43.30 |
| henrys | rayjj: right I'm sending it on to miles and ron | 16:43.50 |
| | rayjj: thanks | 16:43.54 |
| rayjj | henrys: OK | 16:43.58 |
| chrisl | henrys: well, I can only fix stuff on the website if I know it's wrong..... | 16:44.23 |
| henrys | well the documentation archive for example why those releases? where are the others? | 16:45.34 |
| chrisl | henrys: there's every release there since I took over | 16:46.16 |
| | TBH, I don't see why we should have more than maybe four releases listed there | 16:46.55 |
| henrys | chrisl: oh I forgot we skipped more than I thought. | 16:47.18 |
| chrisl | How many people are likely to need quick access to the docs for GNU Ghostscript 3.33 ?? | 16:48.12 |
| Robin_Watts | artifex.com is hosted on the godaddy hosting, I believe. | 16:48.29 |
| | chrisl: centos users. | 16:48.40 |
| | :) | 16:48.42 |
| henrys | chrisl: I would say we don't want documentation for any release we aren't willing to support | 16:48.50 |
| chrisl | Robin_Watts: those aren't users I want to help ;-) | 16:49.06 |
| | henrys: I can easily zip the older ones | 16:49.45 |
| henrys | I need to finish this newsletter ugh ...I hate writing inflated nonsense. | 16:51.05 |
| norbertj | henrys: I'm at home, but I checked in at work and retested: HEAD-1 = 85.854sec, HEAD=68.768sec, so already a big improvement. | 16:53.00 |
| henrys | chrisl: I would just get rid of a lot of this stuff. The AFPL and GNU 7.07 in releases.html can be taken out. | 16:53.01 |
| Robin_Watts | henrys: Are you collecting inflated nonsense for just gs? or mupdf and SOT too? | 16:54.00 |
| henrys | gs and mupdf miles is doing sot | 16:54.26 |
| | norbertj: that suggest your trees are not well balanced. hmm that's on odd thing ot say to someone. | 16:56.00 |
| norbertj | henrys: this is now just the improvement on ghostpdl-standalone. I would have to check how it works out with our integration (that's where we noticed this file perfdrop first). | 16:57.26 |
| Robin_Watts | norbertj, henrys: splay trees! :) | 16:57.54 |
| henrys | norbertj: oh okay that's in line with I saw also. | 16:58.01 |
| | norbertj: crazy pcl file ! | 16:58.17 |
| norbertj | henrys: and in our integration we use also UFST63. I'm waiting for a free buildtree to start integrating ghostpdl-9.15 (which should be a tad better than 9.14). | 16:58.19 |
| | henrys: yes, and I dropped another one (see BUG 695578), It includes a fix that works for me. | 16:59.08 |
| | henrys: our customers produce really weird pcl. | 16:59.39 |
| henrys | norbertj: I'll get to that, thank you. | 16:59.50 |
| norbertj | henrys; old (AS400) application, and probably in fortran, so the guy who made it is long dead. So the customer cannot change it anymore. | 17:00.31 |
| chrisl | norbertj: if they're stuck with 35 year old software, maybe they should expect 35 year old performance! ;-) | 17:01.20 |
| norbertj | henrys: tomorrow I'll backport the macros fix in our 9.14 integration to see if it helps a bit. | 17:01.50 |
| | chrisl: I pinpointed the problem with 695578 by using bisect. And it was a change from me that made the bug visible:( | 17:02.51 |
| chrisl | norbertj: PCL is like that - that's why none of us like it | 17:04.17 |
| norbertj | henrys: I backported the macro-fix to our integration of ghostpdl-9.14 and it went from 14sec to 4.7 sec. (Not the platform we are delivering pcl on, for that I have to wait for the automatic-testresults tomorrow. | 18:11.48 |
| | henrys: have to see then what it does to the other performance testfiles. | 18:12.31 |
| | henrys: and whether there is any regression because of it. | 18:12.45 |
| Diego_ | Anybody listening that can answer a question about antialiasing when rendering a PDF that has gradients and transparency on GhostScript 9.10? | 18:17.56 |
| henrys | Diego_: just ask | 18:36.17 |
| Diego_ | It seems like there is no antialising. Can I send you a sample file? | 18:37.02 |
| | But only when there is transparency or gradients. | 18:37.10 |
| | I actually looked over and found a bug report marked closed about this. | 18:37.22 |
| | Says it was fixed in revision 12341. | 18:37.52 |
| | Back in 2011. | 18:38.32 |
| | Version 9.10 is from 2013. | 18:38.38 |
| | Either the bug persists, or there is something in my file instructing gs not to antialias, or I am missing some command line to enable antialising when transparency is present. | 18:39.20 |
| mvrhel_laptop | whew. expense reports done. now I can do some real work | 18:39.33 |
| henrys | Diego_: if you have something that renders incorrectly compared with adobe reader report a bug at bugs.ghostscript.com | 18:41.20 |
| Robin_Watts | Diego_: What command line are you using? | 18:41.52 |
| Diego_ | 1 sec. | 18:43.06 |
| | gs -dEPSCrop -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -r100 -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -sOutputFile=car.png car.pdf | 18:43.58 |
| | The result has no antialiasing. | 18:45.05 |
| Robin_Watts | Ok, so there are a few reasons why that might not be anrialiasing. | 18:45.11 |
| | We'd expect normal line graphics and text to be antialiased. | 18:45.34 |
| | but sometimes graphics can be done by placing a clip path, and then filling that. | 18:45.57 |
| | clip paths are not antialiased. | 18:46.04 |
| Diego_ | Let me check something on the file. | 18:46.15 |
| Robin_Watts | It's a limitation in gs. | 18:46.21 |
| | If your desire is to render pdf files to pngs, then you may want to consider using mupdf instead. | 18:46.49 |
| | mupdf has a different graphics engine, and a different set of tradeoffs. | 18:47.02 |
| Diego_ | Is there a simple way to check if there are clip paths in a PDF file? | 18:47.06 |
| | I think there aren't any | 18:47.15 |
| | But there is transparency and gradients. | 18:47.30 |
| Robin_Watts | It's designed for screen use rather than printing, and as such does aa natively. | 18:47.33 |
| Diego_ | I know about mupdf. | 18:47.45 |
| | What I am doing is comparing the rendering quality of a bunch of different rendering engines. | 18:47.55 |
| Robin_Watts | I can't give you an easy check, no. | 18:48.12 |
| | Can you open a bug on bugs.ghostscript.com, and attach the file there please? | 18:48.25 |
| Diego_ | http://w3.impa.br/~diego/projects/GanEtAl14/sample.html?car | 18:48.37 |
| Robin_Watts | Then I can look at the file and may be able to give you more information. | 18:48.40 |
| Diego_ | Yes. I'll open a bug report. It's just that there is this bug here | 18:49.17 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=689044 | 18:49.18 |
| | That sounds exactly like what I am experiencing. | 18:49.25 |
| Robin_Watts | I think you'll find that gradients are being drawn using a shading to fill a clippath. | 18:49.45 |
| | oh, that's possible I guess. | 18:50.30 |
| henrys | Diego_: you tried the pdf in that bug report and it doesn't work? | 18:54.15 |
| Diego_ | I don't know what that was supposed to look like. | 18:56.26 |
| | There are a couple icons that look odd. | 18:56.49 |
| | But the text is antialised in that file. | 18:56.55 |
| henrys | Diego_: so your bug is likely different and should have a new reprot | 18:57.21 |
| | s/reprot/report | 18:57.28 |
| Diego_ | mupdf has this "display list" mode that shows the contents of the PDF. | 19:00.40 |
| | It reports exactly what you suggested. | 19:00.49 |
| | That the gradients are being clipped by the shapes. | 19:00.59 |
| | So it's a "feature", I guess. No need to file a bug report. | 19:01.11 |
| | Thanks, guys! | 19:02.32 |
| henrys | yeah! | 19:02.38 |
| Robin_Watts | Diego: Wait... | 19:02.49 |
| | There is an alternative way to do antialiasing in gs, at least for png output. | 19:03.09 |
| | gs -sDEVICE=png16m -o out.png -dDownScaleFactor=3 -r300 in.pdf | 19:03.37 |
| | That will render the png at 300dpi, then shrink it by a factor of 3 in each axis before outputting it. | 19:04.09 |
| | So you'll get antialiasing that way. | 19:04.20 |
| henrys | Diego_: could you go ahead and report a bug anyway just so we have the file. I'd like to see it. | 19:04.44 |
| Robin_Watts | You can use higher or lower DownScaleFactors as required for more or less quality. | 19:04.59 |
| Diego_ | Ah. That 's good to know! | 19:05.38 |
| Robin_Watts | http://w3.impa.br/~diego/projects/GanEtAl14/ looks to have inputs.tgz | 19:05.49 |
| Diego_ | Can I just send you the file? | 19:05.56 |
| | (the inputs.tgz does include that file, but it's a large package) | 19:06.10 |
| | I can put it somewhere for you guys. | 19:06.17 |
| | http://www.impa.br/~diego/car.pdf | 19:07.05 |
| henrys | Diego_: thanks | 19:07.13 |
| Diego_ | I will regenerate the files using this downscale factor thing, but it will take a long time to render. :) | 19:07.46 |
| henrys | bbiab | 19:07.59 |
| Diego_ | Thanks, guys! | 19:13.13 |
| mvrhel_laptop | bbiaw | 21:07.31 |
| | Forward 1 day (to 2014/10/09)>>> | |
IRC Logs