| | <<<Back 1 day (to 2011/10/30) | 2011/10/31 |
| X-Scale | Hi. Yesterday I converted a pdf file to a sequence of PBM files. The problem came where I tried to visualize the PBM files on XnView. It didn't work. It seems that ghostscript doesn't put spaces between each character, as is defined by the P1 format: http://en.wikipedia.org/wiki/Netpbm_format#PBM_example | 02:15.43 |
| | So, for instance, I got sequences of 00000 when it should have been 0 0 0 0 0. | 02:16.33 |
| alexcher | X-Scale: Use pdbraw for now. it has been tested extensively. | 04:08.35 |
| | X-Scale: It looks like the spaces in pbm are not required. So gs files are valid. | 04:24.34 |
| X-Scale | pbmraw works properly as it uses P4 (binary format). | 06:18.09 |
| ray_laptop | X-Scale: I'm not sure that the spaces are required in pbm format, and other viewers can handle it OK. | 06:22.00 |
| X-Scale | I was checking that on the specification | 06:23.14 |
| | http://netpbm.sourceforge.net/doc/pbm.html | 06:23.17 |
| | "White space in the raster section is ignored." | 06:23.25 |
| ray_laptop | The spec I found was: http://www.fileformat.info/format/pbm/spec/95c6ddbd6ea64476b267895b0ae47873/view.htm | 06:23.27 |
| X-Scale | For Plain PBM | 06:23.39 |
| | I see. | 06:24.52 |
| | XvView is being too restrictive then. | 06:25.00 |
| ray_laptop | with the raster as: Width * height bits, each either '1' or '0', starting at the top-left corner of the bitmap, proceeding in normal English reading order. | 06:25.10 |
| | Nothing in the spec mentions that whitespace is required between the bits, although the example has it. | 06:25.12 |
| X-Scale | Exactly. | 06:25.28 |
| | The example is a little misleading, but not incoherent. | 06:25.42 |
| | And it makes sense that it ignores all white space in the raster as it saves half of the space occupied by the file. | 06:26.34 |
| ray_laptop | X-scale: The spec I found does say: "Programs that read this format should be as lenient as possible, accepting anything that looks remotely like a bitmap." | 06:27.05 |
| | since other viewers can handle it, I am willing to chalk it up to a deficiency in XnView. BTW, I've tripped over this as well. | 06:28.10 |
| X-Scale | I'll try to signal this issue to the author of XnView. | 06:37.22 |
| Robin_Watts | tor8: ping ? | 12:41.11 |
| tor8 | Robin_Watts: pong. | 12:43.21 |
| Robin_Watts | Any luck resolving the release mode crash on iOS? | 12:43.41 |
| tor8 | not yet. just about to start digging again. | 12:43.55 |
| Robin_Watts | Let me know if there is anything I can do to help. | 12:44.10 |
| tor8 | I've managed to get the release mode crash with debugging by buliding the library in debug but the obj-c code in release | 12:44.33 |
| | somewhere in the lexer, the input stream read pointer is garbage | 12:44.57 |
| | I really miss valgrind... | 12:45.14 |
| Robin_Watts | Can you get any debug out ? | 12:46.30 |
| | i.e, can you get printfs or the equivalent out of the lexer ? | 12:46.55 |
| vtorri | hey | 12:48.16 |
| | with mupdf, what is the best way to get the size () width and height) of the document without any transformations ? | 12:48.19 |
| | should I use the mediabox of a page ? | 12:48.54 |
| tor8 | vtorri: yes. | 12:50.47 |
| vtorri | ok | 12:51.02 |
| | then, next question: how do I do that ? | 12:51.16 |
| | i'm explaining: | 12:51.21 |
| | a media box has xi and yi as float | 12:51.41 |
| tor8 | pdf_load_page gives you a pdf_page object, which has a fz_rect mediabox. | 12:51.44 |
| vtorri | and i looked at the code that is returning a box | 12:52.08 |
| | it does some rounding | 12:52.14 |
| | should I doe the same ? | 12:52.36 |
| | or should I use the function that returns the box ? | 12:52.53 |
| tor8 | why don't you just do what pdfdraw and the mupdf x11 viewer do? | 12:53.44 |
| vtorri | because i just want the size, without transformations | 12:54.54 |
| | their code does transformations | 12:55.01 |
| tor8 | then do the same, but skip the transformation step. | 12:55.13 |
| vtorri | bbox = fz_round_rect(fz_transform_rect(fz_identity, page->mediabox)); | 12:55.23 |
| | ? | 12:55.25 |
| | or something even more simpler ? | 12:55.37 |
| tor8 | which is equivalent to bbox = fz_round_rect(page->mediabox); | 12:55.39 |
| vtorri | ok | 12:55.47 |
| | so I'll use that | 12:55.55 |
| | thank you | 12:56.01 |
| tor8 | Robin_Watts: *sigh* now I can't reproduce the bug :( | 12:56.20 |
| ray_laptop | Hi, all. | 14:31.05 |
| | I will be busy from about noon on today (helping at school, then Halloween tonight). | 14:31.51 |
| Robin_Watts | Morning ray_laptop | 14:32.59 |
| ray_laptop | Robin_Watts: we should probably have Miles clarify the Artifex interpretation of GPL (again) so when we are discussing it we are consistent | 14:33.07 |
| Robin_Watts | ray_laptop: Did you disagree with anything I said? | 14:33.28 |
| ray_laptop | I saw somebody asking you about it. I didn't read it thoroughly. | 14:33.56 |
| Robin_Watts | It's my belief that 'Arms length' use is fine (i.e. calling it as a separate application that can be replaced by the end user). | 14:36.34 |
| ray_laptop | the points I know he insists on are that whether it is invoked as a process, via the DLL or statically linked, that it is apparent that it is a separate product. GPL is vague anout invoking it as a process | 14:36.36 |
| Robin_Watts | Right. If it's statically linked, then the whole application is infected with the GPL. | 14:37.16 |
| | If it's DLL, probably too. | 14:37.22 |
| ray_laptop | Robin_Watts: I _think_ that is OK, but he insists (I think) that users be told how to replace/upgrade it (that it isn't some kind of hidden install process that effectively ties end users' hands) | 14:38.02 |
| Robin_Watts | but if it's a process, it's my belief it's safe - unless we've moved to GPL v3. | 14:38.02 |
| | quite right. | 14:38.08 |
| ray_laptop | We are GPL v3 | 14:38.14 |
| Robin_Watts | Ah, GPL v3 makes changes in this area. | 14:38.40 |
| | My advice was basically "You can probably get away with GPL use, but speak to a lawyer to be sure" | 14:39.41 |
| ray_laptop | or check w/ Miles | 14:49.14 |
| | bbiaw | 14:49.22 |
| Robin_Watts | ray_laptop: Indeed, checking with Miles is a good idea. He was planning to come back when he had it working for us to look at it, so we can pass it to Miles then. | 14:51.14 |
| henrys | wow I started looking at the python 3 changes I can't believe they would make such massively backward incompatible change. Essentially any file the looks at binary data has to change. | 14:57.09 |
| Robin_Watts | henrys: Want a copy of my changed version? | 14:57.26 |
| | http://www.wss.co.uk/~robin/pxldis.py3 | 14:58.25 |
| henrys | sure I'll have a look at yours did you use 2to3? | 14:58.36 |
| Robin_Watts | That's got the exception handling and file handling changes in it. | 14:58.42 |
| | no, I hand hacked it. | 14:58.49 |
| henrys | I got an error with that url. | 14:59.11 |
| Robin_Watts | http://www.ghostscript.com/~robin/pxldis.py3 | 14:59.26 |
| | Ahem, sorry. | 14:59.28 |
| | Rats. kammerer was here, and I missed him :( | 15:25.33 |
| | Aha. | 15:33.26 |
| | kammerer, hi. | 15:33.31 |
| | I committed ARM based optimisations for the image rendering in mupdf the other day. | 15:33.55 |
| kammerer | hi | 15:35.20 |
| | in what branch? | 15:35.27 |
| Robin_Watts | into my repo on casper. | 15:35.37 |
| | sorry, let me get you a link. | 15:35.48 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git/.git;a=summary | 15:36.39 |
| | That doubles the rendering speed in Android for my test PDF file (with 8 bitmaps on the page and nothing else) | 15:37.15 |
| | On my HTC desire. | 15:37.27 |
| kammerer | thank you! | 15:39.09 |
| Robin_Watts | Please let me know how you get on. | 15:39.20 |
| | And if you can spot any more hotspots, let me know. | 15:39.29 |
| kammerer | ok | 15:45.23 |
| henrys | Robin_Watts:maybe I am missing something in your patch, the fundamental problem is the data is now an array of ints not bytes so every comparison with a character will fail and unpack is now broken... that's the big thing that needs to change. This really sucks. | 16:05.57 |
| Robin_Watts | ?? | 16:06.24 |
| | Are we talking about pxldis ? | 16:06.33 |
| henrys | yes | 16:06.38 |
| Robin_Watts | I wasn't aware I'd changed anything from bytes to ints. | 16:06.55 |
| | I made the minimal changes I could to accomodate the new exception and printing syntaxes of python 3. | 16:07.45 |
| | and then it ran into problems I didn't understand, so I stopped. | 16:08.07 |
| | I offer the patch purely to avoid you having to make the same 'donkey work' changes that I did. | 16:08.28 |
| henrys | oh okay I thought you had fixed what I was seeing wrong ... | 16:09.59 |
| Robin_Watts | sorry, no. | 16:10.26 |
| gliese849b | how do, Any MuPDF developers here? | 16:31.38 |
| | Thta's a no then. ;o) I'll check back later.. | 16:33.49 |
| vtorri | ? | 16:36.56 |
| | that was fast :) | 16:37.02 |
| Robin_Watts | gliese849b: (For the logs) Yes, we're here. | 16:49.04 |
| mvrhel2 | Robin_Watts: so did you have any more insight on the xps stroking issue? | 16:58.17 |
| Robin_Watts | mvrhel2: Well, I think I now understand completely what's going on, and why you were seeing the problems you were. | 16:59.18 |
| mvrhel2 | ok | 16:59.37 |
| Robin_Watts | And I would expect to see those problems if stroke adjustment is enabled. | 16:59.46 |
| mvrhel2 | ok. I am reading 7.5.2 right now | 17:00.48 |
| henrys | off to the coffee shop ... | 17:00.54 |
| Robin_Watts | If authors can expect to produce sets of strokes like the ones seen in that file, and expect them to to exactly abut, then stroke adjustment cannot be expected to be turned on. | 17:01.04 |
| mvrhel2 | I would think it should not be turned on, in XPS (at least in many of the test files) there are patterns that rely upon strokes abutting | 17:01.42 |
| Robin_Watts | Stroke adjustment is a fairly simple idea, best explained by an example. If you imagine a horizontal line of thickness 1.8 | 17:02.15 |
| | Depending on the y position of that line, it might cover 1 or 2 pixel centres vertically. | 17:02.56 |
| mvrhel2 | I would think that one would simply do anti-aliasing at low resolutions to handle this problem. That is what is suggested in the XPS doc | 17:03.05 |
| Robin_Watts | Hence will appear either as 1 pixel thick, or 2. | 17:03.08 |
| | Stroke adjustment works badly with AA. | 17:03.43 |
| mvrhel2 | well, yes | 17:03.50 |
| | I would not have the adjustment on with AA | 17:03.59 |
| | I mean, instead of stroke adjustment one would use antialiasing | 17:04.16 |
| Robin_Watts | Either you should disable stroke adjustment when AA is on... or you should modify it so it adjusts to the 'subpixels' used by your AA algorithm. | 17:04.24 |
| | I think that probably the right thing to do is to just disable stroke adjustment in XPS. | 17:04.44 |
| mvrhel2 | yes | 17:04.49 |
| Robin_Watts | I can do that for, or you can do it. | 17:05.08 |
| mvrhel2 | I will go ahead and do it | 17:05.17 |
| | thank you for digging into this | 17:05.30 |
| | I was not even aware of stroke adjustment | 17:05.40 |
| Robin_Watts | no worries. | 17:05.40 |
| | I was aware of it. I hadn't seen where it was coded in gs, and in looking into it, I found a bug, so it was worthwhile :) | 17:06.07 |
| mvrhel2 | good deal. | 17:06.33 |
| | how familiar are you with the shading code? | 17:06.47 |
| Robin_Watts | Well, my new scanline converter renders tiger.eps ok. | 17:07.01 |
| | mvrhel2: Bits of it. | 17:07.10 |
| mvrhel2 | ok, I have an XPS bug which generates a gradiant where one triangle in the shading is screwed up | 17:07.40 |
| Robin_Watts | sorry, I mean "I am familiar with bits of it". | 17:07.42 |
| mvrhel2 | I will dig into it first to see | 17:07.52 |
| Robin_Watts | mvrhel2: Feel free to kick that my way if you want. | 17:08.04 |
| mvrhel2 | have you seen this sort of thing before ? | 17:08.05 |
| Robin_Watts | I'm free of hugely pressing stuff at the moment. | 17:08.14 |
| | shadings being screwed? yes :) | 17:08.26 |
| mvrhel2 | ok. I will give it to you then. Then I work on the halftone stuff | 17:08.43 |
| Robin_Watts | sounds like a reasonable deal. | 17:08.54 |
| mvrhel2 | Robin_Watts: ok I sent you the file | 17:17.58 |
| Robin_Watts | Thanks. | 17:18.05 |
| mvrhel2 | it is edited down to just the shading fill | 17:18.21 |
| | and is visible at low resolution | 17:18.35 |
| kammerer | Robin, I reinvestigate scaling timing after patch - it works two times faster, but it still take more 80% of rendering time | 17:22.01 |
| | https://docs.google.com/spreadsheet/ccc?key=0AiZOsHXQgyTWdDNpbFZXcXRfZkJmeURZemJnYkxYenc | 17:22.15 |
| Robin_Watts | ok. | 17:23.33 |
| kammerer | what algorith do you use for scaling? | 17:24.05 |
| Robin_Watts | One from graphics gems. | 17:24.24 |
| mvrhel2 | Robin_Watts: | 17:27.59 |
| kammerer | could you give me a link to it? | 17:28.16 |
| Robin_Watts | ? | 17:28.17 |
| mvrhel2 | so stroke adjust did not fix the issue in the main file. I had to set fill_adjust values to 0.5 to get things to work | 17:28.29 |
| | that got rid of the white lines | 17:28.40 |
| Robin_Watts | mvrhel2: You turned stroke adjustment off, on the current HEAD and it didn't solve the problem? | 17:28.56 |
| | (just checking you've got the commit I put in this morning) | 17:29.42 |
| mvrhel2 | no I did not update yet | 17:29.54 |
| | let me do that | 17:29.56 |
| Robin_Watts | That's why. | 17:30.01 |
| | The old code used to apply stroke adjustment on EVERYTHING if it was turned on, and on horizontal and vertical lines even if you turned it off. | 17:30.40 |
| mvrhel2 | that is real useful | 17:30.50 |
| Robin_Watts | The fix that went in this morning means it only ever gets applied on H and V lines, and then only if it's turned on. | 17:31.22 |
| mvrhel2 | ok | 17:31.30 |
| | how many changes did that result in | 17:32.09 |
| | in the test files | 17:32.15 |
| Robin_Watts | THOUSANDS :) | 17:32.31 |
| mvrhel2 | :) | 17:32.39 |
| Robin_Watts | 24000 or something | 17:32.51 |
| | I bmpcmped the first 1000 and it looked fine to me. | 17:33.05 |
| mvrhel2 | sounds reasonable | 17:33.10 |
| | crazy that that bug was in there | 17:33.23 |
| Robin_Watts | yeah. | 17:33.35 |
| mvrhel2 | ok white lines are gone | 17:37.04 |
| Robin_Watts | cool. | 17:37.09 |
| mvrhel2 | going to test a few different resolutions real quick | 17:37.29 |
| | ok. so I still have some vertical white lines. I am wondering if those are coming from the pattern tiling code though | 17:38.43 |
| | ok. Robin_Watts question for you | 17:41.24 |
| Robin_Watts | mvrhel2: I've just spotted that the patch I passed you for the planar stuff has lots of warnings in it. | 17:42.45 |
| | unused vars etc. | 17:42.56 |
| | go on. | 17:43.17 |
| mvrhel2 | when I worked on the XPS rip at the previous place, to get rid of white lines in these files (we were using the same files) I had to have a 0.5 offset relationship between the pixel getting filled and the patch coordinates. When I set the fill_adjust to 0.5 for x and y in the gs graphics lib, the white lines go away | 17:43.18 |
| | s/patch/path/ | 17:43.33 |
| Robin_Watts | Well, fill adjust of 0.5 means "any part of pixel" rather than "pixel centre". | 17:44.00 |
| mvrhel2 | ah ok. that is what we want with tiling | 17:44.27 |
| Robin_Watts | try a test XPS file where you draw a line of thickness 0.8 from 1.05,0 to 1.05,10 | 17:44.57 |
| mvrhel2 | ok | 17:45.10 |
| Robin_Watts | For "pixel centres" nothing should appear. | 17:45.14 |
| mvrhel2 | let me do that real quick | 17:45.32 |
| Robin_Watts | for "any part of pixel" you should get a 2 pixel wide line. | 17:45.34 |
| mvrhel2 | yes | 17:45.39 |
| | ok, the xps viewer in windoze shows the line | 17:48.13 |
| | realize though, they always have AA on | 17:48.25 |
| | let me see if Acrobat show it | 17:49.00 |
| | yes it does | 17:49.39 |
| | Robin_Watts: so it looks like we should be setting the fill adjust to 0.5 | 17:50.11 |
| Robin_Watts | How wide does Acrobat show it ? | 17:50.24 |
| mvrhel2 | it looks like a single line. | 17:50.35 |
| | hehe | 17:50.39 |
| Robin_Watts | That sounds like they have stroke adjustment turned on. | 17:50.49 |
| mvrhel2 | oh can I turn a grid on | 17:50.50 |
| | ok so in AR I have a white line followed by a blue line (my stroke color) of the same width | 17:51.57 |
| | so it is a width of 1 | 17:52.13 |
| Robin_Watts | They may choose to make all lines of width < 1, be treated as width=1. | 17:52.44 |
| mvrhel2 | well, maybe with the 0.5 setting we want stroke adjustment on | 17:52.46 |
| Robin_Watts | so really we ought to test with width = 1.5 | 17:53.00 |
| | let me knock up a quick test. | 17:53.05 |
| | trick or treat... | 17:53.37 |
| mvrhel2 | the line thickness of 1.5 looks the same at 0.8 did in the xps viewer at 100% resolution | 17:55.38 |
| | in Acrobat it looks wider | 17:56.23 |
| | at 100% | 17:56.29 |
| | so they are doing two different things | 17:58.26 |
| | the XPS view vs. AR | 17:58.36 |
| chrisl | I did a lot of experimenting with Acrobat a few years ago, and I found it was doing strange (and not always consistent) sub-pixel feature compensation. I'd treat its output with some care as a benchmark for this type of thing. | 17:58.39 |
| mvrhel2 | yes | 17:58.46 |
| | it appears that way | 17:58.51 |
| Robin_Watts | pumpkin outside => productivity tends to zero. | 17:59.21 |
| chrisl | Have you got access to Acro Pro? | 17:59.27 |
| mvrhel2 | Robin_Watts: so the XPS windoze viewer appears to have a single pixel width with the 0.8 settings | 17:59.29 |
| | yes | 17:59.30 |
| | chisl: I do | 17:59.47 |
| | chrisl | 17:59.51 |
| chrisl | You could try having it rip to tiff, I found that was more consistent for this stuff | 17:59.55 |
| mvrhel2 | yes. | 18:00.06 |
| chrisl | s/rip/export | 18:00.06 |
| | I thought there was a way to get tiff from the XPS viewer, too, but maybe that's in the API rather than the app..... | 18:00.58 |
| mvrhel2 | yes. OK. with AR->TIFF is shows both lines with the same width | 18:01.52 |
| | much like the XPS viewer | 18:02.00 |
| | in windoze | 18:02.07 |
| Robin_Watts | http://ghostscript.com/~robin/vernier.fpage | 18:06.33 |
| | I should probably have spaced the lines out a bit, but you get the ide. | 18:10.14 |
| | a | 18:10.16 |
| mvrhel2 | Robin_Watts: so with fill any pixel set, we seem to match what AR shows on the screen | 18:11.13 |
| | ok. let me stuff this in a xps wrapper real quick | 18:11.48 |
| | here comes the XPS file | 18:13.14 |
| | http://www.ghostscript.com/~mvrhel/stroke_adjust_2.xps | 18:16.53 |
| | good grief. the windows xps viewer and internet explorer show different things | 18:17.53 |
| | apparently the AA is a bit different in the two | 18:18.18 |
| | at one time, they had a way to turn off AA but I can't remember how | 18:19.11 |
| | oh it was the Edge mode | 18:21.04 |
| netproteus | hi there, I am looking for a way to take a pdf file which has layer/optional content groups, and render an image of each layer for a page, is this possible with ghostscript and if not does anyone have any other ideas? | 18:21.08 |
| mvrhel2 | let me set that in here | 18:21.12 |
| Robin_Watts | netproteus: It's not immediately easy, but probably can be done with PS hackery. | 18:23.35 |
| netproteus | Robin_Watts, yeah from the research I have done so far, I was getting that impression | 18:24.21 |
| Robin_Watts | netproteus: But you may want to think about using mupdf. | 18:24.29 |
| | Again it's not something you can do with the vanilla code, but it's probably not brain surgery to make it work. | 18:24.56 |
| netproteus | ok thanks, I will take a look at that | 18:25.22 |
| mvrhel2 | Robin_Watts: OK. I have the xps file with aliasing turned off | 18:27.18 |
| | let me post that one | 18:27.53 |
| Robin_Watts | I have to shoot out and fetch Helen in a mo. | 18:28.51 |
| mvrhel2 | ok | 18:29.01 |
| | no problem | 18:29.03 |
| | link is the same | 18:29.07 |
| Robin_Watts | I should have spaced the lines out a big more. | 18:29.13 |
| mvrhel2 | apparently, explorer does not honor the turn off | 18:29.25 |
| | but the xps viewer in windows does | 18:29.34 |
| | I need to run some stuff to the school for the halloween party | 18:29.59 |
| | bbiaw | 18:30.01 |
| Robin_Watts | mvrhel2: OK, so for me in the windows 7 xps viewer, I see definite antialiasing (the lines fade in, but no soft edges (on that latest one) | 18:31.23 |
| tor8 | Robin_Watts: and the bug is back. this randomness is driving me nuts. | 18:33.11 |
| Robin_Watts | tor8: ew :( | 18:39.37 |
| | heisenbug | 18:39.42 |
| | mvrhel2: http://ghostscript.com/~robin/stroke_adjust.xps | 18:40.18 |
| | tweaked version of your file with more space in there. | 18:40.29 |
| | we should be able to figure stuff out from that, but I have to run now. back later. | 18:40.40 |
| mvrhel2 | Robin_Watts: ok. | 18:46.44 |
| tor8 | Robin_Watts: oh lovely ... Xcode 4 doesn't even have regular gcc anymore so I can't use that to rule out compiler bugs | 18:48.58 |
| ravenlock | hola | 19:02.49 |
| ghostbot | niihau, ravenlock | 19:02.49 |
| ravenlock | I've a questions regarding distribution of ghostscript with a proprietary commercial system. | 19:03.37 |
| | any armchari lawyers in the house? | 19:03.47 |
| chrisl | ravenlock: we would encourage you to consider a commercial Ghostscript license for such a case. | 19:06.10 |
| ravenlock | ok. can consider that in a moment. | 19:06.58 |
| | but regarding GPL.... | 19:07.04 |
| | we "can use ghost script" with out system "if it is present". | 19:07.23 |
| | but fall back to another mechanism in its absense. | 19:07.35 |
| | if the customer installs ghostscript we use it. | 19:07.43 |
| | if we do not ship it with our product.... | 19:08.03 |
| | is that considered "integrated" per GPL definition on gnu.org FAQ ? | 19:08.20 |
| chrisl | Not usually. That is generally compliant with the letter of (but not the spirit of) the GPL - note, we're GPL3 which is a bit more restrictive than earlier versions. | 19:09.22 |
| ravenlock | I'm readin gthe FAQ on the gnu.org site which I must assume is referring to the most recent GPL | 19:10.35 |
| tor8 | Robin_Watts: grr. same library build, crashes when the app is built for debug but not for release. and it seems to be on-and-off every other time I tweak the compiler flags or project. hair tearing out-worthy this is. | 19:11.57 |
| | good thing I don't have any hair left :) | 19:12.12 |
| chrisl | ravenlock: I would think it does refer to the most recent. I should note: none of us on here (me included) are experts, for a definitive answer you should take proper legal advice. | 19:12.32 |
| ravenlock | chrisl: understood. thank you for the standard disclaimer. :P | 19:13.29 |
| | just wanting your thoughts on it. | 19:13.37 |
| | so (in your opinion)... the manner in which we utilize it is in compliance with the more restrictive GPLv3? | 19:14.34 |
| chrisl | ravenlock: there are people out there doing as you describe with Ghostscript, and it is (in my inexpert opinion) legal. Needless to say, as we have a commercial license option, we're not awfully sympathetic to people making money out of the GPL version! | 19:16.37 |
| ravenlock | right. So, point me to the commercial license now please. I did not see it on ghostscript.com | 19:17.22 |
| | ah, maybe found it now | 19:17.46 |
| chrisl | For commercial license information, you should visit:http://www.artifex.com | 19:17.54 |
| | ravenlock: you will probably need to drop an e-mail to sales@artifex.com to discuss the possible terms. | 19:18.51 |
| ravenlock | right. thanks for help. digging now. | 19:19.09 |
| tor8 | Robin_Watts: ping | 19:49.17 |
| ravenlock | pokes the vtorri | 19:49.46 |
| vtorri | ravenlock: pong | 19:49.55 |
| ravenlock | just now saw you here. :) | 19:50.12 |
| tor8 | Robin_Watts: fitz/stm_read.c line 178 (where p = stm->wp - (stm->pos - offset) is calculated) seems to be where things go wrong | 19:50.17 |
| vtorri | hehe | 19:50.17 |
| | ravenlock: because of my work on epdf and eyesight | 19:50.32 |
| ravenlock | right | 19:50.38 |
| vtorri | mupdf is faster than poppler | 19:51.06 |
| ravenlock | yeah? | 19:51.17 |
| vtorri | and i have some room for more improvements | 19:51.17 |
| | yes | 19:51.21 |
| | try eyesight :p | 19:51.29 |
| ravenlock | yeah, I need to. been awhile. | 19:51.40 |
| vtorri | there is a binary test | 19:51.42 |
| | arrow keys to navigate and zoom the doc | 19:51.58 |
| | and the rendering time displayed in the terminal | 19:52.18 |
| ravenlock | nice | 19:53.28 |
| Robin_Watts | back. | 20:17.02 |
| tor8 | Robin_Watts: I'm inclined to believe in a compiler/optimizer bug. when the expression gets into arithmetic overflow land, the test after it succeeds even though it shouldn't (and doesn't if I force the 'p' into a stored location by for instance calling printf) | 20:18.57 |
| Robin_Watts | tor8: stm->pos and offset are both int's. | 20:20.56 |
| tor8 | in the case where I get the crash, stm->bp & friends are at 11Mb from 0, with stm->pos at 34Mb | 20:21.05 |
| | so the calculated 'p' is way off into overflow land | 20:21.21 |
| Robin_Watts | Ah, you have a .o file, right? | 20:21.46 |
| | Can you get me a disassembly? | 20:21.52 |
| tor8 | Robin_Watts: sure. give me a sec. | 20:22.06 |
| Robin_Watts | That routine should be very simple, but I'll bet it's the scariest thing I see this halloween. | 20:22.58 |
| tor8 | Robin_Watts: command to get a disassembly from an .o file? | 20:23.21 |
| Robin_Watts | fromelf? or objdump ? | 20:23.34 |
| tor8 | command not found | 20:24.03 |
| Robin_Watts | I was using arm-linux-androideabi-objdump.exe -d the other day. | 20:24.21 |
| | objdump is the standard gnu tool, I believe. | 20:24.40 |
| | IF all else fails, send me the .o. | 20:25.02 |
| tor8 | yeah... but this is apple's borked toolchain | 20:25.11 |
| | some makefile hackery and I have what I believe may be the asm | 20:26.27 |
| | http://ghostscript.com/~tor/stuff/seek.s | 20:28.01 |
| | good luck deciphering that ;) | 20:28.12 |
| Robin_Watts | oh, god, thumb. | 20:29.21 |
| tor8 | could that be the reason? *trying with -mno-thumb* | 20:30.40 |
| | I can't compile freetype with armv6 on Xcode 4 (garbage asm output from llvm) | 20:31.19 |
| | and apparently not armv7 with no-thumb either! | 20:31.28 |
| Robin_Watts | Urm... | 20:32.06 |
| | Ltmp106: | 20:32.24 |
| | ldr.wr12, [r4, #24] | 20:32.25 |
| | This is 'new' ARM arm code. | 20:33.12 |
| | I think ldr.w means "load 16 bits". | 20:33.21 |
| | What's fz_stream at offset 24? pos? Is that a short ? | 20:33.51 |
| | being called for food. will be back to look again later. | 20:34.03 |
| | Can you mail me the .o file please? | 20:34.10 |
| tor8 | there are no shorts anywhere in fz_stream | 20:36.02 |
| | only ints and pointers | 20:36.08 |
| | Robin_Watts: http://ghostscript.com/~tor/stuff/stm_read.o | 20:36.59 |
| arthurf | tor8: The "Attempting to create USE_BLOCK_IN_FRAME..." message looks to be coming from here in gdb: http://opensource.apple.com/source/gdb/gdb-1469/src/gdb/varobj.c. I have no idea what triggers it unfortunately. | 20:58.19 |
| | I'll post a couple of sample lines | 20:58.49 |
| tor8 | arthurf: it's related to a variable being used in a block with bad scoping/refcounting. I forgot the details already. | 20:59.21 |
| arthurf | tor8: Okay, I thought you were working on it a couple of hours ago - something about tearing out hair. :) | 21:00.16 |
| tor8 | arthurf: close, but unrelated :) | 21:00.36 |
| | I've run into what I believe is a code generation/optimizer bug in Xcode | 21:01.01 |
| | I'm doing some pointer arithmetic, then testing to see if the resulting pointer is still valid | 21:01.22 |
| | the test passes even when it shouldn't | 21:01.35 |
| | arthurf: basically, p = oldptr + offset; if (p >= beginning_of_array && p < end_of_array) { do-stuff } | 21:02.29 |
| | and it does-stuff even if oldptr + offset overflows (offset being a very big negative number, when the oldptr is an address very near the beginning of the address space) | 21:03.15 |
| | so (11mb - 34mb = big-huge-overflowed-address) | 21:03.34 |
| | but apparently, the compiler believes that big-huge-overflowed-address < 12mb. *sigh* | 21:04.12 |
| Robin_Watts | back. | 21:04.21 |
| | Looking at fz_stream... | 21:04.26 |
| tor8 | Robin_Watts: only ints and floats in there... | 21:04.37 |
| Robin_Watts | 24 should be bp. | 21:04.39 |
| tor8 | I mean, ints and ptrs | 21:04.44 |
| Robin_Watts | let me try something... | 21:05.18 |
| tor8 | http://ghostscript.com/~tor/stuff/stm_read.armv6.no-thumb.s | 21:05.25 |
| | that one also fails, but may be easier to decipher? | 21:05.43 |
| Robin_Watts | yes, that's ARM. | 21:07.34 |
| | gimme a tick. | 21:07.40 |
| tor8 | Robin_Watts: I'm willing to bet that the optimizer assumes that pointer arithmetic can't overflow | 21:08.13 |
| | or underflow, as the case may be | 21:08.22 |
| arthurf | tor8: Ah - okay, thanks. I read earlier in today's log that the problem was intermittent, and I had assumed we were still talking about the frame error. | 21:15.37 |
| mvrhel2 | Robin_Watts: so it is interesting to look at the xps with and without the edge AA on and off in the xps file | 21:17.42 |
| | http://www.ghostscript.com/~mvrhel/stroke_adjust_robin_aa_off.xps | 21:18.11 |
| | and http://www.ghostscript.com/~mvrhel/stroke_adjust_robin_aa_on.xps | 21:18.20 |
| Robin_Watts | mvrhel2: Yeah. In ARM code at the moment... give me 10 mins ? | 21:18.27 |
| | tor8: The ARM code for that looks fine to me. | 21:18.45 |
| mvrhel2 | I *think* the difference is that with it set for aliasing it does not change the line widths but will change the opacity of the line | 21:19.05 |
| Robin_Watts | Is it reaching that case via the whence == 1 thing above ? | 21:19.06 |
| tor8 | whence == 0, stm->pos=34m, stm->wp=11m | 21:19.47 |
| | p=MAX_INT-23m | 21:20.07 |
| Robin_Watts | yeah, whence ==0, but it may previously have been 1. | 21:20.11 |
| tor8 | it's an absolute seek | 21:20.21 |
| Robin_Watts | offset ? | 21:20.48 |
| tor8 | 17 | 21:20.55 |
| | pos=34441055, offset=17, whence=0 | 21:21.22 |
| Robin_Watts | Right. the compiler is treating all this stuff as normal signed ints. | 21:21.31 |
| | and the tests between pointers in the if are unsigned tests. | 21:21.52 |
| tor8 | so it needs to rewind the buffer, but doing that underflows the pointer arithmetic (since the stm->wp address is < pos) | 21:22.06 |
| Robin_Watts | I can't follow the C :( | 21:22.50 |
| | wp = write position? | 21:22.57 |
| tor8 | yeah | 21:23.18 |
| | bp= beginning of buffer | 21:23.26 |
| | rp= reading location | 21:23.35 |
| Robin_Watts | pos = offset of start of buffer ? | 21:23.46 |
| tor8 | wp= writing location (data is valid up to wp) | 21:23.47 |
| | ep= sentinel, limiting the size of buffer | 21:23.59 |
| Robin_Watts | or pos = offset of wp ? | 21:24.24 |
| tor8 | pos= what you said, to relate the current buffered data to the underlying file position | 21:24.26 |
| | Robin_Watts: look at the fz_tell function just above | 21:25.05 |
| | fz_tell() { return stm->pos - (stm->wp - stm->rp); } | 21:25.17 |
| | hmm. now I'm confused too :( | 21:25.33 |
| Robin_Watts | wp - rp = how much data is unread in the buffer. | 21:25.40 |
| tor8 | fz_tell may very well be buggy | 21:26.12 |
| | no, I'm just confused :) | 21:26.41 |
| Robin_Watts | pos = the offset of the last byte written into the buffer. | 21:26.53 |
| tor8 | pos is the offset of 'wp' from the underlying file | 21:26.53 |
| Robin_Watts | Yes. | 21:26.58 |
| tor8 | yeah | 21:27.00 |
| Robin_Watts | So fz_tell makes sense | 21:27.09 |
| | So pos - offset = "how far back from the end of the buffer that 'pos' is" | 21:27.49 |
| | So, we should rewrite that code a bit. | 21:28.40 |
| tor8 | yeah. rewrite it to not use pointer arithmetic for the range test. | 21:30.12 |
| | my brain is warm and fuzzy, stuffed with objective c framework cruft | 21:30.42 |
| | having to actually think again hurts! | 21:30.50 |
| Robin_Watts | if (pos - offset > 0 && pos - offset < wp-rp) | 21:31.13 |
| tor8 | shouldn't that be ... < wp-bp) | 21:32.41 |
| | since we can rewind behind the current reading position without harm | 21:32.59 |
| Robin_Watts | yes. | 21:33.00 |
| | you're right. | 21:33.07 |
| | Just thinking about > or >= | 21:33.16 |
| tor8 | >= 0 should be fine | 21:33.47 |
| | still thinking about the < | 21:33.54 |
| Robin_Watts | <= should be fine too, as that will move back to bp. | 21:34.15 |
| tor8 | yeah! | 21:34.20 |
| Robin_Watts | Right. Context switch back to mvrhel2 :) | 21:34.45 |
| tor8 | Robin_Watts: thanks for the help looking into this! | 21:35.08 |
| mvrhel2 | so it is interesting. we get the best match to the xps viewer for this case when we have stroke adjust true and the fill adjust set to 0.0 0.0 | 21:35.33 |
| tor8 | Robin_Watts: and since the release build now works, I can try out your arm optimized scaling tomorrow | 21:36.13 |
| Robin_Watts | tor8: no worries. | 21:36.26 |
| mvrhel2 | I am recalling now from long ago that when I was dealing with visual brushes (patterns) I had to be a bit more aggressive with what was filled though to match what the XPS viewer was giving me | 21:36.34 |
| Robin_Watts | mvrhel2: Right. I was going to say that it looked very much like fill adjust should be 0. | 21:36.54 |
| mvrhel2 | I think with fill adjust to 0 we will end up with these pattens having lines though. I can have the graphic state changed to set a fill of 0.5 when in the brush and then return it when we are done | 21:37.52 |
| Robin_Watts | mvrhel2: I don't know much about XPS, so some stupid questions if I may before we dive down that route... | 21:38.16 |
| | how come in stroke_adjust.xps, I'm not seeing a horizontal vertical line across the middle ? | 21:38.40 |
| | a horizontal white line, sorry. | 21:38.51 |
| | Is XPS set up to be 1:1 ? | 21:39.28 |
| | (i.e. the values I give in the files are directly mapped to device space?) | 21:39.47 |
| | Ok. If I juggle the window size, it goes right. It's microsofts crap viewer :( | 21:40.46 |
| mvrhel2 | yes the viewer is crap | 21:40.56 |
| Robin_Watts | With the viewer set to what I believe is 100%, I see some interesting things. | 21:41.31 |
| mvrhel2 | I am getting horizontal white lines | 21:41.45 |
| Robin_Watts | me too now. | 21:41.54 |
| | The top 6 rows are vertically aligned with one another. | 21:42.08 |
| mvrhel2 | ok good | 21:42.09 |
| | yes | 21:42.13 |
| | I noticed that too | 21:42.17 |
| Robin_Watts | and the bottom 4 are shifted 1 pixel to the right ? | 21:42.18 |
| mvrhel2 | yes | 21:42.21 |
| Robin_Watts | Those top 6 rows are at x positions 0, 0.1, ... 0.5 | 21:42.36 |
| | So microsoft is rounding 0.5 DOWN. | 21:42.50 |
| mvrhel2 | yes ok | 21:43.14 |
| Robin_Watts | As for stroke adjust, I don't believe they are using it. | 21:43.28 |
| | For me, the bottom row has only 3 'thick' lines in it. | 21:43.49 |
| mvrhel2 | yes | 21:43.56 |
| | me too | 21:43.58 |
| Robin_Watts | wheras the ones above have 5 | 21:44.02 |
| mvrhel2 | yes except for the first three | 21:44.14 |
| Robin_Watts | If stroke_adjust was being used, then that would be consistent, I believe. | 21:44.17 |
| | yes. | 21:44.18 |
| | 1,2,4,5,5,5,5,5,5,5...3 | 21:44.27 |
| mvrhel2 | yes exactly | 21:44.46 |
| Robin_Watts | With the antialiased one, I see exactly what I'd expect a reasonable antialiased engine to give us. | 21:45.50 |
| | the lines blur as they move across - occupy more than one pixel width. | 21:46.19 |
| mvrhel2 | yes | 21:46.25 |
| Robin_Watts | BUT... there is clearly some sort of antialias type operation happening in the unblurred one. | 21:47.02 |
| | as the lines aren't all the same width. | 21:47.09 |
| | (perceptually) | 21:47.17 |
| | So maybe they *are* doing stroke_adjust for lines < 1 pixel wide. | 21:48.00 |
| | Ah. Let me grab this as a bitmap and look at it in paint.net | 21:48.12 |
| mvrhel2 | god this viewer blows | 21:48.53 |
| | as you resize the window the lines all shift | 21:49.05 |
| | I get the horizontal lines going away like you were seeing. | 21:49.52 |
| | to me on the one where the aa is off it looks like they have fooled a bit with the opacity but not the line widths | 21:50.23 |
| Robin_Watts | Looking at a bitmap grabbed from the viewer with it at 100, I'm looking at the colors of the lines. | 21:50.55 |
| mvrhel2 | In the spec, the option that I turned on says this. Controls how edges of paths within the canvas are rendered. The only valid value is Aliased. Omitting this attribute causes the edges to be rendered in the consumer's default manner. | 21:51.12 |
| Robin_Watts | The first 9 lines are solid blue with decreasing R and G components as we go. | 21:51.39 |
| mvrhel2 | ok | 21:51.45 |
| Robin_Watts | The 10th and thereafter are all solid. | 21:51.46 |
| mvrhel2 | but the pixel widths are the same yes? | 21:52.03 |
| Robin_Watts | Yes. | 21:52.08 |
| mvrhel2 | ok so they did some opacity stuff instead of typical AA | 21:52.44 |
| Robin_Watts | So they are doing antialiasing for lines < 1 pixel wide. | 21:52.56 |
| mvrhel2 | yes | 21:53.25 |
| | they must have some thin line adjustment | 21:53.54 |
| | or they simply set an opacity for thin lines | 21:54.17 |
| Robin_Watts | Ah, that'd be cunning. | 21:54.33 |
| | Well... we could test that. | 21:54.54 |
| mvrhel2 | yes, that is another bug that we have on XPS where there are some very thing lines drawn and the viewer draws them light and we have them dark | 21:55.42 |
| | I was thinking that setting the opacity would be one solution for this | 21:56.12 |
| | or simply have them use AA | 21:56.32 |
| | Anyway, so what to do about these patterns though | 21:56.50 |
| Robin_Watts | I'd like to see an example... | 21:57.04 |
| | Using fill_adjust feels like a hack to me. | 21:57.17 |
| mvrhel2 | you like to see the opacity? | 21:57.18 |
| Robin_Watts | no, the patterns... | 21:57.31 |
| mvrhel2 | or you would like to see an example of a pattern issue | 21:57.34 |
| | ok | 21:57.36 |
| | that is pretty easy to create | 21:57.43 |
| | let me work on that tonight and get you one | 21:57.49 |
| Robin_Watts | It may be that we end up fixing it with fill_adjust in the end, but I'd like to understand it first. | 21:58.16 |
| mvrhel2 | I have to get ready in a bit to run the kids to piano and then its trick or treat time | 21:58.16 |
| Robin_Watts | Sure. | 21:58.20 |
| | No worries. I'm going to watch TV. | 21:58.26 |
| mvrhel2 | ok thanks for the help and discussion! | 21:58.36 |
| Robin_Watts | No worries. | 21:58.44 |
| | My scanline converter seems more prone to dropping horizontal lines... | 21:59.01 |
| | Forward 1 day (to 2011/11/01)>>> | |
IRC Logs