IRC Logs

Log of #ghostscript at irc.freenode.net.
Search:
 <<<Back 1 day (to 2012/11/11)2012/11/12 
kens Hoho someone trying to install the .inf file for a printer on WINdows 8....09:13.51 
  Do we supply a printer .inf file as part of the installation ?09:14.35 
chrisl There is one, yes - I wouldn't say "we" supply it, though09:15.09 
kens Well if its in the installer....09:15.20 
chrisl ghostpdf.inf09:15.55 
kens Yeah, was just opening it09:16.06 
  Ah, its from Ghostgum09:16.33 
chrisl Yeh, and the intended/known compatibility is quite clear in the top comment.....09:16.55 
kens Indeed. You want to close the bug, or shall09:17.17 
  I ?09:17.17 
chrisl Or should we reassign to Russell?09:17.45 
kens I doubt RUssell cares now09:17.58 
chrisl I sympathise with that!09:18.49 
  I'll close it....09:18.55 
kens OK thanks, I'm wresling with the Adobe white list for DRM09:19.10 
chrisl Is it not working for that customer font, then?09:19.38 
kens No, it works fine, the customer font isn't on it :-)09:19.52 
  But I though I should see if it had been updated, and it has, massively09:20.06 
chrisl Oh, well, I guess that's not a surprised09:20.23 
kens But extracting the font names from a HTML page, without the notes, is 'challengning'09:20.27 
  Hmm, lots of 'error reading input file' and others, maybe I'll back out that change....12:13.33 
chrisl kens: I would check that locally - I got the same thing on the fapi branch, but all the files errored out on master, too12:20.45 
kens Oh, then that's peculiar12:21.10 
chrisl Notice a little further down: "The following 7230 regression file(s) have been added:".....12:21.20 
kens Yes, but I'm seeing some failures on old test files with pdfwrite12:21.38 
chrisl Yes, but there's not way there are 7k *new* tests since the last commit!12:22.09 
kens I guess thatr's true12:22.23 
chrisl The PXL tests, I think, are *supposed* to error, the others are probably worth checking12:23.10 
kens How the H** do I get out of 'detached head' mode in Git...12:23.24 
chrisl git checkout master?12:23.46 
kens Just tried tha,t elts see12:23.57 
  OK that seems to work, and now I have both files copied locally12:26.27 
Romesnil Hi! I'm using mupdf but it does not remember the last page I visit.13:00.32 
Robin_Watts_ Romesnil: The standard viewer? No. It has no persistent state between invocations.13:01.00 
Romesnil So when I open a pdf, I have to browse to the last page I read13:01.14 
  Yes the standard viewer13:01.31 
  Oh i thought so...13:01.40 
  So I should maybe use another viewer, based on mupdf of course...13:02.15 
kens Robin_Watts_ : any idea whay my last commit (reverting a white list change) hadn't apparently resulted in a regression test ?13:02.38 
Robin_Watts_ Did you 'git revert' ?13:03.06 
kens No13:03.13 
Robin_Watts_ or was it just a normal commit removing the patch ?13:03.19 
kens I pulled an old copy of the file, and committeed it as a new commit13:03.31 
Robin_Watts_ Ok, no idea then.13:03.40 
  I'll check in a mo.13:03.44 
kens Thanks13:03.51 
  Oh crap, I think I see13:04.21 
chrisl_r61 The last commit listed is "pdfwrite - update the 'white list' of fonts" 99 minutes ago - did you push the new one?13:04.30 
  http://git.ghostscript.com/?p=ghostpdl.git;a=summary13:04.39 
kens I seem to have ended up with a new branch called MASTER13:05.02 
chrisl_r61 Oh, yes - oops. git is case sensitive....13:05.50 
Robin_Watts_ git checkout master13:05.52 
kens Robin_Watts_ : yes, and now I'M IN DETACHED HEAD MODE....13:06.08 
Robin_Watts_ Sorry, let me start again.13:06.09 
kens Drat, I really hate the cps lock on this keyboard13:06.26 
Robin_Watts_ git stash ; git checkout master ; git reset --hard MASTER ; git stash pop13:06.29 
  That should make master the same as MASTER13:06.41 
  When you're happy you can then: git branch -D MASTER13:06.51 
Romesnil Robin_Watts: I just install Zathura with pdf support using mupdf, it works perfectly13:07.04 
kens Robin_Watts_ : OK lets see13:07.11 
Romesnil Thanks 13:07.17 
Robin_Watts_ Romesnil: fab.13:07.24 
kens Robin_Watts_ : I think I've confused Git, I know I've confused myself...13:08.35 
Robin_Watts_ kens: git logg -20 and paste it here13:09.40 
kens $ git logg13:10.07 
  * e81f06c (HEAD, origin/MASTER) pdfwrite - revert whielist changes as it seems t13:10.07 
  | * 8e88788 (refs/stash) WIP on (no branch): 24de0d2 pdfwrite - update the 'wh13:10.07 
  | |\13:10.07 
  |/ /13:10.07 
  | * 6484127 index on (no branch): 24de0d2 pdfwrite - update the 'white list' of13:10.07 
  |/13:10.08 
  * 24de0d2 pdfwrite - update the 'white list' of fonts13:10.08 
  | * f51ac44 (cluster/ken) WIP on master: 39e5612 Fixes 693399, PXL file errors13:10.09 
  | |\13:10.09 
  |/ /13:10.10 
  | * 06ff799 index on master: 39e5612 Fixes 693399, PXL file errors out when colo13:10.10 
  |/13:10.11 
  * 39e5612 Fixes 693399, PXL file errors out when color palette is too large.13:10.11 
  reprimaned for flooding ;-)13:10.35 
Robin_Watts_ ok, so it's origin/MASTER, not master.13:10.52 
kens I htink I'm still in 'detached HEAD' mode13:10.52 
Robin_Watts_ git checkout master.13:11.20 
  Where does that leave you?13:11.32 
kens deletion of directory 'gs/base' failed. SHould I try again ? (y/n13:11.56 
Robin_Watts_ y13:12.00 
kens keeps failing13:12.11 
Robin_Watts_ Actually, deleting gs/base ?13:12.13 
  What the hell did you do?13:12.17 
kens that's what it says13:12.20 
  If I say no it does something13:12.38 
Robin_Watts_ presumably you've stashed, so all your changes are safe, right?13:13.02 
kens Deletion of directory 'gs/base' failed. Should I try again? (y/n) n13:13.11 
  Checking out files: 100% (636/636), done.13:13.11 
  Previous HEAD position was e81f06c... pdfwrite - revert whielist changes as it s13:13.11 
  eems to cause errors13:13.11 
  Branch master set up to track remote branch master from casper by rebasing.13:13.11 
  Switched to a new branch 'master'13:13.12 
  Your branch and 'origin/master' have diverged,13:13.12 
  and have 4 and 714 different commits each, respectively.13:13.13 
  Robin_Watts_ : I had a stash, so I hope so13:13.22 
Robin_Watts_ OK. So you'd deleted your master branch.13:13.37 
kens oops :-)13:13.43 
Robin_Watts_ git branch -D master13:13.45 
  so we delete the new one.13:13.50 
  git pull origin master13:14.05 
kens Cannot delete the branch 'master' which you are currently on.13:14.13 
Robin_Watts_ Ok. Try the pull anyway.13:14.23 
kens is that origin/master ?13:14.45 
Robin_Watts_ No. "git pull origin master"13:14.55 
kens OK13:15.02 
  Nothing happening yet...13:15.29 
  Ah, here we go13:15.39 
  From ghostscript.com:/home/git/ghostpdl13:16.16 
  * branch master -> FETCH_HEAD13:16.16 
  First, rewinding head to replay your work on top of it...13:16.16 
  Applying: pdfwrite - linearisation.13:16.16 
  Using index info to reconstruct a base tree...13:16.16 
  M gs/base/gdevpdf.c13:16.16 
  M gs/base/gdevpdfx.h13:16.16 
  Falling back to patching base and 3-way merge...13:16.17 
  Auto-merging gs/base/gdevpdf.c13:16.17 
  CONFLICT (content): Merge conflict in gs/base/gdevpdf.c13:16.18 
  Failed to merge in the changes.13:16.18 
  Patch failed at 0001 pdfwrite - linearisation.13:16.19 
  When you have resolved this problem run "git rebase --continue".13:16.19 
  If you would prefer to skip this patch, instead run "git rebase --skip".13:16.20 
Robin_Watts_ Had you got any changes in the repo that you wanted to keep ?13:17.16 
kens Well, yes, but I could redo them13:17.28 
Robin_Watts_ Well, it thinks that you have commits that need to be reapplied (it's trying a git pull --rebase)13:18.10 
kens Yes, I see that. I don't want to try and pacth the linearisation changes in...13:18.28 
Robin_Watts_ Did you have commits on your local master than had not been pushed up?13:18.32 
kens No commits13:18.39 
Robin_Watts_ Then git rebase --skip13:18.41 
kens Juist stuff in stash13:18.44 
Robin_Watts_ ok.13:18.47 
kens OK back to command prompt13:19.11 
Robin_Watts_ Ok. so does git logg look sane?13:19.23 
kens Well, whitelst.c looks sane, jst a mo13:19.35 
Robin_Watts_ Hopefully with 24de0d2 at the top.13:19.43 
kens Hmm, no, hang on13:20.01 
  Well, actually yes, but I seem to be on wrong checkout still:13:20.17 
  $ git logg13:20.33 
  * e81f06c (origin/MASTER) pdfwrite - revert whielist changes as it seems to caus13:20.33 
  | * 8e88788 (refs/stash) WIP on (no branch): 24de0d2 pdfwrite - update the 'wh13:20.33 
  | |\13:20.33 
  |/ /13:20.33 
  | * 6484127 index on (no branch): 24de0d2 pdfwrite - update the 'white list' of13:20.33 
  |/13:20.33 
  * 24de0d2 (HEAD, master) pdfwrite - update the 'white list' of fonts13:20.34 
  | * f51ac44 (cluster/ken) WIP on master: 39e5612 Fixes 693399, PXL file errors13:20.34 
  | |\13:20.35 
  |/ /13:20.35 
  | * 06ff799 index on master: 39e5612 Fixes 693399, PXL file errors out when colo13:20.36 
  |/13:20.36 
  * 39e5612 Fixes 693399, PXL file errors out when color palette is too large.13:20.37 
Robin_Watts_ No, that's fine. You are on HEAD, which is the same as master = 24de0d2, which is where you should be.13:21.02 
kens Ah, OK then thanks. Lets try chaning the whie list again before I break anything else....13:21.29 
  great, that seems to have triggered a regression run, thanks Robin_Watts_13:24.09 
Robin_Watts_ Fab.13:24.18 
  Hopefully you can stash pop and get your changes back now.13:24.29 
kens and git stash pop brings back my saved changes :-)13:24.30 
Robin_Watts_ Lovely.13:24.34 
  try: git branch -D origin/MASTER ?13:24.55 
kens error: branch 'origin/MASTER' not found.13:25.28 
Robin_Watts_ OK.13:25.34 
paulgardiner You might want git push origin :MASTER13:25.35 
Robin_Watts_ paulgardiner: What does that do?13:25.48 
paulgardiner Removes MASTER from the remote repo.13:26.15 
Robin_Watts_ Ah, lovely, yes.13:26.24 
kens Hmm, should I try that ?13:26.40 
Robin_Watts_ Yes.13:27.05 
  I wasn't aware of that particular use of the : notation.13:27.16 
kens says - [deleted] MASTER13:27.27 
Robin_Watts_ perfect.13:27.33 
kens relief13:27.41 
  Now I can sit back and wait for the cluster result13:27.56 
Robin_Watts_ God, I hate the ghostscript path representation.13:28.02 
kens Coffee......13:28.08 
Robin_Watts_ whiskey more like :(13:28.21 
  lunchtime13:30.24 
  Curses. henrys desired semantics for hpgl paths means they can't be reversed.14:21.24 
kens Sounds like a bad idea14:22.01 
Robin_Watts_ Well, technically it's HPGL rather than henrys, I think.14:23.09 
  Imagine the points of a pentagon. Move to the first, line to the second, move to the third, line to the forth, line to the fifth, closepath.14:23.42 
  Filling that in HPGL gives you a pentagon.14:24.01 
  Stroking it gives you a line and a triangle.14:24.11 
kens bizarre concept of fill....14:24.32 
Robin_Watts_ A move without havine a close first is treated as a 'gap'.14:25.44 
kens Yes, but I still think its odd.14:26.02 
  From a fill pov14:26.09 
Robin_Watts_ It means you can describe a shape with a path, and fill/stroke it with only some of the edges being stroked.14:26.55 
  It's not that strange an idea - it's just different from the PS model.14:27.13 
kens Yes, I see that, but I think its odd14:27.14 
Robin_Watts_ But the closing handling in stroke modes seems VERY strange.14:27.37 
chrisl_r61 I wonder how a plotter does a fill......14:27.44 
Robin_Watts_ chrisl_r61: Hatching ?14:28.03 
chrisl_r61 I wouldn't call that a fill....14:28.23 
  I just wonder if it was one of the things that GL acquired when it started to be used on devices other than "real" plotters14:29.25 
henrys Robin_Watts_:I was beginning to question it too and the problem is different. The issue is I need a way to create a new subpath in GL14:31.18 
Robin_Watts_ henrys: OK.14:31.30 
  What I think we should do is to take a step back and try to define exactly what the different models are.14:31.51 
henrys that subpath ought to begin with a moveto and closepath should go back to that first moveto. Which I think it will just do automatcically14:32.41 
Robin_Watts_ At the moment, I have us creating 'gapto's whenever we're in hpgl mode and we get a moveto that doesn't immediate follow a closepath.14:33.36 
henrys oh christ you want to understand what we're doing ;-)14:33.54 
Robin_Watts_ I find that it helps occasionally, but I am adept at bluffing :)14:34.19 
  Possibly I should leave gx_path_move ALWAYS generating moves, and expose a gx_path_gap function.14:34.42 
  That way you can handle calling move or gap to get exactly what you want.14:35.07 
  That way whenever you call for a move, you get a new subpath.14:35.45 
  And whenever you call for a gap you don't.14:35.56 
  Closes would always return to the last move - is that OK ?14:36.08 
henrys I think I have one command PM1 - start a "subpolygon" and that is the only time I need to create a subpath, so just something to explicitly create a subpath would be best for me.14:37.38 
Robin_Watts_ A moveto will explicitly create a new subpath.14:38.01 
  OK, how about this...14:38.22 
  1) I revert moveto to what it has always been. Call it, you get a new subpath.14:38.38 
  2) I add a new gapto function; call that, and you get what the current moveto does.14:38.58 
  3) I remove the hpglmode stuff entirely from the code. Using gapto to generate the paths is all we need.14:39.23 
  So you'd change PCL over to always calling gapto rather than moveto.14:39.39 
  EXCEPT in your 'start polygon' case.14:39.48 
henrys that's more change than simply an added command to create a new subpath but I guess it is cleaner.14:40.58 
Robin_Watts_ henrys: Cleaner yes. "just adding a command to create a new subpath" - that's what moveto does.14:41.50 
  henrys: ah!14:42.10 
  If you want to test that this will work there is a cheap trick we can use.14:42.28 
  for your start polygon thing, turn hpgl path mode off, call moveto as you do now, then turn it back on again.14:42.52 
  That will stop the moveto call generating a gapto, and will indeed force your new subpath.14:43.17 
henrys oh duh I could have just fixed the problem that way.14:43.53 
  you may not need to change anything.14:44.22 
Robin_Watts_ Try that, if it fixes it we can do the other stuff as a lower priority cleanup.14:44.29 
henrys sorry I wasn't thinking14:44.55 
Robin_Watts_ No worries. It's horrible stuff working without clear specs.14:45.23 
  Exposing an explicit gapto operator seems like a nicer way to go though.14:46.30 
henrys well let's see if this simple fix works, gets the bug closed then talk about it.14:52.25 
Viorel Hello! Could you please tell me in what scenario does the "Items left on stack device:" warning is showing up ?14:55.09 
Robin_Watts_ Viorel: do you mean "items left on stack in draw device:"14:56.10 
Viorel that's called from draw_device.c. Yes, I saw now the correct form.14:56.28 
Robin_Watts_ That's because we are getting to the end of the rendering, and finding that things have not been popped off the stack as we expect.14:56.59 
  The draw device stack is used for clipping/transparency grouping etc.14:57.13 
  Either there is a bug in our code, or we are hitting a memory limit or something, or there is a problem with the file you are running through in that it doesn't match pushes with pops (saves with restores, q with Q etc).14:58.15 
henrys chrisl:I was working on a font bug this weekend and the pl code is just a nightmare, I hope after your integration we can rethink a lot of that.15:00.10 
Viorel could it have anything to do with the fact that I'm trying to draw 2 pdf documents at the same time? (well, each has its own asynctask, but I'm calling the drawing code for both of them)15:01.03 
chrisl_r61 henrys: that's to do with font selection, isn't it? FAPI doesn't affect that......15:01.55 
Robin_Watts_ Viorel: With different contexts?15:02.07 
  Viorel: Sorry, that was unclear.15:02.23 
  Let me give you my standard spiel about the Android code.15:02.58 
sebras hits the record button.15:03.31 
Robin_Watts_ MuPDF is a set of a libraries for handling PDF files, plus some example tools/applications built upon these libraries.15:03.47 
  The plan is to hide the complexity of the formats etc within the libraries, but leave the UIs etc out in the application layers.15:04.17 
  The Android viewer is one such example of this.15:04.36 
  Because of the nature of android, most of the UI is written in java. The MuPDF libraries are written in C though, and hence needs to be driven from C.15:05.33 
  The example android viewer is therefore in the form of a very thin layer of C that wraps up some of our C level public API and exposes it to the java code, which calls into it.15:06.54 
Viorel yes15:07.30 
Robin_Watts_ While we do our best to try and ensure that the mupdf C library offers a powerful, consistent API, we make no such claim for the wrapped up version that java can call into.15:07.51 
henrys chrisl_r61:no selection really, loading, building the pcl dl font wrappers, boldening, "build_char" stuff beyond what was done in gs_type42.c15:08.25 
Robin_Watts_ That layer is undocumented, subject to change, and is only designed to be just powerful enough for the needs of our example.15:08.26 
  <end of standard spiel>15:09.00 
  IF you are trying to modify the example code so you can drive 2 renders at once etc, then you need to be aware of the limitations of the system.15:09.36 
chrisl_r61 henrys: oh, right. Well, we can certainly tidy up a lot of that for Truetypes, but bitmap and intellifont stuff has to remain15:09.42 
Robin_Watts_ MuPDF itself is perfectly capable of doing it - I wouldn't swear that the existing android java<->C interfaces are.15:10.00 
  If you're opening 2 documents at once, then you should ensure that each has its own fz_context. Attempting to do 2 tasks at once on the same fz_context will give you bad effects.15:10.59 
Viorel Thanks for the spiel! I am experiencing rendering artefacts at a certain position in the zoomed in page, and was wondering if it might have anything to do with that warning15:11.02 
  yes, each of them has its own context15:11.46 
Robin_Watts_ Well, I suspect it's likely.15:12.05 
sebras Robin_Watts_: http://pastebin.com/ZtVxaWNQ use the link. :)15:12.32 
Robin_Watts_ Do you only get the warnings at certain zoom levels ?15:12.40 
  sebras: Thanks :)15:13.05 
Viorel not really, it show up at large zoom levels, when I can see both documents side by side, and the leftmost one takes up less than half of the page, and only at certain positions: if I hit the spot, it blanks or shows only the background with no text over, then, if I move it a bit in any direction, it comes back to normal.15:14.41 
  that happens to the left doc, I forgot to mention15:15.07 
Robin_Watts_ So you're only occasionally getting the warning?15:15.09 
  Or you're always getting the warning, but only occasionally getting the rendering error?15:15.35 
Viorel yeah, and it shows up much earlier than the rendering itself15:15.42 
Robin_Watts_ OK. If it was caused by an error in the file, we'd expect it to ALWAYS show the warning.15:16.17 
Viorel yup, the file is OK, most of the time it renders right15:16.49 
Robin_Watts_ So it's presumably caused by an error during rendering causing us to bale out part way though rendering hence giving that error.15:17.08 
  It's *probably* down to memory.15:17.27 
Viorel After some research, I see that it only shows the warning once, at the first rendering problem, and then, whether it renders correctly or not, the warning isn't shown anymore.15:19.07 
Robin_Watts_ That may be code to suppress the same warning coming out again and again kicking in.15:20.04 
  Are you using the cookie ?15:20.16 
  When you call fz_run_page, you get to pass the address of a cookie structure in.15:20.55 
  The rendering process updates that cookie as it goes.15:21.09 
  Including (if memory serves) a count of the number of rendering errors it's hit.15:21.21 
Viorel yes, I'm using it to abort the intermediary, unnecessary draw calls, for when scrolling quickly through a page15:21.39 
Robin_Watts_ Right, so you can spot when renders have gone wrong by looking at that.15:22.11 
Viorel great, thanks!15:24.03 
Robin_Watts_ As to what you do when you spot such problems...15:24.23 
  options are to try rerendering a smaller area, or to put a warning up for your users, I guess. 15:25.00 
Viorel yes, the ideal case would be to get to its root and eliminate it from there, as the memory is not maxed out, from the heap values15:26.26 
Robin_Watts_ Are you in a position to put breakpoints in the code?15:27.14 
Viorel yes, of course15:27.25 
Robin_Watts_ breakpoint fz_throw then.15:27.37 
  You say "yes, of course", but I have not yet managed to get a debugger set up for android.15:29.17 
Viorel for plain Java it's simple, but for NDK you must use gdb. It requires some steps at each debug session, but it works15:30.23 
Robin_Watts_ Viorel: Right. I am not averse to using gdb, but I'm running from windows.15:31.25 
Viorel this is the tutorial: http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-debugging/15:31.31 
  me too15:31.32 
Robin_Watts_ Ah, thanks!15:31.37 
Viorel on windows, and eclipse15:31.39 
  no problem!15:31.44 
Robin_Watts_ ew eclipse.15:31.44 
Viorel I know, it should work with ant too15:31.56 
Robin_Watts_ useful link. Thanks.15:32.12 
Viorel my pleasure!15:35.56 
Robin_Watts_ sebras: You looked in the 'slow' file, right? IRT3000.pdf ?15:36.44 
  According to my figures 57% of mudraws time is spent actually drawing. (The rest is in interpretation and writing the png out).15:37.21 
  27% of total time is in fz_paint_image_N_lerp15:37.50 
henrys anybody played around with valgrind gdbserver? - looks interesting.15:43.30 
Robin_Watts_ henrys: I haven't. I use --db-attach=yes15:44.28 
  Which means that it spawns me a gdb on valgrind errors.15:44.47 
henrys yes that's what I use too15:45.03 
Robin_Watts_ Is valgrind out for ML yet?15:45.22 
henrys with this you can step etc. though the code while valgrind is working 15:46.10 
Robin_Watts_ right, that is nicer.15:46.19 
  valgrind + memento in a meaningful manner :)15:46.32 
henrys what are you doing in ML? rewriting mupdf?15:47.37 
Robin_Watts_ Mountain Lion.15:47.57 
henrys oh I thought you meant ocaml15:48.07 
  haven't tried it yet.15:48.17 
Robin_Watts_ maintained a hardware compiler in ML in a previous life.15:48.36 
  (SMLNJ and later CAML)15:48.51 
sebras Robin_Watts_: yes, I used callgrind to tease some statistics out from it.15:51.39 
  though I saw that the main part of the pdf that made it slow was the paths.15:52.32 
  Robin_Watts_: there was lots of line art curves causing lots of linetos which took time to process.15:53.12 
Robin_Watts_ Right. I'm not seeing that in my profiles.15:53.37 
sebras I seem to recall that the lineart was drawn in cmyk too, which made little sense, but that's how the file was specified.15:53.58 
  Robin_Watts_: I still have the stripped down file at home.15:54.19 
Robin_Watts_ I'm seeing a significant amount of time being spent in the interpolated image plotting.15:54.32 
  where we call: fz_paint_affine_N_lerp15:54.50 
  tor8 has that written in a way that I think he hoped the compiler would optimise it for common values of N, but that's not happening here.15:55.14 
henrys turning off path mode does work for that problem, let's see how it tests.15:57.35 
  and it prints norbert's test correctly, today is looking up!16:02.37 
Robin_Watts_ excellent.16:02.52 
Viorel I'm back with a question related to my issue: I am trying to cancel an ongoing rendering by setting cookie->abort to 1. If I take out that line, my issue seems to be gone. Is it another thing I must do to abort an ongoing rendering, besides setting the abort field?16:22.34 
Robin_Watts_ Ah.16:22.52 
  Well, if you set cookie->abort to 1, then it will abort rendering part way through.16:23.08 
  Which means it'll exit the draw device with stuff on thet stack, and hence you'll get the warning.16:23.30 
Viorel and thaat's when it throws the warning, exactly!16:23.40 
Robin_Watts_ That explains the warning.16:23.41 
  So, are you still displaying the rendered bitmap even though you've aborted the rendering ?16:24.10 
Viorel no16:25.02 
Robin_Watts_ Are you sure? :)16:25.55 
  As a test, you could try blanking the bitmap to green after every aborted render.16:26.57 
henrys Robin_Watts_:yeah I really don't like this business of turning on and off the path mode best to leave it on and have explicit gapto and moveto. but ets and other stuff is far more important16:51.05 
Robin_Watts_ sure.16:51.16 
Viorel Robin_Watts_: Indeed, I get the reset color wherever I was getting the corrupted image before, at the approximative position, and sometimes it shows up even on pages that had no problems displaying.17:02.10 
Robin_Watts_ ok, so I'm guessing that your aborted renders are polluting the bitmap.17:02.44 
  If you tell it to render to a particular region of the bitmap, then abort it, then start a render for another area of the bitmap, the first region will remain 'broken'.17:03.30 
Viorel the problem is that the new area isn't rendering, and lets it corrupted.17:04.22 
Robin_Watts_ Viorel: You are resetting the abort flag to 0 before restarting the render, right? :)17:05.00 
Viorel no, within mupdf.c > drawPage17:06.19 
  before rundisplaylist17:06.45 
  and right after creating the cookie17:07.01 
Robin_Watts_ You recreate the cookie each time?17:07.15 
Viorel yes, at each drawPage call. Is it bad?17:07.44 
Robin_Watts_ No, that's perfect.17:07.55 
  You said "the problem is that the new area isn't rendering, and lets it corrupted."17:08.59 
  I'd be tempted to add some logging to the code that outputs the regions being rendered at the start of every render, and outputs the region made invalid at the end of each abort.17:10.09 
  And possibly the regions being painted onto the screen.17:10.40 
  That way you can look to see if you ever get an invalid region of bitmap drawn to the screen - and why.17:11.08 
Viorel yes, the visible part of the left document is corrupted, and the right-hand one is good. I guess that now I have a lead, and must track the issue in my code, which probably holds the error17:11.21 
Robin_Watts_ Morning mvrhel 17:23.59 
mvrhel good morning Robin_Watts_ 17:24.43 
Robin_Watts_ http://ghostscript.com/~robin/ipview.html17:24.46 
mvrhel oh cool. you were busy this weekend17:25.01 
Robin_Watts_ yeah, was fun.17:25.11 
mvrhel I got nothing accomplished this weekend17:25.29 
kens : My repository is borked again17:25.46 
Robin_Watts_ I've just generated cmykcm and cmykcmk pams by playing with the ranges in cmyk ones.17:26.29 
  just updating the ets code to read that too.17:26.37 
mvrhel cool17:26.42 
  so is it even worth me fooling with the psd output and input?17:26.57 
Robin_Watts_ Up to you.17:27.53 
  I won't use it personally, but if you find it useful...17:28.10 
mvrhel ok. I will think about it17:28.33 
Robin_Watts_ mvrhel: In the psd file, how are the spots described in terms of CMYK ?17:32.14 
  4 scale factors?17:32.29 
mvrhel yes17:32.32 
Robin_Watts_ ok, that's what I've done in the pams.17:32.40 
mvrhel ok. cool. have you committed this to the ets git?17:33.10 
Robin_Watts_ you have a header line: # PLANE 4 c 0.5 0 0 0 17:33.14 
  mvrhel: Still working on the ETS changes, so no.17:33.26 
  Gimme 30 mins.17:33.40 
mvrhel ok. If I do the psd stuff I will do it after you do that17:33.50 
  I will look at these cups color output intent issues now17:34.45 
chrisl_r61 mvrhel: IIRC, the cups thing is reported only with text - if it looks like it's actually a font/text problem, feel free to punt it to me17:36.37 
mvrhel chrisl_r61: ok will do17:37.14 
Robin_Watts_ mvrhel: Changes pushed. I have some example files for different aspect ratios.17:51.28 
mvrhel Robin_Watts_ : ok. I will update in a sec and check it out17:51.53 
Robin_Watts_ Also tiger6 and tiger7 (cmykcm and cmykcmk)17:52.00 
  Actually, I might just regenerate those at higher resolutions.17:52.11 
  mvrhel: OK, pushed.18:04.39 
mvrhel ok18:06.36 
  Robin_Watts_: I think tiger6.pam should be called tiger_cmykcm.pam18:12.53 
  Robin_Watts_: so photoshop opens tiger6.pam ok. tiget7.pam had some issues though18:13.10 
Robin_Watts_ I had it called that originally, but hated it :)18:13.18 
mvrhel it thinks it is also 6 bands18:13.28 
  tiger7.pam 18:13.34 
Robin_Watts_ Oh. Me so dumb. Hold on.18:13.41 
mvrhel I can live with tiger6 and tiger7 names18:14.14 
Robin_Watts_ I've force pushed a fixed tiger7.pam18:14.37 
mvrhel ok18:14.49 
Robin_Watts_ Sorry about that.18:14.57 
mvrhel no problem18:15.04 
Robin_Watts_ I want to make ipview.html do raw files too. In theory it might already.18:15.20 
mvrhel ok18:15.31 
Robin_Watts_ It should pick the sizes from the gs names.18:15.54 
mvrhel that will be handy for the transparency stuff for those without photoshop18:16.23 
Robin_Watts_ Yeah.18:16.29 
  I have to pop out to get helen. back soon.18:16.35 
mvrhel weird. I can't properly update from what you pushed18:19.42 
  I get a conflict for the tiger7 file18:19.50 
  so I am at 80f08f73bb2a1366895b6ebc0dd7e95e8ff54cab18:21.10 
  and doing a fetch and rebase18:21.15 
chrisl_r61 It might be because it was a forced push. Do you have any local changes you need to hang onto?18:22.41 
Robin_Watts_ mvrhel: Yes, it's because I forced the push up.19:50.42 
  As far as the history is concerned the lowres tiger6 and tiger7 files never existed.19:51.06 
mvrhel Robin_Watts_: ok20:50.32 
Robin_Watts_ mvrhel: Are you sorted then?20:51.36 
mvrhel no20:52.05 
Robin_Watts_ Have you made any commits?20:52.14 
mvrhel no20:52.20 
Robin_Watts_ ok, so:20:52.26 
  git stash20:52.28 
  git pull -f origin master20:52.38 
  git stash pop20:52.44 
mvrhel sigh20:52.49 
  I am working from tortoise git20:53.01 
Robin_Watts_ Have you got any local changes?20:53.14 
mvrhel no20:53.19 
  I did the fetch just fine20:53.34 
  but the tiger7.pam file is still wrong20:53.44 
  according to photoshop20:53.49 
Robin_Watts_ And if you do a git pull now what does it say?20:54.26 
mvrhel From ghostscript.com:/home/robin/sauce/ETS20:55.21 
  = [up to date] master -> origin/master20:55.23 
  Auto-merging examples/tiger7.pam20:55.25 
  CONFLICT (content): Merge conflict in examples/tiger7.pam20:55.27 
  Automatic merge failed; fix conflicts and then commit the result.20:55.28 
  warning: Cannot merge binary files: examples/tiger7.pam (HEAD vs. 4a765d78b29b85ebeab3f1ac724c169116760f10)20:55.30 
  so there is a conflict20:55.41 
Robin_Watts_ delete examples/tiger7.pam20:55.43 
mvrhel done20:55.52 
Robin_Watts_ then repull20:55.56 
mvrhel git.exe pull -v --progress "origin"20:56.52 
  Uexamples/tiger7.pam20:56.53 
  Pull is not possible because you have unmerged files.20:56.55 
  Please, fix them up in the work tree, and then use 'git add/rm <file>'20:56.56 
  as appropriate to mark resolution, or use 'git commit -a'.20:56.58 
Robin_Watts_ git checkout examples/tiger7.pam20:58.02 
  Sorry, I have no idea how to do this using tortoise.20:58.12 
mvrhel ok. let me fool with it on my own20:58.24 
  why did you choose to do the work flow this way instead of a normal commit?20:58.56 
Robin_Watts_ Sorry, I regularly rewrite history with git to make it look like I didn't make mistakes.20:59.26 
  I didn't twig that it would cause you problems, sorry.20:59.40 
  If you can't solve it, then don't worry. I'll just rewrite history back again.21:00.02 
  In fact, shall I just do that now ?21:00.08 
mvrhel ok. this may explain why I had an issue last week21:00.17 
  I eventually had to do a new cleckout21:00.29 
  since I had a sorts of weird conflicts in files that I had not changed21:00.45 
Robin_Watts_ This isn't a problem with normal git.21:01.06 
mvrhel I do a fetch and rebase21:01.19 
Robin_Watts_ I suspect tortoise is "helpfully" setting a flag somewhere.21:01.19 
mvrhel I would expect to see the same thing occur21:01.27 
  in command line git or tortoise git21:01.47 
Robin_Watts_ Try: git reset --hard HEAD~1 to throw away the top commit.21:02.12 
  or whatever the tortoise equivalent is.21:02.26 
  then when you pull again, there is no commit for it to conflict with.21:02.37 
mvrhel ok that worked21:03.46 
Robin_Watts_ ok. I'll remember not to do that again in future. Sorry.21:03.58 
mvrhel I can't see how command like git would have avoided conflicts showing up since I always do a fetch and a rebase21:04.47 
Robin_Watts_ mvrhel: In binary files the conflicts can be resolved.21:05.12 
  In source files, git normally copes.21:05.23 
  so you're right, it's probably not a tortoise vs command line thing. My bad21:05.39 
mvrhel I tried to resolve the conficts21:05.41 
  but it mucked up things21:05.52 
  ok. thanks for getting me straightened out Robin_Watts_ 21:06.39 
Robin_Watts_ I'm being called downstairs now.21:06.42 
  Sorry for having caused it.21:06.47 
mvrhel ttyl21:06.49 
  no worries21:06.52 
  I learned something new21:06.57 
Robin_Watts_ let me know how you get on.21:06.57 
sebras Robin_Watts_: argh! robin.watts@artifex.com, robin@ghostscript.com robin.watts@ghostscript.com!?!?!22:31.15 
  Robin_Watts_: do they all work?22:31.31 
  Robin_Watts_: and which one do you prefer? I need to clean my address book up a bit so I don't get so frustrated when sending mail to you. :)22:32.02 
mvrhel i curse this psd file format23:26.40 
  bbiaw23:26.47 
 Forward 1 day (to 2012/11/13)>>> 
ghostscript.com
Search: