| | <<<Back 1 day (to 2012/05/02) | 2012/05/03 |
| diverdude | How can i merge all pdf's in a dir into a single pdf? | 00:01.29 |
| alexcher | I'm back. | 02:11.53 |
| rayjj_ | alexcher: me to | 06:22.09 |
| | me too | 06:22.11 |
| | I landed at about the same time as alex got all the way home. I was home about 1 hr after that. | 06:22.57 |
| norbertj | hello rayjj_ | 07:03.48 |
| | I have a question on 693001, do you know when you are going to look at it. We are waiting for a fix fot this, so we can switch from 9.04 to 9.05 | 07:04.53 |
| kens2 | ping chrisl | 08:09.19 |
| chrisl | kens2: pong | 08:14.37 |
| kens2 | Too late :-) | 08:14.47 |
| | I found the answer to my question. | 08:14.54 |
| chrisl | Sorry, working on the other computer..... | 08:15.01 |
| kens2 | A particular patch was *not* included in 9.05 | 08:15.03 |
| | NP | 08:15.11 |
| chrisl | Is this the merging PDFs with transparency thing? | 08:15.45 |
| kens2 | No, its the incompatible pdfwrite options | 08:15.56 |
| | Now it gives a warning and ignores one, previously it gave an error and stopped | 08:16.16 |
| | I thought Alex closed the transparency thing, unless that was a different bug | 08:16.51 |
| chrisl | I thought you closed it..... | 08:17.28 |
| kens2 | I did, Alex re-opened it | 08:17.37 |
| | I just closed it again | 08:18.00 |
| chrisl | Yeh, just saw the e-mail. | 08:18.15 |
| kens2 | The code didn't make it into 9.05, but it is in the trunk | 08:18.32 |
| | The subject is misleading on that bug, because it has nothing to do with transparency at all | 08:19.14 |
| chrisl | Well, only so much can go into each release, or we'd never release anything....... | 08:19.25 |
| kens2 | Exactly. | 08:19.31 |
| | I now remember you asking if it was important to get in and I decided not to bother, because it was so long-standing an issue | 08:19.54 |
| chrisl | As long as it works now, the user can always himself a snapshot....... :-) | 08:20.50 |
| kens2 | I've pointed them at a patch, and suggested several options. THe weasy one is to drop the nicompatible options. | 08:21.19 |
| chrisl | "But this is how I want to call GS, so *you* must be wrong".......... | 08:21.59 |
| kens2 | Yep. Did you look at his command line ? multiple incompatibilities, options that override other options.... | 08:22.28 |
| | I bet he has no idea what he's doing with those | 08:22.36 |
| chrisl | No, but it can be hard to blame the user entirely - with such a bewildering number of command line options, who *does* know them all properly? | 08:24.00 |
| kens2 | Nobody, but that's no excuse for sending an alphabet soup | 08:24.21 |
| | If you don't know what it does, don't use it "Do not press this button again" | 08:24.41 |
| chrisl | It would certainly make things easier on us if folks would start with the assumption they are wrong, and disprove it - rather than the assumption GS is wrong, and have us disprove that. | 08:28.56 |
| kens2 | I'm tempted to add a new switch that does nothing but produce an error message 'do not use this switch' | 08:29.28 |
| | And tehn wait to see how many bug reports come in | 08:29.41 |
| chrisl | And if you use it a second time, it eats your hard disk? | 08:30.18 |
| kens2 | Tempting.... | 08:30.26 |
| | Maybe I could just have it eat Ghostscript "You are too stupid to be allowed to use this software..." | 08:31.00 |
| | Though I'm wondering about the help desk people on an online game. | 08:31.38 |
| | I wanted to track ther progress of a bug report, so I went to login to the site. | 08:31.54 |
| | Realised I couldn't remember my password. | 08:32.01 |
| | So I clicked the 'lost password' link, typed in my email address and pressed 'submit' | 08:32.23 |
| | I then got an error 'captcha does not match'. Note that there *is* no captcha on the page.... | 08:32.44 |
| | SO I opened a ticket for that too. | 08:32.52 |
| | So they asked me to send a screen shot, which I did. | 08:33.03 |
| | Now they want to know if I have tried another browser. | 08:33.17 |
| | What's wrong with just going to the page and trying it ? | 08:33.26 |
| chrisl | They probably have orders to avoid passing issues up to the technical people, so they are trying to put you off going further..... | 08:35.27 |
| kens2 | You're probably right. Isn't going to work though :-) | 08:35.49 |
| chrisl | You could be stubborn, and send them a link to their own page | 08:39.54 |
| kens2 | I already did, this time round I asked them what browser they were using to view the page, because that clearly must work | 08:40.29 |
| | I wonder if MiKTeX pdfTeX uses cairo. | 08:41.24 |
| | Ah, clearly it does, that explains the barking mad PDF file. | 08:49.20 |
| | Alex was only partially correct about the 'merging transparent PDF files' bugs. The output from pdfwrite works fine in Ghostscript, but not in Acrobat. | 08:54.37 |
| chrisl_x100e | So, power, cable and phone all dead - this could be bad.... :-( | 08:59.05 |
| kens2 | Oh, definitely not good | 09:00.56 |
| | We had trouble getting home yesterday, fire in a cable run on the railway. COuld be something similar (though how anyone started a fire round here escapes me....) | 09:02.04 |
| | Morning tor8, good flight home ? | 09:02.49 |
| chrisl_x100e | There a road dug up just round the corner, so I would bet the digger has just yanked up all the utility conduits, or something | 09:03.06 |
| kens2 | Probably dropped a pneumatic drill into it... | 09:03.24 |
| tor8 | hi kens. it was reasonable enough. but they wanted to charge GBP 80 to get on an earlier flight! | 09:03.25 |
| kens2 | tor8 yeah, rip-off Britain.... | 09:03.37 |
| tor8 | waiting an extra hour in an otherwise already ruined by travel day isn't worth paying 80 pounds to avoid | 09:04.20 |
| kens2 | Nope, definitely not | 09:04.32 |
| | 8 hours would be different.... | 09:04.45 |
| Robin_Watts | Morning all. | 09:13.38 |
| kens2 | Morning Robin_Watts | 09:14.07 |
| Robin_Watts | tor8: malc_ reported a bug on here with a type3 font getting the baselines all wrong. | 09:14.11 |
| | sebras tracked it back to your y-flip commit. | 09:14.23 |
| chrisl_x100e | Well, I might as well go out for a couple of hours - shame it's such sh*tty weather :-( | 09:19.30 |
| sebras | Robin_Watts: the one I bisected to yesterday? | 09:29.00 |
| Robin_Watts | yup. | 09:29.07 |
| tor8 | Robin_Watts: sebras: damn! | 09:29.13 |
| sebras | tor8: indeed. | 09:29.22 |
| tor8 | I thought I checked type 3 baselines when I did that change | 09:29.27 |
| sebras | tor8: malcs pdf is in the logs. if it's gone I have a copy. | 09:29.54 |
| Robin_Watts | I thought I remembered it breaking and then being fixed. | 09:29.55 |
| sebras | I did an experiment where I checkout master and reverted only that old commit. | 09:31.30 |
| | tor8 Robin_Watts: but when doing so I _still_ got the wobbly baseline... | 09:31.50 |
| | that surprised me a bit. | 09:31.57 |
| tor8 | Robin_Watts: at least it's unrelated to the 1/2 pixel uv offset voodoo! | 10:16.36 |
| Robin_Watts | tor8: ah, good. | 10:18.15 |
| | When did we start gridfitting images? | 10:18.46 |
| tor8 | if I turn off the entire image scaling it looks like they align properly | 10:19.49 |
| | we don't grid fit inside type 3 fonts, so it may be the image scaling with the subpixel offsets | 10:20.32 |
| | but I recall changing the y-flip order in there too | 10:20.43 |
| | and if I force grid fitting the baseline looks stable | 10:22.22 |
| | (at line 1016 in draw_device.c) | 10:22.57 |
| | Robin_Watts: hm, maybe the grid fitting needs to be adjusted for the y-flip as well? I don't see how, but I'm not very familiar with that bit of the code. | 10:25.10 |
| Robin_Watts | tor8: I don't see how. | 11:41.49 |
| | All I do is tweak the matrix so that the image origin is on a whole pixel, and the transformed image width/height are integers. | 11:42.31 |
| | Has anyone else got Visual C++ 2010 Express installed? | 11:44.17 |
| paulgardiner | Robin_Watts: I do. I haven't been following this thread though, so I'm not sure what you are asking. | 11:52.23 |
| Robin_Watts | paulgardiner: This is unrelated. | 11:52.35 |
| | I was writing some instructions to tell people how to build ghostscript for windows using free tools. | 11:53.10 |
| | (In particular, I want to cover how to build 64bit ghostscript, and none of the express things support that by default) | 11:53.45 |
| | With 2010 Express it's a fairly simpler matter though; you download and install the windows SDK. | 11:54.20 |
| | but that means you have to let 2010 express convert the solution file from VS2005 to VS2010 - and that fails for me. | 11:54.50 |
| | paulgardiner: Do you have a local git repo for ghostscript ? | 11:55.04 |
| paulgardiner | No I don't :-( | 11:55.25 |
| Robin_Watts | ah, well. | 11:55.40 |
| paulgardiner | Is it huge? | 11:55.52 |
| Robin_Watts | Not stupidly so. | 11:56.07 |
| paulgardiner | Wouldn't killl me to clone it then. | 11:56.28 |
| | I'm in a particularly good mode just now because I just asked v8 to execute "var display=this.getField('Display'); display.value='Hello'" and Hello appeared in calc.pdf's display. :-) | 11:58.06 |
| | s/mode/mood/ | 11:58.16 |
| Robin_Watts | excellent! | 11:58.17 |
| paulgardiner | So, worth my cloning gs, do you think? | 11:58.55 |
| Robin_Watts | if you wouldn't mind. | 11:59.05 |
| | Let me get you the remote address... | 11:59.16 |
| | (just attempting to count it :) ) | 11:59.31 |
| | paulg@ghostscript.com:/home/git/ghostpdl.git | 12:00.23 |
| paulgardiner | Ah, via ssh. Right. | 12:00.59 |
| Robin_Watts | tor8: I had an idea about linearisation. | 12:02.25 |
| | We add a new function pointer to the lock structure. | 12:02.50 |
| | Whenever we run out of data in the file, we call that function. | 12:03.10 |
| | That can either sleep (until new data appears, in which case the code will block), or it can throw an exception. | 12:03.47 |
| | I think that covers our bases in terms of functionality, and keeps us thread lib agnostic. | 12:04.56 |
| kens2 | power back chrisl ? | 12:05.24 |
| chrisl | Yes, power came back about an hour ago, phone and cable back in the last 10 minutes - fingers crossed it stays that way..... | 12:06.03 |
| paulgardiner | Robin_Watts: I have ghostpdl master checked out. | 12:11.55 |
| Robin_Watts | Ok. Start Visual Studio 2010 Express | 12:20.27 |
| | File -> open -> Solution/Project... -> win32/ghostpdl.sln | 12:20.53 |
| | That should bring up the project conversion wizard. | 12:21.21 |
| | If you next/finish through that, what happens? | 12:21.28 |
| kens2 | Oh God, I must be tired... Spent 2 hours debugging a problem to discover its because I failed to move a list pointer to the next item before freeing the current item :-( | 12:22.41 |
| paulgardiner | Robin_Watts: hang on. Microsoft want me to register to continue using it. Free so not a problem. | 12:23.08 |
| | Robin_Watts: all projects converted successfully with some warnings | 12:26.39 |
| | All the vcproj conversions generated 17 warnings. | 12:27.12 |
| | If that sounds more successful than on your machine, maybe I can email you a patch. | 12:27.56 |
| Robin_Watts | yeah. | 12:29.10 |
| | For me, I ended up with the solution explorer showing lots of "not loaded" | 12:29.36 |
| | Don't worry about a patch. | 12:30.06 |
| | I'll finish the docs, and maybe you could run through them to test them? | 12:30.29 |
| paulgardiner | Sure | 12:31.02 |
| chrisl | Robin_Watts: Did you have files open in the editor before? I've had converted projects that gave errors because (for some reason) the editor couldn't find the files when it tried to reopen them. | 12:31.25 |
| Robin_Watts | chrisl: No. I thought of that... | 12:31.37 |
| | I suspect I need to reinstall my copy of VS Express | 12:31.49 |
| chrisl | Well, FWIW, I think I have VS2010 express on my laptop..... | 12:32.32 |
| kens2 | I did have a copy, somewhere... I can probably find it if required. | 12:34.13 |
| jellenagels | hi guys! | 12:36.32 |
| | anyone from MuPDF here ? | 12:36.40 |
| Robin_Watts | Sure. | 12:36.46 |
| jellenagels | Nice. Over a week ago, someone from the company where i work sent you guys an email to check on how the commercial license would work. | 12:37.41 |
| kens2 | WHich company ? and where did the query go ? | 12:38.01 |
| Robin_Watts | jellenagels: Are you at liberty to say what company? (So I can search) | 12:38.06 |
| jellenagels | We haven't got an email back yet, so i wanted to check if it came through | 12:38.28 |
| Robin_Watts | and as Ken says, to what address did the enquiry go ? | 12:38.40 |
| kens2 | can you tell us the ocmpany name, or the name of the person who sent the email ? | 12:38.46 |
| jellenagels | The name of the person was Peter Minne | 12:38.58 |
| kens2 | Don't recall that one, let me check | 12:39.10 |
| Robin_Watts | jellenagels: We have a range of possible licensing options. | 12:39.18 |
| jellenagels | Can we move this conversation to a private room if possible? :) | 12:39.44 |
| kens2 | Makkes sense | 12:39.51 |
| | Go along with Robin | 12:39.55 |
| jellenagels | Alright. | 12:40.00 |
| kens2 | FWIW I can't see an email form anyone by that name, but if it went directo to sales, we wouldn't see it. | 12:40.50 |
| Robin_Watts | kens2: Yeah, they were talking to Scott. We have it under control now, I think. | 12:44.36 |
| kens2 | OK | 12:44.49 |
| jellenagels | Indeeds, thanks for the quick response here. | 12:45.06 |
| kens2 | NP drop by again if you need questions answered :-) | 12:45.28 |
| jellenagels | I will :) | 12:46.11 |
| paulgardiner | tor8:, Robin_Watts: What's the best way to enumerate a name tree? I can see existing functions to lookup specific entries, but nothing for enumeration. | 13:30.07 |
| d3c | new 1.0 is looking good. can I build a noarch from the source? | 13:42.10 |
| | will OS=Linux do? | 13:42.24 |
| tor8 | noarch? | 13:57.32 |
| d3c | tor8: well, I just need to build mu executables that will run on all unix platforms, that's what I mean | 13:59.36 |
| Robin_Watts | dsc: make build=release | 13:59.49 |
| tor8 | d3c: I don't see how that's ever going to work with C code... | 14:00.17 |
| Robin_Watts | dsc: ahem, I meant d3c. | 14:00.22 |
| tor8 | but to build a release, "make build=release" should be smart enough | 14:00.52 |
| Robin_Watts | d3c: Because of the static nature of our libs, you'll probably find that an exe will run on most x86 linux versions OK. | 14:01.35 |
| | but it won't run on other processor archs etc. | 14:01.47 |
| | (like ARM or PowerPC or...) | 14:02.03 |
| | http://ghostscript.com/~robin/HowToBuildGhostscriptOnWindows.txt | 14:02.55 |
| | kens, chrisl, everyone else: ^ Any comments on that? | 14:03.10 |
| | tor8: Did you see my burblings about linearisation above? | 14:04.11 |
| d3c | Robin_Watts: ok, will try that, sec | 14:04.40 |
| chrisl | Robin_Watts: we've already got instructions for building on Windows - couldn't you just update those? | 14:05.51 |
| d3c | Robin_Watts: do you know what this error is about? http://pastebin.com/51qmDSxW (Fedora 16) | 14:05.57 |
| | Robin_Watts: that's `make build=release` btw | 14:06.10 |
| Robin_Watts | d3c: "doc may be used uninitialised in this function" warnings are spurious. | 14:06.28 |
| | Due to the exception handling. | 14:06.42 |
| chrisl | d3c: looks like you don't have the X11 development package(s) installed | 14:06.55 |
| kens2 | Robin_Watts : will need some time to read | 14:07.09 |
| Robin_Watts | You want to build with NOX11=yes or something | 14:07.15 |
| tor8 | Robin_Watts: I saw, not sure I like it. | 14:07.37 |
| d3c | Robin_Watts: oh, nice. what's the X11 for though? | 14:07.49 |
| Robin_Watts | chrisl: I was hoping the top paragraphs about why a user/customer would need to do their own builds would be a clear statement of what we decided at the meeting. | 14:08.42 |
| | tor8: Is there something specific you don't like about it ? | 14:08.58 |
| chrisl | Robin_Watts: surely those should go in the FAQ, then? | 14:09.12 |
| Robin_Watts | chrisl: Possibly. | 14:11.41 |
| chrisl | Does the GhostPDL solution build Ghostscript? | 14:12.09 |
| Robin_Watts | But regardless of where this ends up, comments on wording would be appreciated. And if people could test the instructions, that would be good. | 14:12.13 |
| | Yes. | 14:12.15 |
| | For some reason, my VS2010 fails to convert the solution, but Pauls works fine. | 14:12.35 |
| chrisl | Oh, I didn't know that. It might be worth mentioning that there's a GS specific solution - just to avoid possible confusion | 14:13.08 |
| Robin_Watts | chrisl: There isn't a GS specific solution. | 14:15.09 |
| | There is a GS specific project :) | 14:15.15 |
| | The GS specific project is one of the 5 subprojects of the GhostPDL solution. | 14:15.46 |
| chrisl | Argh! Now I know why I just use nmake! | 14:15.55 |
| | Robin_Watts: the only other thing is, given the apparent technical level at which this is aimed, "Next, apply any patches that may be required." might require explanation. | 14:16.13 |
| Robin_Watts | Yes. That is, I think, going to be the most challenging part for any customer. | 14:16.44 |
| | ray was saying that a customer would need to buy VS Professional, but it can all be done with Express. | 14:17.22 |
| chrisl | Yeh, that, I think, changed with VS2010 | 14:17.58 |
| Robin_Watts | No, you've been able to do it with the platform SDK and previous versions of VS, but it's required registry tweaks so that VS can find the compilers. | 14:18.43 |
| | VS2010 has made the toolset thing a configuration option, so that's MUCH easier. | 14:19.02 |
| chrisl | Robin_Watts: Anyway, the instructions seem fine, to me. I am concerned that if we put this out there, we'll start getting questions about installing/setting up VS2010 and the Win SDK...... | 14:20.15 |
| d3c | btw, I used `pdfdraw` until now. can I use `mudraw` in the exact same way or did arguments change with 1.0? | 14:21.40 |
| Robin_Watts | There are more args, but the old args remain unchanged. | 14:22.03 |
| | So yes, just use mudraw instead of pdfdraw. | 14:22.14 |
| chrisl | Robin_Watts: I guess we should change the directory name from win32 at some point | 14:23.37 |
| Robin_Watts | I think win32 is understood to mean "32 or above" in many cases. | 14:24.34 |
| chrisl | Okay, it's just we did change msvc32.mak | 14:25.29 |
| Robin_Watts | Yes. | 14:26.25 |
| | there are wince, win16 etc, and they wouldn't be covered by the solution. | 14:27.01 |
| | I have no real objection to changing the directory if a better name can be found though. | 14:27.28 |
| ray_laptop | I saw a comment about VS Express. I still think that you need Pro in order to do 64-bit builds: http://msdn.microsoft.com/en-us/library/hs24szh9.aspx | 14:27.49 |
| d3c | Robin_Watts: ok, so I did `make build=release NOX11=yes`. ran with no errors. when running mudraw, I'm getting 'mudraw: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by mudraw)' | 14:28.13 |
| Robin_Watts | ray_laptop: Right. Did you read my document? | 14:28.28 |
| ray_laptop | chrisl: this relates to cust 393 doing their own builds (without buying Pro) | 14:28.43 |
| | Robin_Watts: no, I just glanced at the logs -- what doc | 14:28.56 |
| Robin_Watts | http://stackoverflow.com/questions/1865069/how-to-compile-a-64-bit-application-using-visual-c-2010-express | 14:29.12 |
| | http://ghostscript.com/~robin/HowToBuildGhostscriptOnWindows.txt <- I asked for comments on that. | 14:29.26 |
| | I was aiming for something that walked customers through *why* they might need to build their own, and *how* they could do it without spending money. | 14:30.22 |
| | But I really don't want to write "How to build GS for Dummies" :) | 14:30.45 |
| chrisl | Hmmm, 64 bit build doesn't work for me with VS2010 :-( | 14:31.55 |
| Robin_Watts | And you installed the platform SDK ? | 14:32.37 |
| d3c | Robin_Watts: shouldn't mudraw be able to run, when the build was successful? ^ | 14:32.44 |
| chrisl | Yes. | 14:32.44 |
| Robin_Watts | d3c: The brokenness of your linux system is not my fault :) | 14:33.02 |
| | chrisl: Did you change the Platform Toolset configuration option? | 14:33.27 |
| | d3c: Are you running the binary on the machine it was built on? | 14:34.19 |
| d3c | Robin_Watts: well, the former release I used worked like a charm so I'm just trying to figure out how to build 1.0 and if something changed in 1.0 that I need to take into account | 14:34.22 |
| | Robin_Watts: yes I am | 14:34.29 |
| chrisl | Robin_Watts: I'll have to look into this, it's a while since I installed it. | 14:34.30 |
| Robin_Watts | chrisl: There is a paragraph in my instructions about changing the COnfiguration properties. | 14:35.02 |
| d3c | Robin_Watts: http://pastebin.com/WxXfhWgW | 14:35.08 |
| Robin_Watts | (All this is written blind, as the sodding conversion is broken for me :( ) | 14:35.21 |
| | So if I've missed a step, please tell me. | 14:35.31 |
| d3c | Robin_Watts: doh, sorry. my fault. | 14:35.52 |
| | Robin_Watts: works :) | 14:36.01 |
| Robin_Watts | d3c: Phew :) | 14:36.08 |
| ray_laptop | Robin_Watts: sorry -- was eating breakfast | 14:37.25 |
| | I'll look at your doc. | 14:37.41 |
| Robin_Watts | ray_laptop: np. How was the flight, by the way? | 14:37.45 |
| chrisl | Robin_Watts: I don't see the "Platform Toolset" option - but the Win SDK 7.1 configuration tool doesn't list VS2010 (only 2005 and 2008). | 14:39.47 |
| ray_laptop | My flight was EXCELLENT. Air New Zealand Flight 1. It was about 1/5 full in economy. I wasn't even in Premium Economy and they had "Sky couches" for the three seats on the two outer groups of seats (the 3 of the 3-4-3). | 14:41.26 |
| Robin_Watts | chrisl: Maybe the details in here will help? http://stackoverflow.com/questions/1865069/how-to-compile-a-64-bit-application-using-visual-c-2010-express | 14:41.56 |
| | ray_laptop: Nice. | 14:42.43 |
| ray_laptop | I had a row of 3 to myself, so I could put the leg rests on all three seats up to full horizontal (they lock in position) and they provide a special seat belt thngy that goes from the middle belt to a D-ring on the the bottom of the middle seat in front. | 14:43.19 |
| Robin_Watts | Ah, clever. I've often thought that the seatbelt thing is a real pain when you have enough seats to be able to lie down. | 14:44.24 |
| ray_laptop | they also provide full size pillows and a duvet so I got about 5 hours sleep, then couldn't fall back asleep | 14:44.29 |
| | they don't wake you when you have the middle belt fastened since they can tell it's fastened | 14:45.10 |
| Robin_Watts | tor8: What depth of support for linearised files were you thinking we should aim for? | 14:45.40 |
| | I was going to be quite happy just opening a file as it downloaded. | 14:45.56 |
| ray_laptop | Also no charge for wine with the meals, and the food was better than any 'economy' food I've had for anytime in the last 10+ years | 14:46.04 |
| Robin_Watts | I think we can ignore the hint streams unless we want to start directing the http fetch ourselves (and we really really don't) | 14:46.43 |
| ray_laptop | Robin_Watts: the hint streams are supposed to also be useful to let you know when you can discard resources | 14:47.49 |
| | useful if memory gets tight | 14:48.07 |
| | I have to take the kids to school. bbiaw | 14:48.37 |
| sebras | Robin_Watts: wouldn't this just result in mupdf blocking until the entire file is downloaded (in RAM or elsewhere) since seeking to the end of the file is one of the first things we do..? | 14:50.46 |
| Robin_Watts | sebras: No. My plan (poorly thought out as it is) is that we have a new (optional) callback function in the locking structure. | 14:51.47 |
| | That function gets called when we run out of data, and it can either block, or it can throw an exception. | 14:52.19 |
| | If we HAVE that function, then after we read the version, we attempt to read the linearisation dictionary from the file. | 14:52.53 |
| | (i.e. before we seek to the end and read the xref) | 14:53.08 |
| | IF we get that, then we can read everything we need to display the first page. | 14:53.54 |
| sebras | ah, if having the function pointer implies reading the dict then I understand. I guess I'd have to be in .uk to know that though. ;) | 14:54.16 |
| Robin_Watts | sebras: No, sorry, I hadn't expressed that either at the meeting or here. The idea of us supporting linearised files was mentioned (by me) at the meeting, but that was all. | 14:54.58 |
| | I'm being my usual incoherent self. | 14:55.06 |
| sebras | :) | 14:55.09 |
| Robin_Watts | The only thing is, we need to know what the length of the complete file should be when we open it in order to know if the linearisation is outdated or not. | 14:56.06 |
| sebras | one more point which is a bit fuzzy to me is "run out of data" -- what does that mean? reading beyond the (current) end of the file? | 14:56.34 |
| Robin_Watts | Yes. If we call fz_read for n bytes and get back m < n bytes. | 14:57.10 |
| chrisl | Robin_Watts: building 64 bit from the nmake command line works, but I have to set the path to MSSDK on the command line. I'm reinstalling VS2010 to see if that helps. | 14:57.56 |
| Robin_Watts | I guess we need to cope with the cases of 1) We've hit the end of the file, and that's all we'll ever get, 2) We've hit the end of the file, and we should block until more data arrives, 3) We've hit the end of the file, and we don't want to block - so throw an exception and the caller can retry later. | 14:58.52 |
| sebras | when would 3) apply? I can see the reason for the other two... | 14:59.50 |
| Robin_Watts | The attraction (to me) of using a function for that, is that we can roll it into the stream reading stuff, and it's low impact. Also it keeps the thread library agnosticicity. | 14:59.52 |
| chrisl | Robin_Watts: in a well behaved PDF, the "real" end of file will have the EOF comment | 15:00.07 |
| Robin_Watts | (I have no idea if agnosticity is a real word or not, but I like it, so I'm going to pretend it is) | 15:00.27 |
| | sebras: Suppose you build Mupdf into another app; you might not want it to completely freeze until data arrives. | 15:01.11 |
| chrisl | So we could also have "agnosticisation - the process of becoming agnostic"? | 15:02.01 |
| Robin_Watts | and anti-agnosticisation. | 15:02.29 |
| | and antidisagnisticisation | 15:02.40 |
| | and antidisagnisticisationarianism. | 15:02.45 |
| sebras | Robin_Watts: but wouldn't such an app require you to have multiple threads already? i.e. 1+ for mupdf and another for its gui? | 15:02.57 |
| Robin_Watts | (which would have been funnier if I'd spelt them right) | 15:03.01 |
| | sebras: Not necessarily. | 15:03.13 |
| chrisl | Robin_Watts: I think you should submit those to the OED! | 15:03.29 |
| Robin_Watts | (I mean, sane people might program it that way, but...) | 15:03.30 |
| sebras | chrisl: or at least add them to wiktionary.org... | 15:03.53 |
| chrisl | :-) | 15:04.27 |
| sebras | Robin_Watts: ok, so let's say we are in scenario 3), and we don't want to block. what would the function in the locking struct do then? | 15:04.44 |
| | if it returns mupdf will try to process further data... | 15:04.53 |
| Robin_Watts | Throw an exception. | 15:05.04 |
| sebras | and the premise is that it must not block..? | 15:05.05 |
| Robin_Watts | sebras: Regardless of whether 3) will ever be used in normal use, we probably need the option of throwing an exception because the transfer might fail, or time out, or the user might cancel it. | 15:05.26 |
| sebras | Robin_Watts: how do you know that there is no fz_try()/fz_catch() along the callpath in mupdf? | 15:05.47 |
| | Robin_Watts: sure, throwing exceptions in the error case is one thing. | 15:06.05 |
| Robin_Watts | sebras; We'd be assuming that there *would* be a try/catch in force. | 15:06.16 |
| sebras | here you are advocating that we should be throwing exceptions just because we don't want to block..? I must be missing something. | 15:06.34 |
| Robin_Watts | sebras: Yes, that's exactly what I'm advocating. | 15:06.51 |
| | The function would be something like: int blockForMoreData(...); | 15:07.07 |
| sebras | so why wouldn't mupdf treat it as an error? | 15:07.15 |
| Robin_Watts | and if it returned 0, it would mean "No more data forthcoming". | 15:07.22 |
| | If it returned 1, it would mean "Try again, you should have more data now". | 15:07.37 |
| | or it could throw an exception to mean "just give up!" | 15:07.47 |
| | mupdf WOULD treat it as an error, and would exit. | 15:08.00 |
| | The caller can then say "Ah, but I only got that error because my function threw an exception" and know to retry. | 15:08.32 |
| | The alternative is to have that function return 2 for "just give up" and have to add code everywhere to cope with that case. | 15:09.45 |
| | Which I fear will be way more invasive. | 15:09.52 |
| | sebras: Like I say, this is an initial idea. It could have all sorts of failings. | 15:11.52 |
| sebras | ok, so the "just give up!" case is more along the lines of "the socket from which I'm reading broke so my blockForMoreData() indicates this by throwing an exception". | 15:12.21 |
| | I'm just trying to understand the idea. :) | 15:14.03 |
| Robin_Watts | sebras: Well, I am uncomfortable forcing blocking onto a caller. | 15:14.18 |
| | With sockets you can choose to block or not. | 15:14.38 |
| sebras | also I know from experience that you usually get an "aha!"-moment when you try to explain something that's not yet ready to someone that ask all the silly questions. the latter person being me. ;) | 15:14.51 |
| Robin_Watts | With jpeg/png libs you can choose to block or not. | 15:15.03 |
| | sebras: Indeed. | 15:15.09 |
| | hence it seems reasonable that we should support "blocking or not". | 15:15.28 |
| sebras | so what you are arguing is that it should be possible to have mupdf abort gracefully when there is no more data to be read (yet), and at a later time when there is more data the caller would be retrying the operation. | 15:17.04 |
| Robin_Watts | Yes. | 15:17.34 |
| | And piggy backing that on the existing exception scheme seemed reasonable to me. | 15:17.59 |
| | (because we already cope gracefully (I hope!) with those) | 15:18.15 |
| sebras | right. now I get it. | 15:19.03 |
| | the other option (of not re-using exceptions for this) would be to have mupdf block until more data is available as indicated by blockForMoreData() eventually returning 1, but that means that the app will have to do e.g. GUI updates in another thread since this one is busy-waiting inside mupdf. | 15:20.38 |
| Robin_Watts | sebras: Right. So we'd be forcing all callers to accept the fact that mupdf can block for arbitrary lengths of time. | 15:21.22 |
| sebras | yes. | 15:21.28 |
| Robin_Watts | and my gut tells me that that isn't reasonable. | 15:22.13 |
| sebras | I think it might work (re-using exception for non-blocking calls), but I'm not convinced it would be obvious how it works. | 15:22.15 |
| | well, basically we would require any callers of mupdf to be multi-threaded. | 15:22.39 |
| | in case they can not accept arbitrary waiting periods when calling mupdf. | 15:23.08 |
| Robin_Watts | I think we can document it clearly enough. | 15:23.28 |
| | I suspect we may need the ability to ask what type of exception we just caught in an fz_catch() clause. | 15:24.19 |
| sebras | the scheme would be for a caller to retry upon exceptions from mupdf as long as their blockForMoreData() returns exceptions. | 15:24.23 |
| | or you would need to distinguish between exceptions due to real parsing errors or exceptions that originate from not wanting to block. | 15:25.04 |
| Robin_Watts | sebras: A caller would either have to accept blocking, or it would have to throw exceptions, and respond to the fact it threw an exception by treating errors as "retry". | 15:25.12 |
| sebras | got it. | 15:25.23 |
| Robin_Watts | All of this counts for nothing unless tor8 likes the idea though, and last I heard, he wasn't keen, but I hadn't heard specific objections. | 15:26.17 |
| sebras | I would be tempted to argue that if a caller can not accept arbitrary waiting times (e.g. due to wanting gui updates), then they ought to multi-thread their app. are you thinking about some specific scenarios where this would not be suitable? | 15:27.13 |
| Robin_Watts | No. I'm just thinking that there may be cases where people want to avoid the complexities of threading. | 15:28.00 |
| sebras | I'm not familiar with how mupdf is used when commercially licensed for use in devices, so there might be scenarios I'm unaware of. | 15:28.01 |
| | Robin_Watts: right. one more reason why I'm asking is to make details surface so tor8 knows more about your idea. :) | 15:29.05 |
| Robin_Watts | sebras: yes, you asking questions has forced me to think through more corners of the problem. | 15:31.05 |
| | I think maybe when we're in linearised mode, we should abandon the idea of using xref tables, and just scan through the files reading objects in, recording their positions in an xref we synthesise as we go. | 15:32.45 |
| | The hint tables would let us find the start of a given page without having read the final xref in the file. | 15:33.31 |
| | I require tea. | 15:36.52 |
| sebras | too much thinking? :) | 15:37.20 |
| | isn't the idea of linearised pdfs that they do store xrefs early in the file so that you can locate objects for the early pages before the end of the file is available? | 15:38.29 |
| | but sure, doing so probably would mean that we need to take special care of some xref-attributes that we ignore today. | 15:39.08 |
| Robin_Watts | sebras: Linearized PDFs offer several things, as far as I can make out. | 15:43.19 |
| | Firstly, they ensure that the first page (and all the objects for it) are sent first. | 15:43.36 |
| | Then they ensure that all subsequent pages are sent in order with all the objects they need (except for ones shared between multiple pages) | 15:44.28 |
| Gigs- | there is a constraint on referencing objects that have not yet occurred, basically, right? | 15:45.01 |
| Robin_Watts | They offer a way of getting the offset of page object for a given page, but there is no 'early access' to the offsets for the objects that a given page needs. | 15:45.34 |
| | (i.e. if you want to be able to find objects by looking up their offsets in xrefs, then you have to have read the final xref in the file - except for the first page where you are guaranteed that the special first-page-xref is enough) | 15:46.40 |
| | Gigs-: No, sadly it's not that simple. | 15:46.54 |
| | All shared objects are sent AFTER all the pages. | 15:47.01 |
| | So you'd have to render a page with the wrong fonts etc, and then rerender it later unless you want to wait for ALL the pages to download first. | 15:47.41 |
| Gigs- | that sucks heh | 15:47.51 |
| Robin_Watts | Yeah. | 15:48.08 |
| | It would have been MUCH simpler all around if adobe had mandated that an xref should be sent first, then pages in order, guaranteeing that every object can only refer to objects already sent in the file. | 15:48.57 |
| kens2 | Sigh, someone please pass me the clue stick, I need to hit myself with it repeatedly.... | 15:50.48 |
| Gigs- | Robin_Watts: is anyone using multiple partial xrefs in linear pdfs? | 15:51.49 |
| Robin_Watts | Gigs: Maybe. That would have been a reasonable solution too - but if it's not in the standard, you can't rely on it... | 15:52.19 |
| Gigs- | it's allowed in the standard I believe | 15:52.31 |
| | an early trailer | 15:52.35 |
| Robin_Watts | It's allowed, sure | 15:52.40 |
| Gigs- | I've never seen one personally, even in supposedly linear PDFs | 15:53.10 |
| Robin_Watts | but unless the files we meet in the wild are like that, we gain no advantage from attempting to deal with them efficiently | 15:53.28 |
| | (not that we currently deal with them inefficiently) | 15:53.42 |
| Gigs- | doesn't gs build its own xref anyway? I seem to remember it warning if the real xref and the actual locations of the objects don't line up | 15:53.59 |
| Robin_Watts | Gigs-: We're discussing mupdf here. | 15:54.57 |
| Gigs- | oh, ok | 15:55.02 |
| Robin_Watts | and specifically extending it so that it can cope with early display of files as they are still downloading. | 15:55.14 |
| | Different use-case from gs (which can assume that all the data is there when it's called) | 15:55.33 |
| Gigs- | if it's HTTP might you be able to cheat and do a partial get with a Range header to get the end of the file first? | 15:57.43 |
| | sorry If I'm way off base, I don't have much context for the conversation heh | 15:58.08 |
| sebras | Gigs-: sure, but we'd rather hand over the HTTP handling to the app rather than having mupdf depending on an HTTP library. or so I understood it. | 15:59.21 |
| | Robin_Watts: hm.. I should look into linearlized pdfs more. | 15:59.42 |
| Robin_Watts | sebras: I've just read through the chapter going "but... but... why?" | 16:00.07 |
| sebras | need to go now though -- I have an appointment with an icelandic concert in copenhagen in a few hours. :) | 16:00.16 |
| | Robin_Watts: aww. now I'm not looking forward to it anymore... | 16:00.30 |
| Robin_Watts | Sibelius ? | 16:00.32 |
| sebras | reading about linearized pdfs that is. | 16:00.41 |
| Gigs- | I got into it with the lead architect guy at adobe that was the one who got it turned into an ISO standard | 16:00.55 |
| chrisl | Robin_Watts: the "why" is the usual answer - a horrible hack for use case that Adobe didn't originally think through properly....... | 16:01.24 |
| Gigs- | he demanded a public apology because I claimed that the spec left enough vague that there was no guarantee that two spec compliant implementations would render two files the same way | 16:01.47 |
| | I replied with a very sarcastic apology heh | 16:02.01 |
| sebras | Robin_Watts: no, Sóley. http://goo.gl/BAOQZ | 16:02.18 |
| chrisl | Gigs-: considering versions of Acrobat don't always agree on how to display a PDF, I'd say he was on pretty shaky ground, there! | 16:02.59 |
| Gigs- | yeah, it's interesting that he could actually believe that though | 16:03.21 |
| sebras | Gigs-: for a very superficial reason I would prefer if it was not an ISO standard -- Adobes typesetting of the spec is way appealing than ISOs... | 16:03.22 |
| | good evening. | 16:03.55 |
| chrisl | Robin_Watts: the "Platform Toolset" setting doesn't apply to nmake projects. | 16:10.36 |
| Robin_Watts | chrisl: Oh. Ass. | 16:11.07 |
| | Hmm. So we'd need to update our msvc thing to pick up a new location for the platform toolset compilers ? | 16:11.56 |
| | s/msvc thing/msvc makefile | 16:12.08 |
| chrisl | Yes | 16:12.15 |
| Robin_Watts | OK, this just got to be way more work than is worthwhile. | 16:12.36 |
| chrisl | I need to pass nmake: 'BUILD_SYSTEM=64 WIN64=1 MSSDK="C:\Program Files\Microsoft SDKs\Windows\v7.1"' | 16:13.12 |
| | And the Windows SDK installer doesn't add an environment variable with the path (whilst the VS installer does) :-( | 16:15.32 |
| Robin_Watts | Refresh my memory here... WIN64=1 means "target of build is 64bit" | 16:15.44 |
| chrisl | Yes | 16:15.51 |
| Robin_Watts | BUILD_SYSTEM=64 means ? | 16:15.53 |
| chrisl | You're building on a 64 bit system | 16:16.06 |
| Robin_Watts | Call compilers that only run on a 64bit system? | 16:16.07 |
| | What's the advantage to that? Are the platform SDKs compilers 64bit exes? | 16:16.35 |
| chrisl | Other way round: most of the VS executables are 32 bit only (even the ones that produce 64 bit output), so we need to know whether the path has the (x86) suffix for Program Files | 16:17.29 |
| Robin_Watts | Ah. | 16:19.52 |
| ray_laptop | kens2: are you handling the support tasks while marcos is at the show / traveling ? | 16:22.21 |
| kens2 | Err, good question. | 16:22.32 |
| | Nobody mentioned it, so I suppose the answer is 'yes', unless Marcos has internet access and wants to carry on | 16:22.50 |
| | I did see he replied to Raed this monring but I didn't think about it | 16:23.13 |
| ray_laptop | kens2: I ask because I thought henry requested that customer communications go through marcos (single point of contact) unless marcos is out of town | 16:23.25 |
| chrisl | Robin_Watts: even worse, the version 7.x SDKs don't seem to put a path entry in the registry either........ | 16:23.34 |
| kens2 | Indeed, but he is out of town, so I don't know.... | 16:23.43 |
| | ray_laptop : I don't *think* I've been CC'ing the customer, I certainly haven't intended to, did I screw up ? | 16:24.04 |
| ray_laptop | chrisl: just tell people to buy "Pro" | 16:24.23 |
| Robin_Watts | chrisl: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A | 16:24.32 |
| | ? | 16:24.38 |
| ray_laptop | kens2: maybe I missed that | 16:25.21 |
| | marcosw: probably won't have good internet while at the show (in Caldera's booth) | 16:26.05 |
| kens2 | Absolutely. | 16:26.14 |
| chrisl | Robin_Watts: yes, that'll be it - strange my search didn't find it, but found an entry for 6.0A | 16:26.16 |
| | Robin_Watts: so we *could* get the path by using reg.exe to interrogate the registry..... | 16:31.05 |
| Robin_Watts | chrisl: Well, it sounds like a nice feature to me, but I'm not the poor schmuck who has to maintain the makefile. | 16:31.34 |
| chrisl | I have a feeling we didn't do it before because reg.exe isn't standard on pre-Win7 | 16:32.10 |
| kens2 | Its on Vista | 16:32.23 |
| Robin_Watts | chrisl: So... the makefile could only call reg.exe if all else fails ? | 16:32.45 |
| chrisl | Robin_Watts: we don't really have fallback capabilities in this case - once the build fails, it's failed | 16:33.40 |
| ray_laptop | if reg.exe isn't available, we could build a little 32-bit 'aux' app that interrogates the registry ;-) | 16:33.41 |
| kens2 | runs away screaming | 16:34.31 |
| Robin_Watts | chrisl: I meant, the makefile could only use reg.exe if all other attempts to locate the c compiler fail. | 16:34.39 |
| chrisl | The first time we try to locate the compiler is when we try to start building | 16:35.08 |
| Robin_Watts | Right. | 16:35.15 |
| | nmake doesn't have an if "this file exists" construct? | 16:35.44 |
| chrisl | It does, but I don't know if it has a "if this file exists in my search path" construct | 16:36.32 |
| Robin_Watts | http://stackoverflow.com/questions/4470275/testing-file-existence-in-nmake | 16:36.43 |
| chrisl | Yeh, but that assumes you have the path to the file | 16:37.45 |
| Robin_Watts | Using the technique there (Cheeso's answer) we could make a temporary batch file that attempted to find a suitable compiler. | 16:38.12 |
| chrisl | We already use that type of construct to decide whether to use luratech (and maybe a few other things) | 16:38.12 |
| kens2 | ray_laptop : I discovered today that I hadn't freed function objects in pdfwrite. I missed them because the PCL interpreter can't trigger their use. I've coded tha tup and just finished testing, and all is OK. I'll push the code rtomorrow. Sorry for the delay. | 16:38.15 |
| ray_laptop | kens2: cool. thanks | 16:38.33 |
| chrisl | Robin_Watts: there's a limit to how complex I'm willing to make this...... | 16:39.32 |
| Robin_Watts | chrisl: Absolutely. You've gone further than I would have done in investigating this already. | 16:40.07 |
| | Probably, if a solution *is* required to this, it's to update my docs to talk people through making the change to the solution. | 16:41.09 |
| chrisl | TBH, it's because whenever I have to build with VS2010, I always have to look up the incantation, so if there was a "nice" solution, I'd have been quite happy to use it. | 16:42.07 |
| kens2 | Hmm, looks like I need to make a change to my code today when doing the '%d' syntax. Seems like I'm not clearing a list. | 16:42.10 |
| | So its trying to examine freed objects. | 16:42.24 |
| | One for the morning. | 16:42.31 |
| | Goodnight all | 16:42.34 |
| Robin_Watts | night kens2 | 16:42.38 |
| chrisl | Robin_Watts: Do you have the Windows SDK installed? | 16:42.52 |
| Robin_Watts | I thought I did, but I can only see 6.0A | 16:43.05 |
| chrisl | So, can you get a VS2010 command line window up, and try this: | 16:43.36 |
| | nmake -f psi/msvc.mak BUILD_SYSTEM=64 MSSDK="C:\Program Files\Microsoft SDKs\Windows\v7.1" | 16:44.19 |
| | (you are using 64 bit Windows, IIRC) | 16:44.33 |
| Robin_Watts | I am. | 16:44.39 |
| | I don't have 7.1 installed it seems. Trying with v6.0A instead, I get: | 16:46.23 |
| | "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\cl" /c /DWINDOWS_NO_UNICODE /DGX_COLOR_INDEX_TYPE="unsigned __int64" /DHAVE_SSE2 /GF /O2 /Ob2 @.\obj\ccf32.tr /Za /Zm1100 -I.\psi -I.\obj -I.\obj -I.\base -Fo.\obj\imain.obj /c .\psi\imain.c | 16:46.35 |
| | NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\cl.EXE"' : return code '0xc0000135' | 16:46.37 |
| | Stop. | 16:46.39 |
| | That's from a command window though. | 16:46.52 |
| | Not a VS2010 command line window (what's one of them?) | 16:47.20 |
| chrisl | Each VS installs a shortcut to open a command prompt window with it's paths all set up | 16:47.59 |
| Robin_Watts | oh, right, yes. | 16:48.21 |
| | Right. That whirs away nicely. | 16:49.31 |
| chrisl | Is that with the path to v6.0A? | 16:49.55 |
| Robin_Watts | yes. | 16:50.01 |
| chrisl | Could you try it with the path to v7.1 - I'm specifically interested in what might happen if the MSSDK isn't there? | 16:51.09 |
| Robin_Watts | Oh, that still builds into obj rather than obj64 | 16:53.16 |
| chrisl | The command line I gave above was for a 32 bit binary | 16:53.45 |
| Robin_Watts | Irrespective of what path I give, it seems to call MSVC10 | 16:54.11 |
| | and indeed, it was for a 32bit binary, sorry. | 16:54.59 |
| chrisl | So, we could just add the MSSDK default path to the project, with a note saying if you've installed somewhere else, you need to do other stuff | 16:55.16 |
| Robin_Watts | chrisl: Sorry, I'm confused. | 16:55.38 |
| | The MSSDK setting seems to have no effect for me. | 16:56.26 |
| chrisl | I just looked at the makefile, and it only comes into effect when the build is a 64 bit one | 16:56.58 |
| Robin_Watts | Right. | 16:57.03 |
| | And the solution has separate invocations for 32 and 64bit builds. | 16:57.14 |
| chrisl | Yes, but it just occurred to me that setting the MSSDK value might then cause problems if you use the VS Pro version | 16:57.55 |
| Robin_Watts | It's only the 64bit ones we have to worry about, because every VS can build the 32bit ones fine. | 16:58.20 |
| | Right. I don't think we can add it by default. | 16:58.54 |
| chrisl | I think I'll briefly look into whether the reg.exe idea might work..... but tomorrow..... | 16:59.38 |
| Robin_Watts | OK. | 16:59.46 |
| | have a 'findsdk.bat' or something. | 17:00.12 |
| | (maybe as an autogenerated thing) | 17:00.24 |
| chrisl | Well, I'm hoping the invocation will be simple enough to do in the makefile | 17:00.51 |
| Robin_Watts | right. | 17:01.00 |
| chrisl | Otherwise, I'll just add a comment at the top of the makefile as an aide memoire...... | 17:01.49 |
| tor8 | Robin_Watts: (sorry, was at the cinema) two specific objections, that both ground themselves in my dislike for complexity. 1) adding non-blocking i/o should be done properly, if we do it at all. and that's a rat's nest of complexity with all the filters. | 19:04.35 |
| | 2) this is all a hell of a lot of work. we'd need a new mode and rework the xref parsing to deal with partial serial reading of a pdf. | 19:05.24 |
| | now I think we could do (2) without having to get into non-blocking i/o by basing it off an in-memory buffer that the client will add more data to and have a call for "here's some more, resume partial parsing and let me know when you have all the objects you need for page N" | 19:06.12 |
| Robin_Watts | tor8: In what way is having a callback function to block until we have more data not doing it properly? | 19:19.13 |
| tor8 | global state callbacks? | 19:19.52 |
| Robin_Watts | Would you rather the callback function was part of the stream ? | 19:20.10 |
| tor8 | well, you could use a custom stream if you need it...? | 19:20.28 |
| | but we'll still need to rejig the whole xref parsing thing, the exact i/o mechanism is a pretty minor detail | 19:21.14 |
| Robin_Watts | Yes, a custom stream would effectively have the callback inside it already. That is nicer. | 19:22.30 |
| tor8 | if we work more on the threading architecture another approach would be to have the xref parsing done in a separate thread from the other pdf parsing | 19:22.35 |
| Robin_Watts | The xref parsing is a rework yes, no getting around that. | 19:22.58 |
| | I don't think it's quite as horrific as it could be though. | 19:23.09 |
| tor8 | but I think a "feed the xref some more data" and "can we parse page N without blocking yet?" calls would be easiest | 19:23.18 |
| | and that'd get us what we really want too | 19:23.34 |
| Robin_Watts | Implementing "can we parse page N without blocking" is hard. | 19:24.00 |
| tor8 | no, I think we can refit the repair code to work piece-meal | 19:24.01 |
| | without too much difficulty. | 19:24.13 |
| | well, we can just do the same thing as for garbage collection but stop if we reach a not-loaded-yet object? | 19:24.40 |
| Robin_Watts | We know the start offset of the page. | 19:25.09 |
| tor8 | the page tree parsing would have to be done differently, but that may help loading times for all other cases too | 19:25.11 |
| Robin_Watts | We don't have any page tree at all. | 19:25.31 |
| | We can read the page object in (but have to cope with not having the data to get all of it yet). | 19:25.51 |
| tor8 | right, but that's only if it's linearised right? | 19:26.03 |
| | (the page offset) | 19:26.09 |
| Robin_Watts | yes | 19:26.19 |
| | but we have no way of knowing if a resource object is going to be coming in the 'page bundle', or whether it's going to be much later on in the shared objects. | 19:26.47 |
| tor8 | I guess linearised pdf is why the first page in so many pdf documents has the content stream chopped up into tiny pieces | 19:27.02 |
| | but all other pages have the content stream all in one stream | 19:27.11 |
| Robin_Watts | tor8: Not sure I follow that logic. | 19:27.26 |
| tor8 | page 1 content streams are almost always chopped up into many objects (an array of content streams) | 19:27.46 |
| | page >1 content streams are just one object | 19:27.53 |
| Robin_Watts | We can always part render a stream - whether it's in one or many objects doesn't matter. | 19:27.53 |
| tor8 | it's not relevant, it was just a reflection :) | 19:28.06 |
| Robin_Watts | or do you think that's so they can intersperse the contents with resource objects? | 19:28.13 |
| | That's possible, yeah. | 19:28.22 |
| tor8 | it could very well be that | 19:28.32 |
| | but in the general case we'd have to wait with a page until we have all resources if we want to guarantee being able to render without (blocking | needing to read more data) | 19:29.01 |
| Robin_Watts | Doing it as a custom stream seems absolutely the right way to do it, now you come to mention it. | 19:29.13 |
| tor8 | thanks! I really don't want to put more stuff into the context if we can avoid it. | 19:29.41 |
| Robin_Watts | BUT... I reckon most of our customer will not want to write a stream themselves. So we should offer them a stream where more data can be fed in as it arrives. | 19:29.42 |
| | and the blocking or not behaviour of that custom stream will need to be configurable, I reckon. | 19:30.21 |
| tor8 | an appendable_buffer_stream basically? | 19:30.28 |
| Robin_Watts | which means I still think we need the same basic callback, but as a facet of the stream rather than the context. | 19:30.49 |
| tor8 | and a fz_repair mode that can resume processing when prodded | 19:30.50 |
| Robin_Watts | yes, exactly. | 19:30.52 |
| | indeed. | 19:30.54 |
| tor8 | and a "do we have enough objects to draw page N yet" call somewhere | 19:31.05 |
| | then some client who is downloading the pdf off an http stream can keep appending data to the appendable-buffer-stream and ask after each time if it can draw page 1 yet | 19:31.55 |
| Robin_Watts | I think we have a 'render page N' call, and that will call down into the usual rendering stuff. | 19:31.55 |
| | If we can't locate the page yet, we keep reading through the objects until we can. | 19:32.20 |
| | If we can locate it, we try and render it, until we run out of data. | 19:32.36 |
| tor8 | have you looked at the spec for linearised enough to know whether the page tree objects are there too for the first page? | 19:32.51 |
| | or can the page tree come after everything? | 19:33.06 |
| Robin_Watts | If we run out of data, we'll call down into the stream to read more, and we can either decide to bale or to block there. | 19:33.18 |
| tor8 | we could special case the page tree loading for linearised for the first page if not | 19:33.21 |
| Robin_Watts | the page tree can come after everything. | 19:33.24 |
| tor8 | damn. | 19:33.30 |
| Robin_Watts | For the linearised case (at least), we'll need to build our own table of page/offset. | 19:34.03 |
| | The initial page offset is read from the initial linearised dictionary. | 19:34.19 |
| | subsequent ones come from the hints table. | 19:34.26 |
| | The hints table is guaranteed to come before the other pages though. | 19:34.42 |
| tor8 | just a thought: two modes for pdf_document: xref parsing done either up front from xref sections, or repair done lazily. if something goes wrong, switch to lazy repair mode automatically. | 19:34.49 |
| Robin_Watts | so we WILL have an offset for every page before we start rendering it. | 19:34.53 |
| tor8 | pdf_cache_object(N) will repair until it finds object N | 19:34.59 |
| Robin_Watts | Yes, | 19:35.03 |
| | I like that. | 19:35.08 |
| tor8 | the repair will remember the last offset it has seen, so we can still seek to earlier objects and decode their streams | 19:36.32 |
| Robin_Watts | Yes. | 19:36.40 |
| tor8 | and if the file-buffer is appended to, it can resume parsing at the end even if it has already seen EOF | 19:36.55 |
| | maybe with a bit of extra prodding | 19:37.03 |
| Robin_Watts | yeah. | 19:38.11 |
| tor8 | I think, since sockets are non-seekable, any client will always be either buffering into ram or into a temporary file | 19:38.30 |
| Robin_Watts | I'm being called to help with dinner, but it sounds like we're not hugely far apart on this. | 19:38.30 |
| tor8 | so appends to an underlying file descriptor should work, and we could provide an appendable-buffer-stream | 19:38.54 |
| Robin_Watts | yes. We could offer 2 different extendable stream implementations (memory or ram), and that should cover our bases. | 19:39.25 |
| tor8 | no, I think we could reach consensus here. but let's hold off the details about blocking until we've rejigged the xref/repairing. I think an appendable stream and leave all the non-blocking details to the client is best. | 19:39.59 |
| henrys | I'm in Snowshill with the sheep | 20:16.15 |
| spencer | Hello all | 20:42.27 |
| | I've got a quick question, can you mix comand line switches and the @filename option? | 20:42.56 |
| | Also, on a windows 7 64 bit machine, the @filename option causes gs to crash | 20:53.12 |
| | Attempting to call gswin64c.exe @tmpfile where tmpfile does not exist replicates the crash | 20:54.04 |
| | Hmm, I'm about to leave work, so I'll log out and come back tomorrow. | 20:55.04 |
| mvrhel_laptop | made it to vancouver... | 20:56.22 |
| | one more flight to go | 20:56.25 |
| henrys | hey mvrhel_laptop I'm hangin' out with the sheep. | 21:05.01 |
| mvrhel_laptop | baaa | 21:05.08 |
| | henrys: I imagine it is pretty there | 21:05.29 |
| | do you have to shear any of them? | 21:05.48 |
| henrys | it really is - rolling hills like you'd imagine. | 21:05.50 |
| mvrhel_laptop | right | 21:05.54 |
| | so I found that tiffsep1 is broken | 21:06.17 |
| henrys | sigh | 21:06.28 |
| mvrhel_laptop | I did not realize that tiffsep1 renders to contone buffers | 21:06.31 |
| | and then halftones in the device | 21:06.35 |
| | with screens | 21:06.38 |
| | I think we should move this device over to planar | 21:06.46 |
| | and then use the fast planar screen code | 21:06.53 |
| | so, with tiffsep1 as it stands, it needs compressed color encoding | 21:07.19 |
| | if you turn it off (as I did) the device does not render correctly | 21:07.31 |
| | this is true even before my commit (I went and checked) | 21:07.40 |
| henrys | mvrhel_laptop:seems like something perfect for Robin_Watts to do... he didn't have a priority project when we left the meeting - poor guy he works too fast. | 21:08.17 |
| mvrhel_laptop | ah. yes. that would be good. | 21:08.31 |
| | I think I have this devn SeparationOrder issue fixed on the plane. doing a cluster push now | 21:09.11 |
| | head hurts now though. I got up at 5am. could not sleep | 21:09.38 |
| | had ac power again on the whole flight and I couldnt let that time go to waste | 21:10.01 |
| Robin_Watts | henrys: Did Sabrina get her scarf from Arnie ? | 23:05.25 |
| rhce7320 | qrencode -tEPS <string> | gs -q -dNOPAUSE -dBATCH -sOutputFile=%stdout -sstdout=%stderr -sDEVICE=pswrite -_ | 23:17.17 |
| | this qorks in s shell. qrencode builds a EPS QR-code. It is pipes to gs that adds ps header & trailer. If run the cmd with php's shell_exec(), I only get the empty ps header & trailer - no QR-code | 23:19.22 |
| | s/qorks/works/ | 23:19.40 |
| | Forward 1 day (to 2012/05/04)>>> | |
IRC Logs