| | <<<Back 1 day (to 2012/03/01) | 2012/03/02 |
| cryptopsy | is there a ps to html program? | 00:20.21 |
| tor8 | Robin_Watts: fz_image_to_pixmap should catch decoding errors or do something so we can ignore broken image data | 00:25.26 |
| Robin_Watts | does it not ? | 00:25.41 |
| tor8 | mupdf gets uncaught exception on files with broken fax streams | 00:26.08 |
| Robin_Watts | Damn. It certainly shouldn't be an uncaught exception. | 00:26.35 |
| | Give me a filename, and I'll look tomorrow. (mupdf is in pieces at the moment) | 00:26.57 |
| tor8 | 33c386e*-full.pdf | 00:27.39 |
| | in /home/tor | 00:28.16 |
| henrys | Robin_Watts:I looked at your code there is no closepath in the part in question it just does moveto gapto stroke. There is a closepath on the first 2 or 3 paths in the file (all gl/2 file do this) both those paths are not stroked but deleted. | 00:28.27 |
| Robin_Watts | henrys: At the top of the stroking function, I got it to print the paths it was called with. | 00:29.07 |
| | First one: | 00:29.23 |
| | % state_flags=7 subpaths=1, curves=0, point=(19.000000,46.875000) | 00:29.25 |
| | % box=(19.000000,46.875000),(19.000000,787.000000) last=0x2d9e5d0 | 00:29.27 |
| | % segments=0x2d9e550 (refct=1, first=0x2d9e580, current=0x2d9e580) | 00:29.28 |
| | 19.0000 787.0000 moveto % 0x2d9e580<0x0,0x2d9e5d0>:0 #curves=0 last=0x2d9e5d0 | 00:29.30 |
| | 19.0000 46.8750 gapto % 0x2d9e5d0<0x2d9e580,0x0>:0 | 00:29.31 |
| | Second one: | 00:29.33 |
| | % state_flags=7 subpaths=2, curves=0, point=(94.589844,787.000000) | 00:29.39 |
| | % box=(19.000000,711.410156),(94.589844,787.000000) last=0x2d9ffa0 | 00:29.41 |
| | % segments=0x2d9dd40 (refct=1, first=0x2d9fe40, current=0x2d9fef0) | 00:29.43 |
| | 19.0000 787.0000 moveto % 0x2d9fe40<0x0,0x2d9fe90>:0 #curves=0 last=0x2d9fec0 | 00:29.45 |
| | 19.0000 787.0000 gapto % 0x2d9fe90<0x2d9fe40,0x2d9fec0>:0 | 00:29.46 |
| | closepath % 0x2d9fec0<0x2d9fe90,0x2d9fef0>:0 19.0000 787.0000 0x2d9fe40 | 00:29.48 |
| | 94.5898 787.0000 moveto % 0x2d9fef0<0x2d9fec0,0x2d9ff40>:0 #curves=0 last=0x2d9ffa0 | 00:29.49 |
| | 94.5898 711.4102 lineto % 0x2d9ff40<0x2d9fef0,0x2d9ff70>:0 | 00:29.51 |
| | 19.0000 711.4102 lineto % 0x2d9ff70<0x2d9ff40,0x2d9ffa0>:0 | 00:29.52 |
| | 94.5898 787.0000 lineto % 0x2d9ffa0<0x2d9ff70,0x0>:0 | 00:29.54 |
| | So, no closepath on the first one. | 00:30.02 |
| | but a closepath in the middle of the second. | 00:30.14 |
| | which looks suspiciously like the first one, plus a bit more. | 00:30.29 |
| henrys | the first one prints for me in X11 I see the line draw up the side of the page. | 00:32.02 |
| | I'll check again to be sure. | 00:32.12 |
| | certainly don't interrupt mupdf for this. | 00:32.41 |
| | I guess the simplest thing to do is just put a breakpoint at the end of gs_stroke - first one should produce output. | 00:37.32 |
| | I'm using X11 | 00:38.00 |
| | maybe the windows display is buffering the data - I run gs_flushplage(pgs) on X11 when it does tha. | 00:38.57 |
| Robin_Watts | I'm confused. | 00:39.54 |
| | I'm running to pbmraw. | 00:40.02 |
| | And I see the line up the left hand side. | 00:40.14 |
| | And the triangle. | 00:40.18 |
| | Basically, I see exactly what I'd expect to see when I'm asked to stroke those 2 paths. | 00:40.31 |
| | The first call to stroke shouldn't mark the page,AIUI. | 00:41.26 |
| | The second one should, and will give the results I'm seeing. | 00:41.35 |
| henrys | and I'm saying on x11 the first one does mark the page. bp on the first stroke and I see the line running up the page - omnicient rendering? | 00:42.36 |
| Robin_Watts | Hmm. OK, well, that's a bug then :( | 00:43.02 |
| | but independent of that, I don't see where those particular paths are coming frm. | 00:43.54 |
| henrys | it's moving the cursor the currentpoint is kept in sync with gl/2's position | 00:45.29 |
| Robin_Watts | So every cursor move, you add it to the current path ? | 00:46.40 |
| henrys | essentially yes. | 00:47.26 |
| Robin_Watts | So, when you call 'stroke', do you clear the path? | 00:47.47 |
| henrys | stroke clears the path | 00:48.07 |
| Robin_Watts | What function are you calling ? | 00:48.34 |
| henrys | gs_stroke() | 00:48.45 |
| Robin_Watts | ok, | 00:50.00 |
| | I'm worried that there is something in this whole HPGL2 plotting thing that we haven't understood. | 00:52.04 |
| henrys | if I need to preserve the path the meme is to do gs_gsave gs_stroke gs_grestore | 00:52.11 |
| Robin_Watts | You get a sequence of pen operations ? | 00:53.12 |
| henrys | right but there always is a current position - I can go in PCL for example outside GL set the cursor come back to GL/2 and do PD and it draws a line. | 00:54.37 |
| Robin_Watts | My PCL isn't great, so bear with me here. The file you sent... | 00:54.48 |
| | Does a reset? Then goes into HPGL mode? THen does a series of GL2 operations, then goes back to PCL, then finishes, yes ? | 00:55.24 |
| henrys | correct | 00:55.46 |
| Robin_Watts | So PA = Pen At? I.e. move to? | 00:56.02 |
| | PU = With the pen up, move to.... ? | 00:56.21 |
| | and PD = Put the pen down and move to ? | 00:56.36 |
| henrys | pen absolute as opposed to pen relative (rmoveto) | 00:56.38 |
| Robin_Watts | OK, so the overall gist is that the pen is told to move around the shape that would be filled. | 00:57.28 |
| | but it only actually draws in 3 edges of it. | 00:57.44 |
| | Why is the last point PD1024,0 ? | 00:58.41 |
| | In my test it was supposed to be 0,0 | 00:59.02 |
| henrys | to close the path - note everything here is at bottom left corner - there is no coordinate in the file going up the side of the page. | 00:59.35 |
| | you said it was what you expect and I don't think it should be, just seeing if we're looking at the same thing. | 01:00.34 |
| | I have a line going to the upper left corner with your new code. | 01:01.09 |
| Robin_Watts | What I see when ghostpcl renders that is a line running from the bottom of the page to the top. | 01:01.17 |
| | plus a triangle | 01:01.24 |
| henrys | right and there are not coordinates in the gl/2 file where y is greater than 1 inch. | 01:01.56 |
| Robin_Watts | Right. | 01:02.03 |
| | Right. I don't understand how we get from the PCL file to the paths that stroke is called with. | 01:03.02 |
| | I do understand how we get from the paths that stroke is called with to what is rendered. | 01:03.16 |
| henrys | I changed it to 1024,0 because you had a closepath to that point in your original test didn't you? | 01:03.44 |
| Robin_Watts | No. | 01:03.51 |
| | My orignal test file was 0 0 moveto 1024 0 moveto 1024 1024 lineto 0 1024 lineto closepath | 01:04.26 |
| | In the postscript filling model that would add a line back to 1024 0. | 01:04.49 |
| | In the HPGL filling model that would add a line back to 0 0, AIUI. | 01:05.00 |
| | I just tried to copy that file to my laserjet, and nothing was printed. | 01:05.29 |
| | Do I need a form feed or something ? | 01:05.36 |
| henrys | in the mode we are working in no addition line is added. | 01:06.06 |
| | HP's use a heuristic - mine works but I know some model will fail. | 01:06.50 |
| | I'll send you a new file - but getting late for you no? | 01:07.13 |
| Robin_Watts | The point of my test file was to see whether the segment between 0 0 and 1024 0 was stroked, and it's not, as far as I can see. | 01:07.39 |
| | Yeah, but I have a few minutes. | 01:07.51 |
| henrys | that's a pretty well formed pcl file - odd. | 01:08.40 |
| Robin_Watts | Essentially, as I understand what's going on, I'd expect HPGL mode to fill the region that the pen moves around the outside of. | 01:08.51 |
| | and to stroke just the edges where the pen was down. | 01:09.06 |
| | Does that match with your understanding ? | 01:09.19 |
| henrys | yes exactly | 01:09.42 |
| Robin_Watts | So what prompts you to do a 'stroke' operation? | 01:10.49 |
| | Adding a form feed makes my printer like the file, it seems. | 01:11.36 |
| henrys | I sent a new file to you with more explicit pcl stuff anyway. | 01:11.52 |
| Robin_Watts | of course it doesn't actually print anything. Let me try your new version. | 01:12.07 |
| | The new version just prints the PJL foo. | 01:13.39 |
| henrys | oh I did put an extra ampersand but my printer is okay. | 01:14.22 |
| | you haven't damage the file in any way it does have non printable characters in it. | 01:15.21 |
| Robin_Watts | I see no ampersands. | 01:15.25 |
| henrys | bytes 9 and 10 should be ampersands. | 01:16.21 |
| Robin_Watts | I have @ | 01:16.39 |
| | not &# | 01:16.43 |
| | not & | 01:16.45 |
| henrys | brain fart sorry | 01:17.04 |
| | should be just 1 of those | 01:17.13 |
| Robin_Watts | :) | 01:17.13 |
| | Right. Let me try that. | 01:17.19 |
| henrys | at signs, ampersands it's all running together | 01:17.41 |
| Robin_Watts | I need a form feed at the end of the page before it will move the paper. | 01:18.09 |
| | but only having one @ means it doesn't print the PJL. | 01:18.24 |
| | But I still get no path. | 01:18.37 |
| henrys | but no triangle | 01:18.49 |
| Robin_Watts | Whats the default line width in pcl ? | 01:18.49 |
| | no triangle. | 01:19.08 |
| henrys | that's what I was going to suggest try inserting ;PW1; after IN | 01:19.16 |
| Robin_Watts | still nothing. | 01:20.17 |
| | My printer is VERY old. | 01:20.48 |
| henrys | welcome to the world of pcl - when's the last time you rebooted. | 01:20.52 |
| Robin_Watts | My printer? yesterday. | 01:21.08 |
| henrys | the printer that is. | 01:21.09 |
| Robin_Watts | Don't panic. I'll try the canon inkjet MFP thing in the morning - that's PCL too, I think. | 01:21.49 |
| henrys | I do have a beat up monochrome - I get a triangle with nice big fat lines with the new file. | 01:22.10 |
| | I'll get the monochrome working and see if something funky is going on. | 01:22.32 |
| Robin_Watts | but when I next look at this, I'll try to figure out why the first line marks. | 01:22.40 |
| henrys | okay | 01:22.56 |
| Robin_Watts | If you put gx_print_path(ppath); in line 519ish of gxstroke.c in gx_stroke_path_only_aux, presumably you'll see the same paths as I'm getting. | 01:24.17 |
| | I agree that I shouldn't be marking the page with the first one. | 01:24.32 |
| | but the marks that I should generate for the second path are, I believe, exactly the marks we see from ghostpcl. | 01:24.57 |
| | Actually, no, that's rubbish. | 01:25.41 |
| | I was misreading it. | 01:25.48 |
| | So, if I fix the first one to not mark, we should be OK. | 01:26.04 |
| | Sorry. My turn to plead brain fart :) | 01:26.16 |
| henrys | yea but yours was a non trivial fart | 01:26.44 |
| Robin_Watts | yeah yeah. | 01:26.54 |
| | I'll look into that as soon as I need a break from mupdf. | 01:27.14 |
| henrys | setting up the dreaded mono printer you've got me curious | 01:27.31 |
| | looks fine on my mono printer too. | 01:31.36 |
| | 5L's are usually pretty reasonable, puzzling | 01:31.58 |
| Robin_Watts | Yeah, it may be venerable, but it's generally reliably printed anything I've thrown at it. | 01:33.55 |
| | I'm off to bed now. Will ponder more in the morning. | 01:34.24 |
| henrys | night | 01:35.56 |
| chrisl | kens: I get the empty name spot plate with the revision the reporter used and building with VC2010 - do you want me to try on Linux? | 08:54.52 |
| kens | chrisl, is this using the GPL release ? | 09:05.54 |
| | I'm not sure how I'm going to resolve this, I can't reproduce the problem | 09:06.21 |
| chrisl | kens: yes | 09:07.18 |
| kens | Well neither teh commercial 9.05, the GPL 9.05 nor the current code will exhibit the problem for me in either release or debug builds. | 09:07.47 |
| chrisl | Only difference I can think of is that I'm using Win7 and you use Vista - can't see how that would make a difference, though | 09:08.25 |
| kens | Me neither. I'm not using VC 2010 though | 09:08.43 |
| chrisl | Oh, and I'm using 64 bit Windows | 09:08.53 |
| kens | Hmm, that might be it, though I can't see how. Mac OS/X is also 64-bit | 09:09.09 |
| | Are you running a 64-bit executable ? | 09:09.20 |
| chrisl | I can try it trivially with VC8 if that would help? | 09:09.22 |
| kens | Please | 09:09.27 |
| | Abd 32-bit as well please | 09:09.32 |
| | Still don't know how I'm going to fix a problem I can't reproduce though | 09:10.46 |
| chrisl | I used the 32 bit executable | 09:11.26 |
| kens | OK well that's somethign at least :-) | 09:11.34 |
| chrisl | Actually, it'll take a minute to test the VC8 build - I need to build it first...... | 09:13.01 |
| kens | Yes, I wondered about that ::-) | 09:13.10 |
| | If it turns out to be specific to VS 2010 I guess I can use Express | 09:13.24 |
| chrisl | Well, I have a VC8 build (which I was going to use) but it is the patched up one I built for Gemma a couple of weeks ago - I'd rather use a "real commit" | 09:14.18 |
| kens | Probably best | 09:14.28 |
| chrisl | kens: VC8 build - same result | 09:19.16 |
| kens | Well I'm baffled then, it works just fine for me. | 09:19.30 |
| | I suppose I can try Linux | 09:19.45 |
| chrisl | How are you checking for the empty sep name? | 09:19.49 |
| kens | Opening it in Acrobat and using Output Preview | 09:20.02 |
| | It shows the problem with his PDF file | 09:20.08 |
| chrisl | Okay, so we're doing the same thing there, too | 09:20.30 |
| kens | I also examined the PDF files | 09:20.40 |
| | His has an emoty name '/' in a colour space, mine doesn't | 09:20.52 |
| | Well I guess I should try it in Linux, don't really want to try and debug it there though :-( | 09:21.52 |
| chrisl | I'll try linux in a sec - the other variable is Win7 vs Vista | 09:23.13 |
| kens | THey claim to be using XP... | 09:23.24 |
| chrisl | Oh, and I did change the output file they supplied | 09:24.46 |
| kens | THe filename ? I changed that too. | 09:24.58 |
| | And the input location obviously | 09:25.08 |
| chrisl | Yeh, writing to c:\ doesn't work too well on recent Windows! | 09:25.18 |
| kens | Quite.... | 09:25.27 |
| | Oh dear, my Linux seems to only have 8.71 :-( | 09:26.14 |
| | I guess IO'd better git clone the repo | 09:26.23 |
| chrisl | My build has just finished, I'll check LInux now | 09:26.48 |
| kens | I don't suppose you remember the magic runes for cloning ? | 09:27.06 |
| chrisl | git clone ghostscript.com:/home/git/ghostpdl.git | 09:28.31 |
| kens | yeah, just found it thanks | 09:28.38 |
| | And its off.... | 09:29.35 |
| chrisl | Doesn't happen on 64 bit Linux..... | 09:30.22 |
| kens | Sigh. | 09:30.30 |
| | I'm guessing its some kind of stupid memory issue, which is why I can't reproduce it | 09:30.44 |
| chrisl | Empty spot colour happens with VC8 64 bit build, too | 09:34.20 |
| kens | That's puzzling... | 09:34.30 |
| | If it was memory I'd expect that to move stuff around, maybe not | 09:34.41 |
| | cloning the repo is taking a loooong time. | 09:34.56 |
| chrisl | Do you want me to try building on Vista (it will take quite a while!)? | 09:35.32 |
| kens | Not really, I don't think it will tel me anything | 09:35.45 |
| | I just don't know how I'm going to work on the problem | 09:36.00 |
| chrisl | OKay. I guess if the worst comes to the worst, I can always drive my laptop over to you! | 09:36.32 |
| kens | Oh, its your laptop ? Well that might work if we have to. | 09:36.46 |
| | I'll keep prodding with my pointy stick for now | 09:37.02 |
| | clone now at 14% :-( | 09:37.16 |
| chrisl | That's oddly slow....... | 09:37.34 |
| kens | Its always been slow for me, and it is running in a VM with network access bridged over | 09:38.00 |
| | chrisl ping | 10:07.10 |
| chrisl | kens: pong | 10:12.09 |
| kens | New Linux checkout, configure is first operation for build ? | 10:12.15 |
| chrisl | autogen.sh | 10:12.22 |
| kens | Ah, thanks | 10:12.28 |
| chrisl | Oh, and remember to run the one in the gs directory (there's also one for ghostpdl) | 10:13.05 |
| kens | Ah, I ran the one in ghostpdl :-( | 10:13.20 |
| | OK make running.... | 10:15.33 |
| | OK finally. My Linux build does behave the way the customer describes. I have no idea why I can't reproduce this on Windows, given that everyone else seems to be able to :-( | 10:50.09 |
| chrisl | I could try a Windows debug build, and if that still shows the problem, I could send you that build to try? | 10:52.18 |
| kens | Well... Your binary should be identical to mine so it should work here too, I woudl hope :-) | 10:52.47 |
| | OK so on Linux if I remove all the monstrous command line it still goes wrong, that's a plus | 10:53.16 |
| chrisl | True - did you try the 9.05 release installed binary? | 10:53.33 |
| kens | No, I built from source every time | 10:53.44 |
| | At least I have a debug route now, even if it is rather painful for me | 10:54.32 |
| chrisl | Is there any way to run an executable under windows so it *doesn't* see your environment variables, and registry settings? | 10:54.49 |
| kens | Well I can zap the environnment in the shell | 10:55.09 |
| | You think that would make a difference ? | 10:55.25 |
| | Seems I only have GS_FONTPATH | 10:56.29 |
| chrisl | Well, I can't believe that your core Windows is so different to everyone elses! So that leaves the executable environment. But most (all?) of the settings are in the registry now...... | 10:56.31 |
| kens | I couyld delete from the registry, but I'd rather not. | 10:57.07 |
| chrisl | No, I rather hoped there'd be a VC debugger trick that could hide settings | 10:57.46 |
| kens | Hmm, that seemed to do it. Let me check | 10:58.00 |
| | Bizarre! | 10:58.39 |
| | zap GS_FOTNPATH and the problem appears.... | 10:58.53 |
| chrisl | Ah, really sounds like a memory problem, then....... | 10:59.39 |
| kens | I thought it probably was :-( | 10:59.48 |
| | Which may well mean it won't fail in the debugger. | 11:00.10 |
| chrisl | Might be worth throwing it through valgrind and/or memento on Linux - might provide a hint or two | 11:00.24 |
| kens | OK still fails with my debug buil;d | 11:00.28 |
| | Givent that I don't really understand valgrind, I'll try to reproduce it in the debugger first. | 11:01.03 |
| | Ah, on Windows taking out all the customer command line makes it work. | 11:02.18 |
| | Well, lets see if I can make it fail under the debugger. | 11:03.05 |
| | Have to remember how to modify the environment now.... | 11:03.17 |
| | And the asnwer appears to be no, I can't make it fail under the debugger. | 11:18.36 |
| | But I may have to restart my computer first | 11:19.00 |
| Robin_Watts | kens: Why? | 11:19.09 |
| kens | getting rid of an environment variable | 11:19.29 |
| Robin_Watts | If you change an environment variable, then that will not be reflected in the environment of any running process. | 11:19.37 |
| kens | Yes, but it should be reflected in any new process | 11:19.50 |
| Robin_Watts | What you need to do is to remove the environment variable, then launch the new debugger. | 11:19.58 |
| kens | Yes, done that | 11:20.03 |
| Robin_Watts | not any new process; any new process spawned from the current environment - but I suspect you knew that. | 11:20.29 |
| kens | But assuming this is a memory problem, its not surprising this makes no difference | 11:20.30 |
| | Robin_Watts : The gs process is new. | 11:20.53 |
| Robin_Watts | Right, but it's a heirarchical thing. | 11:21.05 |
| kens | I know, which is why I *may* need to reboot its hard to tell | 11:21.20 |
| Robin_Watts | A good trick to see... | 11:21.55 |
| | Run gs, stop it at a breakpoint in the debugger. | 11:22.06 |
| | Then Alt-Ctrl-Q. | 11:22.11 |
| | Then in that window, getenv("GS_FONTPATH") | 11:22.28 |
| kens | Umm well I can try it | 11:22.56 |
| Robin_Watts | If you get NULL then you have no such env var. | 11:22.58 |
| kens | Nah, its stilll present | 11:23.48 |
| | So reboot required :-( | 11:23.58 |
| Robin_Watts | How are you removing it ? | 11:24.08 |
| kens | control panel-settings-system-advanced | 11:24.22 |
| Robin_Watts | A reboot is not required. | 11:24.24 |
| | Ah, oK. | 11:24.25 |
| | So do that, then close the control panel. | 11:24.31 |
| kens | done all that | 11:24.38 |
| Robin_Watts | Then start a new visual studio. | 11:24.42 |
| kens | new shell is fine | 11:24.43 |
| Robin_Watts | Then any process you run from that will be fine too. | 11:24.58 |
| | If your VS has been around since before the env var was removed, then it will still be there in it's copy of the environment. | 11:25.28 |
| kens | Nope, still inheriting it. | 11:25.50 |
| | bbiab | 11:25.54 |
| chrisl | Robin_Watts: you can check environment variables at the GS prompt, no need for the debugger | 11:29.01 |
| Robin_Watts | chrisl: I know. But kens specifically wanted to check whether the var was in the environment of something running in the debugger. | 11:29.48 |
| chrisl | Okay, but you can just run GS in the debugger, then, no need for a break point | 11:30.34 |
| | Aha! http://stackoverflow.com/questions/100543/how-do-i-set-specific-environment-variables-when-debugging-in-visual-studio | 11:31.58 |
| Robin_Watts | IF you want to be able to call getenv to see if the font path is set or not, you need to stop it and use a quickwatch - hence you need a breakpoint. | 11:32.20 |
| kens | and back | 11:32.54 |
| | environment variable now correct, still doesn't fil under debugger | 11:33.06 |
| | fail | 11:33.11 |
| chrisl | Robin_Watts: At the ghostsrcipt command prompt, do: (GS_FONTPATH) getenv not {== flush} if | 11:33.45 |
| | no need for a break point | 11:34.05 |
| Robin_Watts | ah, from postscript. Fair enough. | 11:34.15 |
| chrisl | kens: http://stackoverflow.com/questions/100543/how-do-i-set-specific-environment-variables-when-debugging-in-visual-studio | 11:35.14 |
| kens | Thanks, but all I really want is for it to fail under teh debugger :-( | 11:35.53 |
| Robin_Watts | tor8: ping | 11:56.56 |
| tor8 | Robin_Watts: morning | 12:14.22 |
| Robin_Watts | I'm trying the fitz.h/fitz-internal.h thing. | 12:14.48 |
| | That worked out nicely. | 12:14.52 |
| | The mupdf.h/mupdf-internal.h thing is hairier. | 12:15.03 |
| tor8 | yeah, and I'm not sure there's all that much benefit for the mupdf thing | 12:15.21 |
| Robin_Watts | Mostly because pdfclean/pdfshow want to access into the pdf_document structure. | 12:15.38 |
| | I suspect that it can be made nicer with the addition of just a few accessor functions (pdf_document_version, etc). | 12:16.02 |
| tor8 | well, pdfclean and pdfshow could be made to use the internal header as an exception | 12:16.02 |
| Robin_Watts | Indeed. | 12:16.07 |
| tor8 | but we may want some convenience accessor functions for the xref internals | 12:16.25 |
| Robin_Watts | pdfclean has all the gc stuff in it. | 12:16.42 |
| | I wonder if that would be worth splitting out into a library file; that would remove the need for most of pdfcleans internal fiddling. | 12:17.09 |
| tor8 | we may move parts of pdfclean into the library if we decide we need to save files for the forms project | 12:17.21 |
| | yeah, what you said :) | 12:17.31 |
| | pdf_save_xref with some garbage collection friends? | 12:17.49 |
| Robin_Watts | OK. I'll keep bashing. Hopefully have something for you/sebras to look at later. | 12:17.51 |
| | yeah. | 12:17.56 |
| tor8 | a long time ago we had some more fully fledged pdf saving functions | 12:18.10 |
| | the main diff was saving a buffer for stream objects, so we could update the stream contents as well | 12:18.43 |
| Robin_Watts | We may want to do that for the form filling; if we generate appearance streams, then we'll want to save them out, right? | 12:19.31 |
| tor8 | I wonder if we should save that for post 1.0 or just plow ahead? I'm worried about how stable things will be for the 1.0 release. | 12:19.41 |
| | exactly | 12:19.49 |
| | or if we create annotations | 12:20.00 |
| | (which was the original reasoning for the functionality) | 12:20.11 |
| Robin_Watts | I think that can be post 1.0. | 12:20.15 |
| | because it shouldn't affect the external API. | 12:20.26 |
| tor8 | at least not the basic document api (fz_document) and the graphics api (all the devices) which are what I want to keep stable | 12:20.57 |
| Robin_Watts | The internal/external split is worth doing before 1.0, because it minimises the amount that's frozen. | 12:21.06 |
| tor8 | it also makes the documentation project easier, because it emphasises which parts are meant to be used by clients | 12:21.46 |
| Robin_Watts | Indeed. | 12:21.55 |
| | it looks like most of the stuff that's ended up in fitz.h is nicely documented. | 12:22.17 |
| tor8 | so, fz_new_document_with_stream() should detect file type how? pass in a filename argument that isn't really used? | 12:22.31 |
| | I'd look at the magic in the beginning of the file if it weren't for the fact that both XPS and CBZ use zip files | 12:23.16 |
| Robin_Watts | Pass in a filename/mimetype ? | 12:23.43 |
| | If you get such a stream from (say) a web service, it should have a URL and a mimetype. And we can hope to guess from that ? | 12:24.18 |
| tor8 | yeah, I think a "filename-like" string should suffice | 12:24.41 |
| Robin_Watts | Do you have a use case for this, or is it driven by the potential-customer enquiry ? | 12:24.58 |
| tor8 | pdfapp.c actually :) | 12:25.11 |
| | the windows madness with utf-16 filenames and _wopen | 12:25.25 |
| Robin_Watts | oh, ok. I've managed to remain blissfully ignorant of that. Will strive to stay that way. | 12:25.52 |
| tor8 | also, if/when we get around to pdf portfolios, and I know sumatrapdf uses it | 12:26.03 |
| | for just filenames, we could mandate utf-8 and do the icky bits behind the scenes, which would solve the windows version of pdfapp.c but not the case where you're opening files from a memory buffer | 12:26.56 |
| paulgardiner | tor8,Robin_Watts,henrys: for information on PDF JavaScript, this looks to be a possibly more useful document than the API reference http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/js_developer_guide.pdf | 13:15.16 |
| Robin_Watts | paulgardiner: Thanks. | 13:17.06 |
| | lunch. | 13:37.35 |
| chrisl | reboots | 13:59.22 |
| Robin_Watts | tor8, chrisl: Freetype question... | 14:37.04 |
| | When we render a glyph, it goes into and FT_Face->glyph, and mupdf copies that out. | 14:37.45 |
| | What does FT_DOne_Glyph do ? | 14:38.14 |
| kens | IIRC its Freetype caching, says yo udon't need the glyph any more, but I could be wrong | 14:38.47 |
| marcosw1 | kens: I just sent you an email, but if you are online this is easier: Do we have a guess when PDF-A/2 might be supported? | 14:38.56 |
| Robin_Watts | Ah, ok. | 14:39.00 |
| marcosw1 | I know there will be limitations. | 14:39.10 |
| kens | marcosw1 : I bought the spec yesterday but haven't read it yet. | 14:39.16 |
| | So I don't really know. I got looking at this weiord customer reported bug | 14:39.34 |
| srathbun | Hi all, sorry to interrupt, but I can't seem to find an answer to this anywhere. I'm on a W7 64 bit system, and ghostscript is substituting Courier for CourierNew. Where is the fontmap file I need to edit to have it use the Courier New Regular font W7 has installed? | 14:39.52 |
| kens | You need to add it to Fontmap.GS, and you need GS to use that instead of the built-in font. | 14:40.47 |
| chrisl | Robin_Watts: sorry, was looking at the wrong computer - IIRC, FT_Done_Glyph throws away the glyph specific parts of the glyph slot - so outline, bitmap, bounding box, etc. | 14:41.27 |
| Robin_Watts | OK, I was intrigued as to why mupdf is calling that for stroked glyphs and not for normal ones. | 14:42.32 |
| | For stroked ones we call: FT_Glyph_To_Bitmap then copy the bitmap out into our own cache, then FT_Done_Glyph. | 14:43.10 |
| srathbun | kens: Hmm, I can find various fontmap.* files in the lib folder of my gs install, but no file called Fontmap.GS is there. Do I just copy one of the prebuilt ones? None of them seem to be windows specific. | 14:43.32 |
| Robin_Watts | For normal ones we call: FT_Render_Glyph, then copy the bitmap out, but never call FT_Done_Glyph. | 14:43.38 |
| chrisl | srathbun: if you're using the prebuilt binary, the Fontmap.GS is built into the binary. You need to create a new one (or grab ours from the source archive or git repos) and use the -I command line option to add the directory where the new Fontmap.GS exists to Ghostscript's search path. | 14:43.39 |
| kens | what chrisl said :-) | 14:43.54 |
| chrisl | Robin_Watts: I wouldn't have thought stroked glyphs should be converted to bitmap at all! | 14:44.10 |
| Robin_Watts | We convert them to bitmap in order to render them. | 14:44.28 |
| srathbun | Ah, that explains it. I'll grab a copy and see if it solves my problem. Thanks :) | 14:44.35 |
| chrisl | Robin_Watts: so you use the bitmap as a mask? | 14:44.52 |
| Robin_Watts | Sorry, I mean pixmap, not bitmap. | 14:45.02 |
| chrisl | So what happens if you have a stroked glyph with stuff behind it? | 14:45.25 |
| Robin_Watts | Oh, we use it as a mask in that sense. | 14:46.04 |
| | We convert them to bitmaps with alpha. | 14:46.25 |
| | bah. | 14:46.35 |
| | The pixmaps to which we convert the glyphs have alpha. | 14:46.51 |
| chrisl | Yeh, I knew what you meant ;-) | 14:47.05 |
| | Robin_Watts: does mupdf use the Freetype glyph cache, or implement its own? | 14:48.20 |
| Robin_Watts | out own. | 14:48.35 |
| | our own. | 14:48.37 |
| chrisl | Well, in that case, I'm sure why FT_Done_Glyph would only be called for stroked glyphs. | 14:49.07 |
| Robin_Watts | +not ? | 14:49.20 |
| chrisl | Eh? | 14:49.38 |
| Robin_Watts | I was thinking that maybe you'd missed "not" in that sentence. | 14:50.10 |
| chrisl | You said above that FT_Done_Glyph was called for stroked glyphs, and not for others | 14:50.44 |
| Robin_Watts | Yes. | 14:50.51 |
| | Which seems odd to me. | 14:50.55 |
| | Surely that means that freetype will be keeping cached versions of glyphs around in its cache - which seems wasteful when we are caching them ourselves. | 14:51.44 |
| chrisl | Only if you initialise freetype to use its cache, which I'm assuming you don't | 14:52.19 |
| Robin_Watts | If we tell freetype not to use its cache, why would we call FT_Done_Glyph at all. | 14:52.52 |
| kens | You still need to free the stf that got returned | 14:53.07 |
| chrisl | To free the bitmap, outline etc | 14:53.11 |
| Robin_Watts | Do we not need to do that after Ft_Render_Glyph too ? | 14:53.33 |
| chrisl | Probably should but, IIRC, the worst that should happen is that you might leak the last glyph you use before exiting - I think the first thing freetype does when starting a new glyph is clear out anything laying around from a (possible) previous glyph | 14:54.06 |
| Robin_Watts | Right. | 14:54.29 |
| chrisl | Personally, I would add it in, just for clarity and "rightness" - unless Tor removed it for a reason! | 14:55.19 |
| Robin_Watts | Right. So one to check with tor8. | 14:55.29 |
| | Thanks. | 14:55.40 |
| tor8 | Robin_Watts: in the normal case with freetype you use the glyph slot in the face, which is managed behind your back with the FT_Load_Glyph and FT_Render_Glyph calls | 15:13.05 |
| | in the stroked case we make a copy of the glyph in the glyph slot (or reference count it, not sure about the details) | 15:13.23 |
| Robin_Watts | ok, so it's a deliberate decision, that's fine. | 15:13.40 |
| tor8 | so there we a glyph directly, not via the glyph slot, hence the FT_Done_Glyph | 15:13.44 |
| Robin_Watts | I just fixed (locally) a multithreading issue in that area, hence me spotting it. | 15:14.07 |
| | but they've just given me another one that's proving harder. | 15:14.26 |
| tor8 | we could move to using glyphs directly without using the glyph slot, like chris does in ghostscript (iirc) | 15:14.42 |
| | but I'm not sure it's worth bothering with | 15:14.59 |
| Robin_Watts | We're doing an fz_evict_glyph_cache, and that's dying in FT_Done_Face. | 15:14.59 |
| | no, me either. | 15:15.06 |
| | which suggests that I am getting the font reference counting wrong somehow. | 15:15.39 |
| | Am I reading the code correctly in that when the glyph cache gets full, we bin the entire cache ? | 15:16.15 |
| | tor8: ^? | 15:25.27 |
| tor8 | Robin_Watts: yes. | 15:30.33 |
| Robin_Watts | I could do with another pair of eyes here. I can't see a problem - maybe it will be obvious to someone else. | 15:31.04 |
| | There are 2 threads in the caller. | 15:31.18 |
| | One is busily in fz_scan_convert | 15:31.28 |
| | The one that crashes is in: | 15:31.34 |
| | fz_run_display_list => fz_fill_text => fz_draw_fill_text => fz_render_glyph => fz_evict_glyph_cache => fz_drop_font ->FT_Done_Face -> destroy_face -> cff_size_done | 15:32.30 |
| | My suspicion therefore is that we're destroying a face that's already been destroyed. | 15:33.18 |
| tor8 | double free? any luck running it in valgrind? | 15:33.40 |
| Robin_Watts | I can't reproduce this - it only happens in the customers app, and then not repeatably. | 15:33.59 |
| tor8 | draw_glyph.c:192: fz_keep_font(key,font) | 15:35.09 |
| | key.font | 15:35.13 |
| | possible race condition there? | 15:35.27 |
| Robin_Watts | We hold the glyphcache lock at that moment. | 15:35.45 |
| tor8 | i.e. we insert it before we keep it | 15:35.51 |
| | right, so not that one | 15:35.55 |
| | and since we keep it, the reference count should not drop unless we're miscounting elsewhere | 15:36.22 |
| Robin_Watts | The refcount on fonts is protected by the alloc lock. | 15:36.41 |
| | but someone calls fz_render_glyph and passes the font in, so they must have a reference to it. | 15:37.21 |
| | And that can't go away until we exit, so we should be fine. | 15:37.31 |
| | Actually, refcounting would seem an odd candidate for going wrong here. | 15:37.52 |
| tor8 | stale fonts from old pages that remain in the glyph cache, have their own refcount so should also be safe | 15:37.58 |
| Robin_Watts | We only drop the font when the refcount goes to 0. | 15:38.05 |
| | hence we'd have to go to zero more than once. | 15:38.17 |
| | which seems unlikely. | 15:38.23 |
| tor8 | so we should only drop fonts in the eviction if they're stale ones with no surviving holders other than the cache | 15:38.38 |
| Robin_Watts | Yes. | 15:38.45 |
| tor8 | at least that's what I can see from looking at the code | 15:38.57 |
| | it doesn't rule out a missing freetype lock in fz_drop_font though | 15:39.32 |
| | but you take that lock as well inside fz_drop_font | 15:39.54 |
| | so I really have no idea | 15:40.01 |
| henrys | chrisl:I already talked to them they are 15,000 US each face. | 15:40.44 |
| Robin_Watts | I'm going to speak to the customer to see if this is his only crash at the moment - if it isn't then it's possible that something else is tromping on memory. | 15:40.54 |
| chrisl | henrys: Okay, I've no idea if that's good or bad..... | 15:41.24 |
| henrys | chrisl:my concern is we get another customer that wants say a chinese face - in fact I did look up a printer on the internet. | 15:41.29 |
| | it's a lot for fonts. | 15:41.44 |
| chrisl | Yeh, but work it out on a "per glyph" basis...... | 15:42.03 |
| Robin_Watts | henrys: And we need how many fonts? | 15:42.10 |
| chrisl | At least four, right now | 15:42.24 |
| Robin_Watts | hehe. We should do a 'kickstarter' project to fund it. | 15:43.29 |
| henrys | the issue is most of these companies have already been sold the ufst and have rights to it. This new customer is the first I've seen without it. | 15:45.23 |
| | I'd like to ask the new company what font list they want to have on their printer. | 15:46.23 |
| | I'll ask Scott to ask them. | 15:46.50 |
| chrisl | They specifically mentioned the "MS family" which is the four variants of Mincho and Gothic. | 15:47.14 |
| henrys | Okay I think we'll tell them we can get those four fonts, and we'll worry about others as the opportunity presents. | 15:49.53 |
| Robin_Watts | henrys: We could always offer to source the fonts for them and pass (some/most/all) of the charge along to them. | 15:49.55 |
| henrys | I'll leave that to Scott and Miles, the fonts will be AFPL - that's a shame. | 15:51.25 |
| chrisl | There isn't the option to do them under a tighter license? | 15:52.28 |
| Robin_Watts | I wonder whether a kickstarter project would make sense. I said it as a joke, but... | 15:52.33 |
| | Are there enough CJKV linux users out there who would support such a project... | 15:53.19 |
| | Presumably if we got them for $15000 each, we could release them under the GPL as well as keeping the rights to distribute them commercially? | 15:53.53 |
| henrys | I am not familiar with how kickstarter works | 15:54.07 |
| chrisl | There are already a couple of reasonable quality Japanese fonts out there, plus the Android ones now, not sure how much more people would want | 15:54.14 |
| Robin_Watts | kickstarter: Anyone can put projects up, and invite backers. backers pledge money. If the pledges reach a target, the project is a go. | 15:54.58 |
| henrys | these companies are going to look at quality logic tests and a fiasco like say the cyrillic changes is not going to fly. | 15:55.19 |
| Robin_Watts | henrys: I'm not sure what that's a response to. | 15:56.00 |
| henrys | oh using free fonts. | 15:56.25 |
| Robin_Watts | Ah, right. | 15:56.34 |
| | Companies might want exactness. The issue that I think Chris was highlighting is that your average CJKV linux user probably doesn't particularly care. If the existing fonts are 'good enough' they will not be inclined to pledge money to get better ones. | 15:57.55 |
| chrisl | Yes, exactly | 15:58.14 |
| henrys | after more thought the money isn't much of a big deal, it's more expensive than lating but per glyph I imagine it about the same. | 15:58.20 |
| chrisl | There are fonts under quite a liberal free license from IPA (I think) in Japan, and the quality seems good - *but* I can only find one variant each of Mincho and Gothic, | 15:59.16 |
| henrys | who is going to make GPL fonts? | 15:59.17 |
| Robin_Watts | henrys: What would we get for $15000? Would we get the rights to release that font as GPL? or bsd ? | 15:59.51 |
| henrys | no like I said AFPL | 16:00.06 |
| | so the open source community won't touch them. | 16:00.16 |
| Robin_Watts | Right. So no chance of kickstartering then. | 16:00.29 |
| chrisl | henrys: Never mind GPL, I'm surprised that there are fonts available under considerably more liberal licenses than GPL | 16:01.29 |
| henrys | we've asked them to do GPL - AFPL (no commercial use) is as far as they'll go. | 16:02.22 |
| | for us the GPL works because of linking - fonts aren't linked. | 16:02.54 |
| | chrisl:there are a total of 4 fonts for the Gothic and Mincho or 4 each. | 16:05.33 |
| Robin_Watts | mkromfs puts fonts into the binary blob, and that gets linked to the gs exe. | 16:05.54 |
| chrisl | henrys: for out purposes, a total of 4 (2 Mincho and 2 2Gothic). The Windows versions also come with a third font in each collection tailored for screen use, so not relevant for us. | 16:06.30 |
| | s/out/our | 16:06.36 |
| henrys | Robin_Watts:what I mean was URW's perspective of how fonts are commonly used, the gpl is not an attractive license for them as it is for us. | 16:06.48 |
| Robin_Watts | ok. | 16:07.04 |
| chrisl | henrys: we also have the option of just waiting to see if the customer comes up with a solution..... | 16:08.58 |
| henrys | I'll just give the info to Scott and Miles at least they can tell the customer we can get the fonts if they need them. | 16:09.16 |
| | I'd have to check with tkampetter but I think we could get the fonts and they would be available for proprietary download like some drivers, flash etc. | 16:10.51 |
| chrisl | It is just possible that we might encounter a potential Japanese customer who has a UFST license, but would relish the idea of stopping paying Monotype...... | 16:10.57 |
| henrys | this is linux I'm thinking of | 16:11.04 |
| chrisl | Ubuntu would be fine with that. They could probably get into the "non-free" Debian repository - don't know about Fedora, Suse etc...... | 16:11.53 |
| henrys | we've run into a few that have done buyouts and exactly the opposite is the case but you may be right. | 16:11.57 |
| chrisl | Ah, I didn't think Monotype did that - they certainly weren't willing to discuss it with Global (at least, that's what I was told) | 16:12.58 |
| Robin_Watts | tor8, sebras: I've just pushed a commit to my repo on casper that does the internal/external API split. | 16:14.45 |
| henrys | I'd like to talk to tkamppeter about that, if he thinks the fonts would get a lot of use that way I think the marketing is well worth the cost of the fonts alone, even without a customer. | 16:14.45 |
| Robin_Watts | tor8, sebras: Any thoughts you may have on it, much appreciated. | 16:15.58 |
| | Several of the tools (notably the ones that mess inside pdf_document still use mupdf-internal.h | 16:16.56 |
| tkamppeter | henrys, what do you plan to do with fonts? | 16:23.48 |
| henrys | I would like them to be available as an "add-on" to ghostscript for asian users. | 16:24.23 |
| | or anyone that wants to use the fonts. | 16:24.36 |
| | but the license would be "non commercial use" - Aladdin's license | 16:25.59 |
| | bb in a minute. | 16:26.22 |
| | of course the fonts aren't specific to ghostscript they are just tt fonts, gothic and mincho | 16:29.45 |
| | sigh pcl bug | 16:33.24 |
| | more with this shared library business, now we can't garbage collect jpeg memory ? | 16:35.52 |
| chrisl | We don't garbage collect that memory, anyway | 16:36.31 |
| henrys | oh alright good | 16:36.50 |
| chrisl | We'll still garbage collect *our* stream stuff, but the libjpeg memory is allocated and freed in libjpeg | 16:37.27 |
| srathbun | Chrisl and everyone else, thanks for all the help. After way too many issues on my end getting the fontmap file, my problem is solved. :) Is there a wiki for GS where I can leave some notes for this? | 16:38.18 |
| chrisl | srathbun: we have a (developing) FAQ, if you want to pen some words for that, we'd be most grateful! | 16:39.08 |
| henrys | tkamppeter:so if you think the typefaces would get a lot of use we'd lean towards buying them. | 16:39.59 |
| srathbun | Would that be the postscript wiki book faq chrisl? | 16:41.00 |
| chrisl | srathbun: No, but if you add an entry there, I can pick it up for our FAQ, too | 16:41.40 |
| tkamppeter | henrys, what do you mean? Is Artifex buying fonts and releasing them as free software? | 16:42.18 |
| srathbun | Hmm, I'd rather add it to the official FAQ, since the problem isn't really postscript related. Do you have a preference for how I should send you the details? | 16:42.33 |
| chrisl | srathbun: if you send it to chris.liddell (at) artifex.com | 16:43.11 |
| henrys | tkamppeter:we would be willing to buy fonts from URW and release them but they will have an AFPL license. | 16:43.21 |
| srathbun | chrisl: will do | 16:43.59 |
| henrys | the license restriction is from URW not us. | 16:44.20 |
| Robin_Watts | paulgardiner: Looks like the javascript stuff is keystroke based... | 16:45.36 |
| tkamppeter | henrys, this way we cannot ship them on our distribution, we also were not able to ship AFPL Ghostscript in former times. | 16:46.03 |
| | henrys, what would be needed is the same dual-licensing as Ghostscript itself has. | 16:46.58 |
| Robin_Watts | tkamppeter: Alas, we are not in control of the fonts enough to do such dual licensing. | 16:47.27 |
| henrys | right I was hoping they would be put in the "proprietary" repository that everyone uses after installing ubuntu but maybe you don't handle that. | 16:47.27 |
| Robin_Watts | The font vendor will not allow GPL release of the fonts. | 16:47.42 |
| henrys | tkamppeter:presumably the fonts would be installed like flash or proprietary graphics drivers. | 16:48.39 |
| tkamppeter | henrys, Robin_Watts, so distro-wise you should then publish the fonts in a separate "enhanced-fonts" package. So distributions can generally ship ghostscript in their main part and, if they have a non-free part, like Ubuntu, ship the "enhanced-fonts" in the non-free part. | 16:49.38 |
| Robin_Watts | And such a solution would be of use to Ubuntu ? | 16:50.17 |
| | tkamppeter: We are trying to judge if this is worth it. If it is, we will consider spending the money. If not, we may not bother. | 16:50.42 |
| marcosw | henrys: I have a doctor appointment at 9:30, can we do the support meeting now (or skip it for this week)? | 16:52.05 |
| henrys | I'm pretty busy | 16:52.22 |
| | skipping would be my first choice. | 16:52.32 |
| tkamppeter | Robin_Watts, henrys, I do not know the exact criteria for when a non-free and for Ubuntu free-of-charge package goes into the non-free part. Especially for the live CDs there will also be a space problem. | 16:52.44 |
| | Robin_Watts, henrys, what is the advantage of these enhanced fonts against the ones which come in the Ghostscript package? | 16:53.20 |
| marcosw | works for me, we'll do it next friday. | 16:53.24 |
| henrys | tkamppeter:do you know who manages the non free stuff? | 16:53.43 |
| Robin_Watts | tkamppeter: None of the standard gs fonts include CJKV support, AIUI. | 16:53.53 |
| henrys | tkamppeter:there japanese fonts not included in the standard set of fonts. | 16:54.20 |
| Robin_Watts | (unless we ship DroidSansFallback now ?) | 16:54.27 |
| henrys | s/there/they're | 16:54.42 |
| chrisl | we do ship DroidSansFallback | 16:54.47 |
| Robin_Watts | chrisl: yeah, just found it :) | 16:55.02 |
| henrys | they would certainly be an improvement over DroidSansFallback | 16:55.04 |
| | so the "advantage" would be improved printing when using mincho and gothic - in particular better metrics - spacing. Chrisl may know some other advantages. | 16:58.13 |
| Robin_Watts | tkamppeter: Is there a japanese Ubuntu maintainer? Presumably it may be worth us speaking to them if there is. Perhaps there is already a solution to this that we are unaware of. | 16:59.24 |
| tkamppeter | henrys, Robin_Watts, OK, I have no appropriate contacts but I can ask who are the right people. | 17:00.04 |
| henrys | thanks | 17:00.14 |
| Robin_Watts | tkamppeter: Thank you | 17:00.16 |
| | http://ubuntuforums.org/showthread.php?t=519493 | 17:00.48 |
| | http://ubuntuforums.org/showthread.php?t=812552 <- says "Go and download MSGothic/MSMincho manually" | 17:02.21 |
| henrys | but the link is dead interesting though | 17:03.55 |
| | I see sites where you can download mincho but they look suspicious - why would microsoft give away this font. | 17:06.39 |
| | ? | 17:06.41 |
| Robin_Watts | Ugh. Looks like there are 2 types of PDF forms; Acrobat forms, and Adobe LiveCycle Designer forms (XML form object model) | 17:06.54 |
| | and the latter comes in 2 forms Static and Dynamic</pirsig> | 17:07.08 |
| sebras | Robin_Watts: I'll have a look at your split later tonight. | 17:07.37 |
| henrys | chrisl:maybe the free fonts is a good research project for you, I think you said you were going to have a look. | 17:07.39 |
| chrisl | henrys: OKay, I'll look into it..... | 17:08.03 |
| henrys | Robin_Watts:anything on the path stuff? | 17:08.53 |
| Robin_Watts | henrys: No. I've been mupdf wrangling all day. | 17:09.10 |
| henrys | anything I can do. | 17:09.12 |
| | okay | 17:09.15 |
| Robin_Watts | sebras: Thanks. | 17:09.18 |
| | I can't really do more on mupdf until I know whether tor8/sebras are going to veto the split or not, so I thought I'd try and read up on this pdf/javascript forms thing a bit. | 17:10.06 |
| sebras | I'm not really in a position to veto anything, so you are really only waiting for tor8... :) | 17:10.40 |
| Robin_Watts | sebras: Yes, but your opinion counts. | 17:10.59 |
| | Ah, so keystroke events aren't really keystroke events; they are 'changed' events. | 17:21.27 |
| | And they specifically cope with pastes. | 17:21.36 |
| | Any my head explodes with javascripty eventy stuff. | 18:38.22 |
| | s/Any/And/ | 18:38.32 |
| | Time look at HPGL paths for some light relief. | 18:38.45 |
| mvrhel | another cluster push that hopefully will not explode. I think I have this user params stuff figured out now henrys. At least I will know when it completes | 18:55.47 |
| henrys | mvrhel:take your time - I have put my language changes off on a branch and can merge them in any time. | 18:59.04 |
| mvrhel | ok thanks | 18:59.16 |
| | working on output intent too. | 18:59.47 |
| | well, I only took down 2 nodes so far.... | 19:16.06 |
| ray_laptop | I saw the discussion about AFPL fonts -- both AFPL and GPL have 'viral' natures -- which makes them incompatible, but we don't _have_ to put AFPL fonts into the romfs -- they can reside on disk (in fact, given the size it probably makes sense not to bloat the executable) | 19:30.09 |
| Robin_Watts | ray_laptop: But presumably, if we buy fonts, we get them both under AFPL and for our own commercial use. | 19:38.32 |
| ray_laptop | Robin_Watts: yes, commercial won't be a problem. | 19:39.08 |
| | Robin_Watts: BTW, on the simulator, I set the BandHeight up to 15000 (single band per page) and the WWTT file is only a disappointing 3% faster (with do_no_output = 1 so disk writing isn't part of it) :-( | 19:49.12 |
| Robin_Watts | Oh, that's a shame :( | 19:49.43 |
| | I suppose I ought to look at the revised profiles he sent at some point. | 19:50.17 |
| ray_laptop | Robin_Watts: can you think of any reason we shouldn't get rid of the cfe compression of tiles in the clist ? Most customer use disk and the increase in file size is a *don't care* | 19:54.07 |
| Robin_Watts | If what you've just said is true, then no :) | 19:54.38 |
| ray_laptop | Robin_Watts: and the performance for text is quite dramatic -- it'll even help all the other parsers | 19:54.39 |
| | Robin_Watts: we don't have very many customers using memory based clist -- and we can always add it back (and it won't be needed at all once I fix the tile storage in the clist) | 19:56.38 |
| | Robin_Watts: since it's your change, I'll let you put in the patch (unless you are too busy and want me to) | 19:58.53 |
| Robin_Watts | ray_laptop: Go for it. I'm neck deep at the moment in debugging. | 19:59.38 |
| ray_laptop | Robin_Watts: OK. I'll mention you in the logs :-) | 20:00.01 |
| henrys | ray_laptop:I suggested dropping the compression for your customer but I don't think a recent pcl customer would be pleased with that, but it hasn't really been quantified. presumably marcosw can record "peaks" for all the tests then we can make a decision. | 20:00.02 |
| ray_laptop | henrys: we only get the clist size out with -Z: from a debug build, but I'm sure marcos could quantify the size differences. After all we all know size matters ;-) | 20:01.36 |
| | henrys: but _could_ make it the default IFF we are using memory based clist -- what do you think of doing that ? | 20:02.11 |
| henrys | ray_laptop:that sounds quite reasonable. | 20:02.49 |
| ray_laptop | henrys: OK, I'll do it that way then. | 20:03.06 |
| henrys | ray_laptop:will we be able to get your customer using full page? your talking about using 1 large band but that is still significantly slower than fullpage. | 20:03.37 |
| ray_laptop | henrys: I'll do timing on the simulator for full page to see how much that might help for this case | 20:04.18 |
| | they've been resistant to that, but if I have performance numbers, I might be able to push them to it. | 20:05.05 |
| henrys | chrisl said you can get peak memory usage on linux with the "time command" so it should be easy to incorporate memory usage into the tests. | 20:05.13 |
| | it doesn't seem to work properly on mac os x | 20:05.34 |
| mvrhel | bbiab grabbing lunch | 20:08.06 |
| Robin_Watts | henrys: Testing a path fix now. | 20:10.17 |
| henrys | oh cool - a few hours with javascript was all the motivation needed. | 20:10.49 |
| ray_laptop | henrys: it won't change memory usage if we are using disk based clist. | 20:11.54 |
| henrys | ray_laptop:are we talking about full page or compressed fonts | 20:12.41 |
| | ? | 20:12.42 |
| ray_laptop | henry tiles in the clist (bitmaps of glyphs) | 20:13.01 |
| henrys | right okay. | 20:13.13 |
| | ray_laptop:how is karen doing? | 20:17.08 |
| | Robin_Watts:sabrina wants to stay at a sheep farm for a day or so while we are in the UK, generally I distrust all farm animals but I'll do it for her. | 20:18.57 |
| Robin_Watts | ray_laptop: Sanity check me... their latest profile shows 2s of time (out of 48s total) spent in gs_return_check_interrupt. And all that does is call gp_check_interrupts, which only accounts for 0.19 seconds. | 20:19.05 |
| | henrys: ? | 20:19.10 |
| | Does she have a specific sheep farm in mind ? | 20:19.21 |
| | or just any farm as long as there are sheep? | 20:19.41 |
| henrys | yes she found one on the net with good rating, sort of like a bed and breakfast --- but with sheep | 20:20.10 |
| | I have 2 collies - I could bring them ;-) | 20:20.36 |
| Robin_Watts | Right. Lots of farms do B+B. | 20:20.42 |
| | henrys: You think it's hard to export crypto code from the US? That's NOTHING compared to transporting dogs into/out of the UK :( | 20:21.10 |
| | Whereabouts in the UK is the farm ? | 20:21.34 |
| | Sheep farms are in the news at the moment. We have a viral outbreak that has potential to decimate lambs (lots are born deformed etc). | 20:22.20 |
| henrys | http://www.broadway-cotswolds.co.uk/sheepscombe.html | 20:23.33 |
| Robin_Watts | Ah. My parents live in the next village :) | 20:23.52 |
| henrys | she is also cooking up something with Helen to do in Oxford I think. | 20:23.59 |
| Robin_Watts | Broadway is very picturesque. | 20:24.38 |
| | and the countryside there is lovely. | 20:24.47 |
| henrys | yes she's hoping to get some pictures for her painting. | 20:24.59 |
| Robin_Watts | I don't know what peoples travel plans are, but anyone who is around (and awake) is welcome to come visit for a proper english Sunday Lunch. | 20:26.42 |
| henrys | so that's a particular type of meal? | 20:34.51 |
| Robin_Watts | It's a style of meal. | 20:35.05 |
| | It basically involves eating until you can't physically move. | 20:35.18 |
| | Don't worry, I promise no Haggis, Black Pudding, or offal. | 20:35.53 |
| henrys | I was just about to ask about that. | 20:36.07 |
| Robin_Watts | Bah. 4500 diffs. | 20:36.28 |
| mvrhel | Robin_Watts: I think I am arriving Saturday | 20:45.57 |
| | How far is it to Sunday Lunch | 20:46.13 |
| Robin_Watts | mvrhel: I'm 90 minutes drive from Heathrow. | 20:46.32 |
| mvrhel | ok. well if I can get things coordinated, I would love to come visit | 20:47.43 |
| Robin_Watts | Cool. You'd be more than welcome. | 20:47.58 |
| mvrhel | thanks. I need to talk to Stephanie to see if she wants to come. I don't think that is going to work due to issues with getting grandparents here to watch the kids, but i need to check first | 20:49.26 |
| Robin_Watts | Well, she'd be welcome as well, obviously. | 20:50.42 |
| mvrhel | Thank you | 21:00.38 |
| Robin_Watts | henrys: Do my bmpcmps make any sense to you? | 21:05.11 |
| | Clearly some of them are still wrong. Will look more on monday. | 21:05.57 |
| henrys | Robin_Watts:I'll have a look. | 21:08.44 |
| Robin_Watts | don't worry about it. It was just the first couple that were odd; one adds a lot of content, one removes it. | 21:09.26 |
| | but later ones show definite mistakes. | 21:09.35 |
| henrys | it looks to me like you aren't doing closepath right. | 21:13.55 |
| | that would account for missing joins and characters. | 21:14.25 |
| | in you bmpcmp | 21:14.35 |
| mvrhel | aha! looks like my remaining issues are from patterns with softmasks | 21:22.14 |
| | fun | 21:22.26 |
| | a clean up issue remains with the icc profile swapping when the pattern is done | 21:22.53 |
| henrys | I have a couple of uk friends here and they speak highly of Bathe so we're adding that to our tour also. | 21:26.12 |
| | mvrhel:sounds nasty | 21:27.59 |
| mvrhel | and getting nastier. very confusing case | 21:28.15 |
| | graphic state pushes in the soft mask | 21:28.36 |
| | and the clist thrown in for good measure :) | 21:29.10 |
| | actually with the debugging statements that I have in the icc and transparency code now, it is not going to be too bad to figure out | 21:30.09 |
| | Robin_Watts: you still up? | 22:28.15 |
| | memento question for you | 22:28.24 |
| | imaging that 10pm on a Friday night Robin_Watts is hopefully off having fun someplace | 22:29.28 |
| | oh reading comments in memento.h I think I have this figured out | 22:31.15 |
| | hmm wondering how I add in Memento_breakAt | 22:32.32 |
| | henrys: have you done this before? | 22:35.59 |
| henrys | no I haven't used that feature | 22:44.54 |
| mvrhel | ok | 22:45.01 |
| | off to get kids. bbiab | 22:46.56 |
| | hmmm this things seems to be chugging along . | 22:50.18 |
| | Forward 1 day (to 2012/03/03)>>> | |
IRC Logs