| | <<<Back 1 day (to 2014/09/09) | 2014/09/10 |
| mvrhel_laptop | Robin_Watts: can I go ahead and push the win_desktop merge to golden? | 00:07.28 |
| | it is all as it should be on my repos if you want to check | 00:07.43 |
| | I did the folder rename and fixed a bug and a couple other issues and then did the merge | 00:08.10 |
| | it all went smoothly | 00:08.19 |
| | Robin_Watts is probably in bed I imagine.... | 00:08.31 |
| | off to take care of a couple things around here. bbiab | 00:09.40 |
| Mario__ | Hello Team, just a quick question. Is the clist Ray is talking about on this bug http://bugs.ghostscript.com/show_bug.cgi?id=695459 in the PDF itself or in Ghostscript? | 07:57.18 |
| kens | clist is 'command list', its the Ghostscript implementation of a display list | 07:57.37 |
| Mario__ | OK, thank you | 07:58.26 |
| tor8 | Robin_Watts: "developers" who don't have enough clue to redownload a file when it's obviously been aborted halfway through? *sigh* | 09:39.00 |
| davesleep | 'lo, is anyone using ghostscript 8.70 ? | 09:45.24 |
| tor8 | davesleep: far too many people, considering its age :( | 09:45.48 |
| davesleep | i tried updating on centos and hrm.. i think i have to reinstall imagick aswell | 09:46.07 |
| | has anyone had any problems with it when it's converting fonts.. or using PDFs created on old macs? (i think that's the issue) | 09:47.36 |
| | it converts the font successfully then errors out | 09:47.37 |
| tor8 | apple has had several problems with creating invalid and broken PDF files throughout modern history | 09:48.35 |
| | so you really ought to upgrade to a newer, more fault resistant, version of gs | 09:48.59 |
| davesleep | i can imagine this going horribly wrong. | 09:50.06 |
| tor8 | imagemagick (IIRC) uses the gs command line, not library | 09:50.26 |
| | and it's perfectly possible to install a newer version of gs alongside the old, but making imagemagick pick that up in preference might be trickier | 09:50.55 |
| | but if all you're doing is converting pdf to images, you don't need imagemagick since you can just call gs directly | 09:51.16 |
| davesleep | yeah i am calling it directly, thought it may fix it | 09:52.03 |
| | it works on my windows machine, but not on the server | 09:52.18 |
| | ill need to test again | 09:55.28 |
| | is there a way to limit the width of the pdf converted? | 10:30.49 |
| | for instance.. all GS conversions to png will make pngs 1440px wide | 10:31.21 |
| tkamppeter | I have posted some OpenPrinting projects at the VALS Semester of Code (http://semesterofcode.com/), for getting some students to work on. Under them there are also MuPDF-related projects. Would someone of you be willing to mentor them? | 10:36.47 |
| davesleep | what is dGraphicsAlphaBits ? | 10:51.18 |
| Robin_Watts | davesleep: That's just not true. | 10:54.16 |
| davesleep | what isnt true? | 10:54.36 |
| Robin_Watts | If all your PDFs are on the same size paper (the same size media box), then all conversions to PNG at the same resolution will give the same width. | 10:54.56 |
| | but if you vary the resolution, you'll get different sizes. | 10:55.11 |
| davesleep | aye, i am | 10:55.16 |
| | yeah, i just realised that | 10:55.20 |
| Robin_Watts | tor8: utter fuckwits, yes. | 10:56.15 |
| davesleep | its a pain in the arse to update it | 11:02.33 |
| | i think you gotta uninstall imagick aswell | 11:02.48 |
| | maybe that's only true on windows | 11:02.56 |
| | hrm.. so i tried to update ghostscript and something's gone wrong.. :S | 11:12.26 |
| | the guide im using says it will untar/zip w/e to ghostscript-9.x | 11:17.41 |
| | but mine has untarred to ghostpdl-9.14, is this an incorrect version? | 11:17.56 |
| Robin_Watts | davesleep: No, that's just fine. | 11:18.24 |
| | change into ghostpdf-9.14/gs and build from there. | 11:18.35 |
| | change into ghostpdl-9.14/gs and build from there. | 11:18.42 |
| davesleep | grr permission denied even though im as root and owner | 11:19.15 |
| | brb | 11:19.43 |
| | do i need gcc? | 11:28.57 |
| | k.. that's installed | 11:29.52 |
| | this is why people dont update Robin_Watts XD | 11:29.56 |
| | heh | 11:29.58 |
| Robin_Watts | davesleep: No. It's why people shouldn't use a distribution that uses key packages that are over 4 years old. | 11:32.37 |
| | s/old/out of date/ | 11:32.57 |
| davesleep | easy to say when you know what you're talking about and doing | 11:35.53 |
| chrisl_away | Centos is a PITA, I wish people would stop using it - or at least, understand and accept the implications of using it | 11:35.59 |
| davesleep | but.. i dont | 11:36.02 |
| | bbiab, lunch | 11:36.18 |
| chrisl | every Wednesday someone steals my chrisl nick - it's very annoying..... | 11:39.55 |
| davesleep | you not regged it? | 12:03.28 |
| chrisl | Yeh, which is why I can ghost the other user - but it's still a bit annoying | 12:04.24 |
| tor8 | chrisl: you'd figure the other user would catch on... | 12:04.36 |
| chrisl | tor8: hmmm, I'd hope, but my expectations are quite low these days! | 12:05.25 |
| Robin_Watts | *utter* fuckwits. | 12:06.05 |
| tor8 | Robin_Watts: *nods* | 12:06.36 |
| | Robin_Watts: and I have confirmed that it works for me as well, so it's def not casper | 12:06.59 |
| chrisl | snapshots don't include the git sub-repo thingies | 12:08.06 |
| Robin_Watts | indeed. | 12:08.26 |
| | but they have downloaded snapshots before. | 12:08.39 |
| chrisl | Now you know why kens was so happy to hand them off to you! | 12:09.09 |
| paulgardiner | robin: build is uploaded to casper | 12:17.17 |
| Robin_Watts | paulgardiner: Thanks. | 12:17.43 |
| paulgardiner | np | 12:17.52 |
| kens | catches up on the logs and chuckles evilly | 12:29.52 |
| davesleep | soo i try and go up a version of ghostscript.. try to install latest version of imagemagick.. autoconf is out of date.. and i cant update autoconf for some reason :[ | 13:34.57 |
| | very frsutrating | 13:35.04 |
| henrys | artifex ought to provide download lessons, let me prepare an nre proposal. | 13:35.29 |
| chrisl | davesleep: what do you need autoconf for?? | 13:36.06 |
| davesleep | for imagemagick | 13:36.20 |
| | autoconf ./configure make make install | 13:36.30 |
| | that's what it tell sme to do | 13:36.37 |
| kens2 | henrys : It would probably be cheaper to burn a CD ands send it to them. Plus, we'd get peace and quiet while they waited for teh courier each time. | 13:36.44 |
| davesleep | but centos uses autoconf 2.63 or something | 13:36.46 |
| chrisl | Nope, just ./configure | 13:36.48 |
| davesleep | okay, i'll see how that goes | 13:37.04 |
| chrisl | then make, then make install | 13:37.05 |
| henrys | kens2: put the courier on a slow ship | 13:37.08 |
| kens2 | Send it via pony express..... | 13:37.44 |
| chrisl | Send it on a bunch of 5.25" floppies - that'll flummox them! | 13:38.38 |
| kens2 | It would stump me these days | 13:38.47 |
| | I don't think I have a 5.25 floppy drive any more | 13:38.58 |
| chrisl | Nope, neither do I: but we could legitimately say we'd supplied the update, and since they probably couldn't try it, no new problems! | 13:39.45 |
| kens2 | Mind you, its an interesting idea for complying with the Feds demands for encryption keys | 13:39.52 |
| chrisl | davesleep: where did you download imagemagick from?? | 13:42.09 |
| davesleep | imagemagick.org | 13:42.24 |
| chrisl | The instructions on there don't mention autoconf..... | 13:42.51 |
| davesleep | it;s okay its installing now | 13:42.55 |
| kens2 | Oh good grief. The cursetomer's 'wrapper' is actually a modification to the device..... | 13:48.31 |
| | I'mglad I punted that one back to Marcos, I know nothing about the PCL device. | 13:49.02 |
| | Hmm, in fact it appears to be a device of their own, not even a modified version of one of ours, though its possible I just can't find the one trhey modified | 13:55.04 |
| davesleep | http://this-is-how-i-did-it.blogspot.co.uk/2013/04/upgrade-ghostscript-and-imagemagick-on.html chrisl | 14:07.25 |
| | that's what im following | 14:07.30 |
| | upgrading ghost/imagick on centos6.5 | 14:07.40 |
| chrisl | Well, those instructions are misleading..... | 14:09.32 |
| | autoconf is what creates the configure script - the developers are supposed to run that when they do a release, so the configure script is ready to run on any given machine - and very specifically, does *not* require autoconf to be installed | 14:11.21 |
| davesleep | k | 14:15.49 |
| | but i installed ghost script and imagick | 14:15.59 |
| | and it doesnt seem to be picked up | 14:16.03 |
| | mayb ecentos doesnt support a higher version of image magick | 14:16.58 |
| chrisl | You may need to mess with some paths..... | 14:17.04 |
| | Distributions normally install the executables in /usr/bin | 14:17.53 |
| | But when distributed as source, executables are usually install in /usr/local/bin or similar | 14:18.37 |
| davesleep | i see gs and magickwand++ in /usr/local/bin | 14:19.34 |
| | and autoconf which i installed in /usr/local/bin | 14:20.19 |
| | i take it i should have been pointing them to /usr/bin | 14:20.26 |
| chrisl | It shouldn't really matter, just add /usr/local/bin to your PATH variable, and it should be fine | 14:21.07 |
| | But I would expect all the imagemagick tools to be in /usr/local/bin too | 14:21.27 |
| davesleep | im a proper nub | 14:22.40 |
| | ah one moment | 14:23.52 |
| | in phpinfo() Environment.. i take it that's what you mean | 14:24.49 |
| chrisl | erm no.... | 14:25.16 |
| davesleep | add the usr/local/bin as currently its /bin:/usr/bin | 14:25.17 |
| chrisl | TBH, I know nothing about php...... | 14:26.41 |
| | I'm basically talking about the command line - when you type commands in a terminal, the shell maintains a list of directories to search for executables. I'm saying add /usr/local/bin to that list | 14:28.27 |
| davesleep | i do echo $PATH and /usr/local/bin is there | 14:30.58 |
| | :[ | 14:31.03 |
| chrisl | So if you call gs at the command line it should run | 14:31.24 |
| davesleep | yup | 14:31.46 |
| | it's there | 14:31.47 |
| chrisl | And it's the new version you built and installed? | 14:32.12 |
| davesleep | yup 9.07 | 14:32.18 |
| Robin_Watts | why 9.07? | 14:32.48 |
| davesleep | because | 14:32.53 |
| Robin_Watts | why not 9.15? | 14:32.54 |
| | If 9.07 doesn't work, you know what we're going to tell you, right? | 14:33.06 |
| davesleep | just for now, leave it, it's been enough hassle | 14:33.11 |
| | yeah, i know i'll do 9.15 then | 14:33.17 |
| chrisl | Well, 9.14 is the latest release...... 9.15 isn't actually out yet | 14:33.24 |
| davesleep | imagick is installed | 14:33.33 |
| | kk, ill go ask in php now that they'r eboth installed | 14:33.42 |
| chrisl | You mean your PHP is finding the *new* imagemagick? | 14:34.07 |
| davesleep | nah, i uninstalled the old imagemagick | 14:34.31 |
| | and ghostscript | 14:34.33 |
| chrisl | Right, so is your php finding imagemagick at all? | 14:35.04 |
| davesleep | nope, ill keep googling | 14:35.22 |
| | i think i have to set it in the php. ini | 14:35.26 |
| | and possibly move a file across | 14:35.35 |
| chrisl | Don't move the file(s), create links instead | 14:35.50 |
| davesleep | i hate linux, but when everything ends up working, i love it. | 14:37.18 |
| chrisl | Well, don't use centos! | 14:37.47 |
| davesleep | i use debian on my netbook | 14:37.56 |
| | but this is a VPS ;/ and it uses centos | 14:38.02 |
| | cpanel for easy mode server control | 14:38.07 |
| chrisl | Well, centos (and debian stable) are notoriously out of date | 14:38.32 |
| davesleep | aye but isnt debians respository up to date? | 14:39.07 |
| chrisl | Not stable, no.... | 14:39.25 |
| | IIRC, debian stable is still using gs 9.05 | 14:39.55 |
| davesleep | centos 6.5 is using 8.7 XD | 14:40.24 |
| | right brb, gonna make a coffee | 14:40.52 |
| kens2 | chrisl finally got my outline fallback fonts updating the text state and the currentpoint. Now I only need to work out why the curves go berserk in the outlines. And test it of course..... | 14:42.49 |
| chrisl | kens2: that sounds good. Shame the curves didn't just fall out of it | 14:44.32 |
| kens2 | I'm fairly sure the curves are some kind of clipping problem with the control points, I was always pretty certain they were 2 different problems | 14:45.08 |
| | Getting the text state and currentpoint sorted out has been enough of a trial though, coffee time | 14:45.37 |
| davesleep | .. messed up loL :/ time to reinstall centOS | 16:30.11 |
| chrisl | WTF? How?! | 16:30.44 |
| davesleep | i messed up the php.ini for some reason then tried to get it back using easy apache and closed it half way through | 16:31.25 |
| | and root stopped working | 16:31.33 |
| chrisl | I cannot imagine why that would stop root working...... | 16:32.26 |
| davesleep | i dont know why it is | 16:32.31 |
| mvrhel_laptop | hi Robin_Watts | 16:37.58 |
| Robin_Watts | hi | 16:38.14 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 16:38.14 |
| mvrhel_laptop | are you fine with me pushing the merge that is on my repos to golden for mupdf? | 16:38.15 |
| | or tor8... | 16:38.37 |
| Robin_Watts | I have no problem with you using a merge, rather than a rebase. | 16:38.55 |
| | Indeed, I think a merge is right in this case. | 16:39.01 |
| | I have not looked at the commit to have an opinion on it other than that though. | 16:39.20 |
| | Does it change anything outside winrt ? | 16:39.30 |
| mvrhel_laptop | no nothing outside winrt | 16:39.39 |
| Robin_Watts | sorry, platform/windows | 16:39.45 |
| mvrhel_laptop | right. I did the rename. | 16:39.52 |
| Robin_Watts | Then, I can't imagine I'd have a problem with it. Tor8 ?? | 16:39.57 |
| mvrhel_laptop | I did fix one bug that had to do with text selection | 16:40.04 |
| | but that again was in the c# code | 16:40.12 |
| | I am guessing that tor8 will be fine with this.. | 16:45.37 |
| Robin_Watts | I would think so. | 16:45.44 |
| mvrhel_laptop | going to go ahead and do the push | 16:45.47 |
| Robin_Watts | All the commits have been reviewed as they went in. | 16:45.54 |
| mvrhel_laptop | yes. | 16:46.03 |
| Robin_Watts | and it can't break anything as it's self contained, so go for it. | 16:46.18 |
| mvrhel_laptop | ok thanks | 16:46.23 |
| | ok. done. henrys: I am going to take a quick look at adding print page selection on gsview today and then I will get back to SOT charts | 16:47.53 |
| henrys | mvrhel_laptop: do I need to contact fred or is he good to go? | 16:48.34 |
| mvrhel_laptop | then I will see about getting it up on gsview.com | 16:48.37 |
| | henrys: he is good to go. I was going to ping him today and let him know that I did this merge and make sure things are going OK | 16:49.01 |
| Robin_Watts | mvrhel_laptop: bloody hell. the cluster is checking every one of those commits. | 16:53.25 |
| | It's not supposed to do that. | 16:53.34 |
| | It looks very much like you pushed a rebase, rather than a merge. | 16:55.03 |
| | but hey, no harm, no foul. | 16:55.18 |
| henrys | mvrhel_laptop: I guess you could warn folks about the email bomb but not big deal. | 16:56.42 |
| mvrhel_laptop | darn | 16:57.16 |
| | sorry about that. I did the merge here on my repos. and then pushed. I guess that is not the way to do it | 16:57.54 |
| | :( | 16:57.58 |
| | Robin_Watts: what should have been the sequence so that I know in the future | 16:58.21 |
| Robin_Watts | mvrhel_laptop: Well, you've obviously been rebasing your branch as you've been going on, so it's always based upon the latest version of the trunk, right? | 16:59.11 |
| | That's a perfectly reasonable way to work, and is absolutely fine. | 16:59.26 |
| mvrhel_laptop | yes. I was good about rebasing as I went along | 16:59.27 |
| Robin_Watts | So working in that way, you did nothing wrong. | 16:59.44 |
| mvrhel_laptop | I would fetch golden in my master here and rebase my branch on my master | 17:00.09 |
| Robin_Watts | If, on the other hand, you'd be collaborating with someone else on the branch, then rebasing the branch makes it hard for you to share it with them. | 17:00.10 |
| | So in that case, rather than rebasing the branch every now and then, you'd have merged master into the branch occasionally. | 17:00.40 |
| mvrhel_laptop | oh merge the master into the branch | 17:00.59 |
| Robin_Watts | That way the hashes of the commits on the branch never change, so it's easy for all the collaborators can work together. | 17:01.08 |
| mvrhel_laptop | then the commits will be interweaved | 17:01.23 |
| Robin_Watts | At the end of that, you pretty much have to merge the branch back to master. | 17:01.25 |
| | right. | 17:01.30 |
| | So you didn't do anything wrong. You just hadn't done what I'd expected. | 17:01.44 |
| mvrhel_laptop | I see. If I had done the periodic merge then it would only have checked the merge commit | 17:02.27 |
| Robin_Watts | With SOT, for example, if we do work on a branch, and build releases from the branch, it's important we don't then rebase the branch,because we want the branch to keep its sequence of hashes the same. | 17:02.30 |
| | exactly. | 17:02.34 |
| mvrhel_laptop | ok. all good to know | 17:03.09 |
| tor8 | Robin_Watts: mvrhel_laptop: I have no problem with merges, especially on long-standing branches. | 17:14.58 |
| mvrhel_laptop | tor8: ok thanks | 17:17.20 |
| tor8 | mvrhel_laptop: but you've pushed a rebased branch, so that's all academic at this point :) | 17:17.50 |
| mvrhel_laptop | yes. sorry about that | 17:17.59 |
| tor8 | not a problem, at all. this way is more linear, which helps when bisecting :) | 17:20.06 |
| tkamppeter | I have posted some OpenPrinting projects at the VALS Semester of Code (http://semesterofcode.com/), for getting some students to work on. Under them there are also MuPDF-related projects. Would someone of you be willing to mentor them? | 18:04.17 |
| Robin_Watts | tkamppeter: Depends what's involved in mentoring. | 18:06.16 |
| | If it's just answering questions, giving guidance etc, then possibly yes. | 18:06.40 |
| | Can we view the projects? | 18:06.56 |
| mvrhel_laptop | ok so I think the way that this gsview print stuff needs to be done is to do our own print dialog. Create the xps content based upon page selection settings etc and then feed that to the windoze print pipeline. currently I am creating the xps content for the document and then using the ready made print dialog which 1) needlessly may create xps pages we don't need and 2) doesn't seem to... | 18:31.00 |
| | ...work properly in terms of page range etc. | 18:31.01 |
| | the conversion to xps when there are images present is still painfully slow. I wonder if there is anything we can do there? | 18:34.12 |
| Robin_Watts | mvrhel_laptop: So printing is all done via xps creation? | 18:35.04 |
| mvrhel_laptop | yes. | 18:35.13 |
| | I question if this is the best way though | 18:35.28 |
| | this printing stuff is really the one part of gsview that makes me go to AR now and then | 18:36.12 |
| | other than that, I have been using it as my default PDF viewer | 18:36.25 |
| Robin_Watts | So, if I'm following what you just said... Currently you generate an xps for the whole document, and the standard windows print dialogue then chooses pages from that? | 18:36.27 |
| | and your alternate suggestion is to do our own print dialog, and based on that create an xps with exactly the pages in we want? | 18:37.31 |
| mvrhel_laptop | well that was the original plan. unfortunately, the print ticket that is generated is ignoring my requests to choose pages. not sure what is going on there. but yes on your most recent post | 18:37.48 |
| | I want to avoid creating xps until I need it and only those pages that we need | 18:38.11 |
| Robin_Watts | So it's asking for the whole xps before it puts up a print dialog? | 18:39.02 |
| mvrhel_laptop | yes. that is 1 thing I want to fix | 18:39.20 |
| Robin_Watts | I guess that makes sense so it can do a print preview/know the number of pages etc. | 18:39.31 |
| mvrhel_laptop | yes exactly. I already have thumbnails of the pages | 18:39.43 |
| | and can show those in the preview | 18:39.48 |
| Robin_Watts | So doing our own print dialog would seem to get around that. | 18:39.49 |
| | Can we query print margins etc? So we can do shrink to fit etc? | 18:40.03 |
| mvrhel_laptop | I believe so | 18:40.10 |
| | that is what I am going to look at first | 18:40.18 |
| Robin_Watts | Ok, so you also said that "creating xps that include images is slow" | 18:40.35 |
| mvrhel_laptop | to see if I can get the list of printers and their properties. | 18:40.39 |
| | Yes. | 18:40.50 |
| Robin_Watts | I bet in gs we have to recompress images. | 18:40.54 |
| mvrhel_laptop | I am doing a small test here to see what is going on now | 18:41.26 |
| Robin_Watts | There is probably no easy way to pass the already compressed images across the device boundary. | 18:41.35 |
| tkamppeter | Robin_Watts, it is more or less like GSoC. Astudent works for 3 months on a project and you give him some guidance. | 18:41.35 |
| Robin_Watts | tkamppeter: Then we can probably get involved. Certainly we could 'co-mentor' with you, I'd think. | 18:42.32 |
| | Obviously henrys has the final say on this. | 18:42.41 |
| | but we'd probably like to see the project definitions... | 18:42.54 |
| tkamppeter | Robin_Watts, theproject is "Add printer output backends to MuPDF" on http://www.linuxfoundation.org/collaborate/workgroups/gsoc/google-summer-code-2014-openprinting-projects. | 18:42.59 |
| | I also would perhaps need some co-mentorship on "Add MuPDF support to cups-filters for a lightweight mobile printing stack", which you can see on the same web page. | 18:43.53 |
| | They will bepublished on http://vps.semesterofcode.com/ for students to apply from Friday on. | 18:44.30 |
| Robin_Watts | mvrhel_laptop: I bet we can do something to get compressed images passed across the device boundary. | 18:45.03 |
| | I had to make a change to mupdf to do exactly that. | 18:45.28 |
| | The trick will be to do it without breaking existing devices. | 18:45.44 |
| | Every bitmap passed across the device boundary has a bitmap id. | 18:46.28 |
| | One way to do it would be to have callers say "Here is how to get the compressed data for bitmap 'x'" just before making a call and passing bitmap x. | 18:47.16 |
| | Gotta go, being called for dinner. I will ponder some more. | 18:47.28 |
| mvrhel_laptop | thanks Robin_Watts | 18:58.37 |
| | ok. so for example, in this particular case, these images are jpeg images. xps supports jpeg images directly. there must be some way just to pass them through | 19:11.55 |
| | and my 2 page 1.38 MB pdf file is blown up to a 311MB xps file | 19:13.05 |
| | :( | 19:13.07 |
| | henrys: any thoughts about how we could fix this? | 19:13.23 |
| | interesting. the contrast is different in the pdf vs xps file | 19:14.57 |
| henrys | mvrhel_laptop: yes, I've been avoiding it. | 19:14.59 |
| mvrhel_laptop | :) | 19:15.02 |
| Robin_Watts | mvrhel_laptop: OK. I reckon we do it by having a new device call. | 19:15.08 |
| | (or a new dev spec op) | 19:15.14 |
| | Where the caller announces an 'image bank' to the device. | 19:15.49 |
| | The device can then call the image bank to say "do you have the compressed data that makes up bitmap x?" | 19:16.14 |
| | and the image bank can either say yes, here it is, or no. | 19:16.26 |
| henrys | mvrhel_laptop: but it's correct right ? ;-) | 19:16.45 |
| Robin_Watts | That way pdfwrite/xpswrite etc can get the original data, if it's available and reuse it. | 19:16.47 |
| | The only downside to that I can see, is that we'll always be decoding to a bitmap and passing it, even if the device doesn't need the bitmap. | 19:17.25 |
| mvrhel_laptop | henrys: the content is there (at last page one which was gray scale). page 2 which is color is still trying to be drawn by the windoze xps viewer. It seems to be having issues with page 2... | 19:18.03 |
| henrys | I thought we were talking about gs xpswrite | 19:18.11 |
| Robin_Watts | The only way to avoid that is to change from passing bitmaps to passing 'images' across the device boundary (or, in more gs style, to add new device calls that can fall back to the bitmap ones). | 19:18.22 |
| mvrhel_laptop | henrys; we are. I don't quite understand what Robin_Watts means by always decoding | 19:18.51 |
| Robin_Watts | At the moment, the device functions take decoded bitmaps. | 19:19.11 |
| mvrhel_laptop | oh I think we want to take coded data | 19:19.22 |
| Robin_Watts | so the caller decodes the JPEG (or whatever) to a bitmap and passes that across. | 19:19.30 |
| | I was proposing a way that devices could say "give me the uncompressed version" | 19:19.46 |
| mvrhel_laptop | and if a high level device understands JPEG for example, then it is passed in its compressed form | 19:20.06 |
| Robin_Watts | mvrhel_laptop: Passing the compressed version would be a better plan, yes. | 19:20.13 |
| | It's what I recently changed mupdf to do. | 19:20.19 |
| | BUT, if I try and change the device interface, ray will pitch a fit :) | 19:20.41 |
| mvrhel_laptop | henrys: yeah! it finally displayed page 2. Took about 4 minutes :) | 19:20.46 |
| Robin_Watts | so, we'd need to add new device functions that can fallback to the old ones. | 19:21.08 |
| henrys | mvrhel_laptop, Robin_Watts : we need high level images in gs xpswrite. Now it is rectangles, that should be good enough | 19:21.16 |
| mvrhel_laptop | well does pdfwrite decode and reencode? | 19:21.17 |
| Robin_Watts | Oh gawd. | 19:21.27 |
| | mvrhel_laptop: It does. | 19:21.31 |
| mvrhel_laptop | I see | 19:21.40 |
| Robin_Watts | but encoding and decoding is still a million times better than rectangles. | 19:21.47 |
| mvrhel_laptop | :) | 19:21.52 |
| | ok. perhaps I can add that in to the xpswrite device | 19:22.34 |
| | a nice break from SOT? | 19:22.43 |
| henrys | I'm confused are you using xpswrite in mupdf or gs? | 19:23.28 |
| | mvrhel_laptop: | 19:23.30 |
| mvrhel_laptop | waiting to see what henrys says... | 19:23.35 |
| | henrys: in gs | 19:23.41 |
| | mupdf has no xpswrite capability | 19:23.48 |
| henrys | mvrhel_laptop: I thought Robin_Watts had started something rudimentary | 19:24.23 |
| mvrhel_laptop | oh. Do we have xpswrite in mupdf Robin_Watts ? | 19:24.40 |
| Robin_Watts | urm... | 19:24.48 |
| mvrhel_laptop | :) | 19:24.51 |
| henrys | mvrhel_laptop: the exact high level image code is already implemente in the the pclxl devices. I was just going to pull that over, it looks the easiest. | 19:25.25 |
| | but it has to output xps | 19:25.35 |
| mvrhel_laptop | ok | 19:25.40 |
| Robin_Watts | aha. found it. https://www.youtube.com/watch?v=-5i1cJIwE7M | 19:25.47 |
| mvrhel_laptop | :) | 19:26.07 |
| Robin_Watts | I don't think we have an xps write device in mupdf. | 19:26.46 |
| | Possibly I was going to start looking at it, but it never happened. | 19:26.59 |
| | We have an SVG device. | 19:27.23 |
| | and a PDF device. | 19:27.28 |
| | both unfinished. | 19:27.31 |
| | but usable. | 19:27.36 |
| mvrhel_laptop | right. I am using them in gsview | 19:27.51 |
| henrys | mvrhel_laptop: have at it. | 19:27.58 |
| mvrhel_laptop | to write out linearized pdf etc | 19:28.02 |
| | henrys: ok. I will only work on it for an hour or so each day and keep pushing on SOT. | 19:29.00 |
| | henrys: and if you can review what I do, that would be great | 19:29.28 |
| henrys | mvrhel_laptop: sure | 19:29.59 |
| mvrhel_laptop | that and the print dialog seem to be the thing that is really screwing up my use of gsview (and it would make people not use it) | 19:30.12 |
| henrys | mvrhel_laptop: one of the issues is a lot of stuff doesn't get into the high level image code for various reasons. I was wondering if we could stitch together rectangles at the device level and create a new image, that would capture everyting. But it's hard to do. | 19:31.14 |
| Robin_Watts | henrys: ew! | 19:32.27 |
| mvrhel_laptop | ok. let me take a look. the only place I have played with high level images is going into the clist. | 19:33.12 |
| henrys | mvrhel_laptop: doing it otherwise there will always be cases where the file size explodes with rectangle as far as I can tell. | 19:33.41 |
| mvrhel_laptop | henrys: so you are saying that there are cases when going from PDF that we currently dont capture high level data in you current pclxl device? | 19:34.55 |
| | but do rects instead? | 19:35.04 |
| | I know there are cases that this occurs in the clist | 19:35.20 |
| | usually funny decode cases | 19:35.31 |
| Robin_Watts | AIUI, we NEVER capture compressed data. We always decode to bitmap. | 19:35.56 |
| mvrhel_laptop | right | 19:36.02 |
| Robin_Watts | But in some cases, we fail to even reuse a single decoded copy of a bitmap. | 19:36.23 |
| mvrhel_laptop | not sure how that would happen | 19:36.41 |
| henrys | mvrhel_laptop: yeah it's been a while since I looked but I know the file size explodes for some stuff | 19:37.08 |
| mvrhel_laptop | I think step one is to simply do high level image support like is done in other high level devices | 19:37.19 |
| | and package the image data in a form that xps supports. png, tiff, jpeg etc | 19:37.41 |
| | then if we want to look at passing compressed data directly, we will need to change the device commands | 19:38.10 |
| henrys | mvrhel_laptop: agreed | 19:38.50 |
| mvrhel_laptop | this way we can handle formats like jpeg2000 that xps does not support | 19:38.50 |
| Robin_Watts | mvrhel_laptop: Probably always into png as a first step. | 19:38.55 |
| mvrhel_laptop | I was thinking png too Robin_Watts | 19:39.04 |
| Robin_Watts | at least that way you can guarantee it won't degrade more. | 19:39.15 |
| mvrhel_laptop | right | 19:39.19 |
| | although tiff would work too and has the nice feature of supporting cmyk | 19:39.41 |
| | avoiding color conversions | 19:39.48 |
| Robin_Watts | True. | 19:40.03 |
| | That's a compelling argument. | 19:40.18 |
| mvrhel_laptop | ok. so let me try that and see what wall I run into :) | 19:41.01 |
| henrys | mvrhel_laptop: now that I look the image problem might be to do with what XL can't handle ... I think XPS is richer image wise - nothing skewed in xl stuff like that. | 19:47.30 |
| mvrhel_laptop | ok | 19:48.23 |
| henrys | mvrhel_laptop: the condition is at gdevpx.c:1997, the begin image call is there. You could look at pdfwrite but I imagine it will be more complicated. | 19:48.54 |
| mvrhel_laptop | henrys: ok great. thanks | 19:49.09 |
| kens | Robin_Watts : regarding decompressing images, I'm not sure there is any way to avoid decompressing a DCT encoded image (or other input type) in PostScript, as I don't think the parser would be able to return to the correct point in the input stream without doing so. BUt its a bit late for me to think about it at the moment. | 20:14.27 |
| | I'd *like* to ba able to pass DCT encoded data to pdfwrite, at least optionally, because of the file size bloat or recompression artefacts problem. | 20:15.13 |
| Robin_Watts | I wasn't thinking about PS so much, as PDF. | 20:15.52 |
| kens | I have considered recompressing the data with the original paramters, which I *think* should result in no new artefacts, but I've never had the time to investigate it properly and prove (or disprove) it | 20:15.54 |
| | Robin_Watts : Don't forget the GS PDF interpreter runs PostScript | 20:16.09 |
| | And I'd be less happy about a solution which didn't work with PostScript as well. | 20:16.24 |
| | runs *on* PostScript.... | 20:16.36 |
| | THough admittedly any improvement would be nice | 20:16.57 |
| | xpswrite falls back to rectangles / No wonder its slow and bloated...... | 20:17.40 |
| | (still reading through the logs) | 20:17.47 |
| rayjj | marcosw: mvrhel_laptop: I am sure glad that Marcos (or Robin?) added the facility to the cluster to prioritize user cluster runs over 'gs-commit' runs. Otherwise I'd still be waiting for mvrhel_laptop's flood of gsview/mupdf comits to be tested | 20:19.35 |
| mvrhel_laptop | sorry rayhh | 20:20.16 |
| | rayjj | 20:20.19 |
| kens | mvrhel_laptop : (for the logs) if you get looking at high level images feel free to punt questions my way, pdfwrite does hits, but pswrite always fell back to rectangles, so I have a reasonableidea of how both approaches work. The rectangles fallback was probably coded because its real easy to code. | 20:20.28 |
| mvrhel_laptop | kens: ok. I am looking carefully over the pswrite and the xl write devices | 20:22.43 |
| kens | pdfwrite handling high level images is mostly comlicated because it does colour conversion, and also tres to figure out which compression scheme to use (when AutoFilterImages is true), as well as downsampling. You cna forget all that for a first pass. Later you will presumably want to deal with images in odd colour spaces, and proabbly consider downsampling to the prtiner resolution (or lower) | 20:22.50 |
| mvrhel_laptop | the xl device seems to be straight forward | 20:23.00 |
| kens | hopes Micahel means ps2write...... | 20:23.00 |
| mvrhel_laptop | yes ps2write | 20:23.11 |
| kens | :-) | 20:23.17 |
| | The complications mentioned above make the code look complicated for ps2write/pdfwrite | 20:23.32 |
| | Its actually a lot simpler than it looks | 20:23.42 |
| mvrhel_laptop | kens: my plan for now is to pack them all as tiff since this lets me handle just about everything without conversions. as well as packing in an icc profile | 20:24.05 |
| kens | Ah, I didn't consider an ICC profile. Presumably you cna handle spot colours/DeviceN that way ? (does xps allow that ?) | 20:24.38 |
| | Downsampling images might get you faster printing, or you can just leave that to the XPS print pipeline. Not sure what would be better | 20:25.26 |
| mvrhel_laptop | ok. so deviceN is interesting. xps allows up to 8 but I suspect such a thing has to be in the windows image format. | 20:25.54 |
| | kens: plan in this case is alternate tint transform | 20:26.10 |
| kens | Yes, that's what I do in pdfwrite | 20:26.21 |
| mvrhel_laptop | and back into tiff | 20:26.24 |
| kens | But I'd ignore weird colour spaces to start with | 20:26.38 |
| | If ytou get stuck trying to figure out what ps2write i sup to let me know | 20:27.33 |
| mvrhel_laptop | ok thanks | 20:28.10 |
| davesleep | right. okay finally reinstalled centos and all other things | 21:04.44 |
| | how do i set its path? | 21:06.17 |
| | yes. it was an old version of ghostscript causing the problem | 23:25.18 |
| | i'm also a total idiot, not realising that using exec doesnt even require imagick to work (as its command line) | 23:25.42 |
| rayjj | mvrhel (for the logs): I saw the discussion on pre-converting images into TIFF or png -- the problem with JPX images is that they can have "SMaskInData" (alpha) channel. Otherwise, it makes sense | 23:56.23 |
| | For Ghostscript, I think we need a new device proc corresponding to begin_typed_image that can accept the source data (particularly for JPEG) but also it allows for pdfwrite to avoid the codec pass if AutoFilterImages=false and when not downsampling -- just use the original data | 23:58.34 |
| | just as for other device procs, if the device can't handle it, it punts to the current graphics lib implementaion | 23:59.49 |
| | Forward 1 day (to 2014/09/11)>>> | |
IRC Logs