| <<<Back 1 day (to 2012/07/08) | 2012/07/09 |
virmitio | new guy question: is there a (relatively painless) way to have ghostscript generate a pdf with interactive form data (ie, the output pdf contains interactive forms / acroforms)? | 03:16.16 |
mrdocs | virmitio: try Scribus... it does all that | 03:34.37 |
| GS can view them with gsview or other viewers | 03:35.04 |
virmitio | mrdocs: thanks | 03:37.45 |
mrdocs | virmitio: its the only open source app which creates forms like acrobat pro | 03:38.14 |
paulgardiner | Robin_Watts: I've updated the text-widget content type patch along the lines we discussed. It's on paul/forms | 10:31.31 |
Robin_Watts | what did we discuss again? :) | 10:39.58 |
| ah yes. | 10:42.34 |
| Bollocks. The cluster is still only testing the head commit when I push several. | 11:14.16 |
norbertj | Robin_Watts: hello, could you mark my latest attachment (see comment #16) to 693042 as private? | 11:17.54 |
Robin_Watts | norbertj: Sure. | 11:18.31 |
| Done, I believe. | 11:19.11 |
norbertj | Robin_Watts: yup. When I logout I don't see it, when I login I do. | 11:21.17 |
Robin_Watts | cool. | 11:21.29 |
| ok, hopefully the cluster should correctly run all the tests now. | 11:42.05 |
jvervier | hi all | 12:41.03 |
| I'm encountering a problem by using ghostscript on a server with Xeon processor | 12:41.25 |
| performance problem | 12:41.46 |
| My local computer is a core 2 duo 2.3Ghz with 3 Go of RAM, the server is a Xeon 3.07Ghz with 4Go of memory (two processors) | 12:42.50 |
| the same batch for-loop on the same PDF's folder take more than an hour on the server | 12:43.16 |
| but on my local computer, it takes 12 minutes | 12:43.27 |
| the server is a Windows 2008 Server | 12:43.40 |
| Is there any know problem about that? | 12:44.05 |
chrisl | What's your local computer running? | 12:44.26 |
jvervier | Windows XP | 12:44.47 |
| but | 12:44.48 |
| I'm actually trying on another server (same processor and memory) | 12:45.08 |
| with an Windows server 2003 | 12:45.34 |
| and it's looking have the same problem | 12:45.48 |
chrisl | Are you using the same version/build of GS on all the systems? | 12:46.34 |
jvervier | Yes | 12:46.44 |
| -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dQUIET -dNOPROMPT -dPDFSETTINGS=/printer -dNumRenderingThreads=1 -dMaxPatternBitmap=400000000 -dNOGC -dBufferSpace=800000000 -sOUTPUTFILE=%donepdfdir%\%%~NXf -c "800000000 setvmthreshold" | 12:47.00 |
| here are the option used | 12:47.05 |
| except that | 12:47.10 |
| dNumRenderingThreads=1 is 2 for the server | 12:47.19 |
chrisl | Hmmm, NOGC seems like a really bad idea...... NumRenderingThrreads has no effect on pdfwrite at all, I don't think BufferSpace has either | 12:49.26 |
| jvervier: what version of GS are you using? | 12:53.28 |
jvervier | 9.05 | 12:54.14 |
chrisl | jvervier: this is a complete stab in the dark, but you might try adding << /IdiomRecognition false >> setuserparams to your "-c" preamble: so it would look like: -c "800000000 setvmthreshold < /IdiomRecognition false >> setuserparams" | 12:57.02 |
jvervier | I'm trying this just right now, I'll take you update of the situation | 12:58.56 |
Robin_Watts | Morning kens & mvrhel_laptop | 15:00.05 |
| mvrhel_laptop: I got a couple of bugs given to me at the end of last week, where interpolation is taking ages. | 15:00.33 |
kens | Hi Robin_Watts | 15:01.15 |
Robin_Watts | specifically it looks like they are interpolating images up and then going to a halftone device. | 15:01.37 |
| kens: How's the holiday? | 15:01.46 |
kens | Fine, the ladies are off to 5th avenue (again...) | 15:02.18 |
henrys | kens:that might cost you. | 15:02.39 |
kens | Weather is back to seasonl;a average (28/29 degrees) | 15:02.42 |
Robin_Watts | paulgardiner: We may have an indeterminism in the forms branch. In one of the cluster tests (for b3a52c4) we get 1 difference in v1.7/nonemployeetravel.mjs | 15:08.42 |
paulgardiner | Robin_Watts: yes noticed that. Is it strange that it comes up every time? Shouldn't it be sometimes and not others, or is it a choice of many different versions? | 15:10.25 |
Robin_Watts | paulgardiner: In this instance it changed between 2 runs on the same machine. | 15:10.51 |
| which is very odd. | 15:10.57 |
| Could be using uninitialised memory maybe? | 15:11.20 |
paulgardiner | It's come up in every test I've done. | 15:14.57 |
Robin_Watts | Sounds like a valgrind run might be worthwhile | 15:16.52 |
kens | Morning ray_laptop | 15:38.21 |
ray_laptop | hi, kens | 15:40.17 |
| chrisl: kens: is it OK with you if I answer Arnold about how to get a space into a name for cidfmap ? | 15:40.58 |
kens | sure | 15:41.12 |
ray_laptop | OK. | 15:41.25 |
chrisl | ray_laptop: I thought the policy was to leave first contact to marcosw....... | 15:41.43 |
kens | has not yet seen teh email | 15:43.16 |
ray_laptop | I'll forward my answer to marcos | 15:46.43 |
mvrhel_laptop | Morning Robin_Watts | 15:52.35 |
| doing any interpolation when heading out to halftone makes no sense | 15:53.09 |
| other than nearest neighbor | 15:53.27 |
| which is what we do for the no interpolation case | 15:53.51 |
ray_laptop | mvrhel_laptop: except maybe interpolating to the cell size (for extreme upscaling) | 15:55.09 |
Robin_Watts | mvrhel_laptop: I created a pdf file with a 16x16 black/white bitmap in on friday, and radically upscaled that. | 15:56.01 |
mvrhel_laptop | maybe. I have done quite a few studies on this (interpolation methods when halftoning) and I never saw any advantage | 15:56.03 |
| Robin_Watts: ok | 15:56.13 |
| fair enough | 15:56.18 |
Robin_Watts | Acrobat does interpolate (so you get shades of greys, which are then halftoned). | 15:56.24 |
| Clearly there is no need to upscale *as much*. | 15:56.33 |
mvrhel_laptop | Robin_Watts: right | 15:56.45 |
ray_laptop | Robin_Watts: you mean interpolate so finely ? | 15:56.54 |
Robin_Watts | (like we could upscale to the halftone cell size) | 15:56.55 |
| ray_laptop: Right. | 15:57.04 |
henrys | and it remains the contone interpolation is very slow relative to adobe as well. | 15:57.14 |
Robin_Watts | but that really doesn't fit into the gs scheme. | 15:57.35 |
| I'm still experimenting. Something very odd is going on with this file. | 15:57.48 |
| If I make the page a single band, then I see lots of 256x256 bitmaps being scaled to be 17067x17067 ones. At 100dpi. | 15:58.35 |
| Which makes no sense at all. | 15:58.39 |
mvrhel_laptop | that is weird | 15:59.23 |
ray_laptop | what's it mean when my msys prompt has (master|REBASE) instead of just (master) | 16:21.42 |
| it happened after git couldn't figure out how to merge when I did a commit --amend | 16:24.16 |
Robin_Watts | it means git thinks you're in the middle of a rebase. | 16:25.11 |
| You should resolve the conflicts yourself by editing the files. | 16:25.34 |
| git add each edited file | 16:25.39 |
| then git rebase --continue | 16:25.46 |
| OR, you can abandon the whole lot by doing git rebase --abort | 16:26.04 |
ray_laptop | Robin_Watts: thanks. I did the git add of the file that was conflicted (after I resolved the conflict) then git rebase --continue said: No changes - did you forget to use 'git add'? | 16:29.56 |
| Robin_Watts: so I just did the rebase --abort | 16:30.08 |
Robin_Watts | oh, sorry. | 16:30.14 |
| You should probably have done 'git commit' | 16:30.23 |
| That 'commits' your revised patch (and gives you a chance to manually update the commit message. | 16:30.51 |
| Then carries on with the rest of the rebase. | 16:30.57 |
ray_laptop | Robin_Watts: I had already committed my change with a git commit --amend -a | 16:32.14 |
Robin_Watts | Right. Using the --amend confused it. | 16:32.43 |
ray_laptop | it was when doing a git up (pull --rebase) that it got the merge conflict | 16:32.44 |
Robin_Watts | Yeah. You had a history A<-B<-C right? | 16:33.04 |
| where C wasn't in the remote end. | 16:33.13 |
| so you pulled in new commits (say D and E) to try and get: | 16:33.30 |
| A<-B<-D<-E<-C right? | 16:33.44 |
| The way git does that is to backtrack to the A<-B<-D<-E and then try to reapply each of the commits that need to be rebased in turn. | 16:34.27 |
| so it tries to commit 'C', and gets a conflict. | 16:34.45 |
| you need to resolve the conflicts by manually editing, then git add them, then git commit | 16:35.03 |
| so you're committing a modified version of C. | 16:35.23 |
ray_laptop | Robin_Watts: git commit or git rebase --continue ? | 16:35.27 |
Robin_Watts | git commit, sorry. | 16:35.34 |
| You have various different options; you can git rebase --skip, in which case it 'skips' the reapplication of C, or you can give up (git rebase --abort) | 16:36.26 |
ray_laptop | Robin_Watts: it seems to be happy following the git rebase --continue and git status doesn't show any file to commit | 16:36.38 |
Robin_Watts | Are all your changes in? | 16:36.48 |
ray_laptop | Robin_Watts: yes | 16:36.57 |
| Robin_Watts: Oh, well. I think it's all OK. I'll find out for sure when I push it up :-) | 16:39.06 |
| here goes ... | 16:39.39 |
Robin_Watts | I'd be a bit suspicious that the git commit --amend may have pushed it into the previous commit. | 16:39.47 |
ray_laptop | oh, well. It's a trivial optional change, so I think I'll just skip it | 16:41.04 |
Robin_Watts | AH! | 16:53.18 |
| This file is created from google maps or something similar. | 16:53.37 |
| So I think it consists of a series of overlaid images, one for each zoom level. | 16:54.18 |
| So we start off with the 256x256 tile that is 'this bit of land seen from the moon', so it's zoomed up so we only see about 64 pixels in the middle of it. | 16:54.58 |
| Then overlaid on top of that we have the next level 256x256 tile that is 'this bit of the earth seen from the lagrange point', so we see a few more pixels from that one (and they completely cover the other one) | 16:55.53 |
| Then overlaid on top of that we have the next 256x256 tile 'this bit of earth from geostationary orbit' etc etc. | 16:56.20 |
| So I suspect that we are failing to clip those outer tiles. | 16:57.07 |
ray_laptop | Robin_Watts: so we are interpolating the entire tile in order to just render a tiny bit in the center ? | 17:01.49 |
Robin_Watts | Yes. | 17:01.57 |
ray_laptop | and then painting over it anyway :-( | 17:02.09 |
| Robin_Watts: is this an XPS or PDF file ? | 17:03.58 |
Robin_Watts | pdf | 17:04.12 |
ray_laptop | so PDFSTEP shows each tile as it is painted ? | 17:04.42 |
Robin_Watts | PDFWHAT ? | 17:05.08 |
ray_laptop | Robin_Watts: -dPDFSTEP | 17:05.22 |
Robin_Watts | WHY HAS NO ONE TOLD ME OF THIS BEFORE?! | 17:06.13 |
ray_laptop | Robin_Watts: don't know. I thought everyone already knew about it. | 17:06.41 |
| it's been around since 2004 | 17:08.00 |
Robin_Watts | Not entirely convinced it works under windows... | 17:08.30 |
ray_laptop | Robin_Watts: it works, but if the file has transparency it doesn't do anything | 17:09.01 |
Robin_Watts | Ah. The file has transparency. | 17:09.13 |
ray_laptop | so sometimes you need to combine it with -dNOTRANSPARENCY in order to find out what paints a certain object | 17:09.39 |
| as the commit message says, it is 'rudimentary' (i.e. sometimes useful) | 17:10.22 |
Robin_Watts | It looks stupidly useful. | 17:11.23 |
ray_laptop | Robin_Watts: stupidly is a reasonable assessment | 17:11.47 |
Robin_Watts | Oh, boy it's even dimmer than I thought. | 17:15.51 |
| It takes a 256x256 bitmap, and then scales up to 17067x17067 with a clipping path set so we only get the 200x200 in the middle somewhere. | 17:17.46 |
| For each square in the most zoomed in level of mapping, it sets the clip path for that, then plots each level of bitmap from far away to close up. | 17:19.17 |
| So we repeat the 256x256->17067x17067 scale for EVERY tiny square. (i.e. we repeatedly scale each source image multiple times, only to clip different regions out of it) | 17:20.30 |
kens | OK lunch and airport, bye all | 17:24.08 |
Robin_Watts | EKENSTOFAST | 17:24.25 |
| Anyone know if we've got a 'transform_rectangle' thing that takes a bbox and a matrix ? | 18:45.01 |
| gs_bbox_transform looks like it. | 18:46.10 |
| I hate the image code. | 20:12.56 |
henrys | won't stir up much controversy with that statement. | 20:27.03 |
mvrhel_laptop | ok. found my xps issue from the last commit I did | 21:01.21 |
| nothing to serious | 21:01.32 |
| we should add that file to our xps test files though | 21:08.22 |
henrys | if you don't have an active test file tree mail the file to marcos for comitting. | 21:28.44 |
| marcos seems to only keep up with pdf and ps files in bugzilla. | 21:29.17 |
mvrhel_laptop | henrys: ok. I will ask him | 22:03.13 |
| Forward 1 day (to 2012/07/10)>>> | |