| | <<<Back 1 day (to 2012/02/02) | 2012/02/03 |
| scottsan | Power failure at my house today. Any of you guys need anything just let me know, I'm back on line. | 00:10.59 |
| dboehmer | hey, i think you can actually help me with my engagement:-) | 01:11.15 |
| | i create a postcard in DIN A6 format saved as PDF | 01:11.29 |
| | the pdf has 2 pages: front and back page of the postcard | 01:11.43 |
| | i need to print 4 DIN A6-sized areas on 1 A4 sheet in the pattern 1,2,1,2 to get correct postcards after cutting | 01:12.27 |
| | how to achieve that with gs? | 01:12.33 |
| | sorry to say but I don't get on with gs' cmd line syntax:( | 01:12.49 |
| henrys_laptop | dboehmer checkout ghostscript stack overflow - a user named pipitas has already answered many of these kinds of questions with detailed explanations and ascii art. | 03:45.26 |
| | oh I see he's here. | 03:45.50 |
| | pipitas that is. | 03:46.17 |
| kens | Well, I've finally located the problem with nested patterns. opdfread.ps deliberately sets the graphics state CTM to the identity before defining *any* pattern. I suspect this is to remove teh resolution scaling that we do fro PDF. | 09:59.17 |
| | But I suspect its entirely the wrong thing to do for nested patterns | 09:59.58 |
| chrisl | Are the patterns instantiated hierarchically?# | 10:03.28 |
| kens | Yes, that all works fine. THe CTM is correct when the second pattern is created. | 10:03.47 |
| | SO the pattern should be created using the CTM (as per the PLRM). But opdfread deliberatly sets the CTM abck to the identity | 10:04.16 |
| chrisl | I thought the second pattern was the problem | 10:04.42 |
| kens | It is, sort of. It has a Ty of 1399 which puts it off the page. | 10:04.58 |
| | But if you apply the CTM under which its created, which has a Ty of -389 and a sclae y of 0.8 then the modified Ty is correct. | 10:05.32 |
| chrisl | But the actual problem is the first pattern using the identity matrix? | 10:05.40 |
| kens | No the problem is that opdfread sets teh CTM back to the identity before creating the second pattern. | 10:06.03 |
| | For the first pattern this is 'corrrect' (for very smal values of correctness) | 10:06.28 |
| | For the second pattern its not correct. | 10:06.36 |
| | I think the problem is the PDFRM says that Patterns are always in the 'default' CTM, and that's clearly not true for nested patterns | 10:07.14 |
| chrisl | Right, so I was going to suggest making a "note" that it is already "in pattern", so subsidiary patterns don't have the matrix set back to identity - that should only happen for the top level pattern | 10:07.27 |
| kens | Yes, that was what I was thinking. I still have to undo the resolution scaling though, and that's a problem. | 10:07.56 |
| | Because I don't know what it is. | 10:08.07 |
| | However, if I note in pdfwrite that we are in a nested pattern, *and* we are goign to ps2write, tehn I don't do the resolution scaling. I think that should work. Ugly as hell though | 10:08.44 |
| chrisl | Oh, right. A little more ugly isn't a huge problem in a whole heap of ugly.... | 10:09.29 |
| kens | Yes, its already incomprehensible. | 10:09.44 |
| | But I'm stretching my understanding a bit, so I need to think about this for a minute or two. So I'm going to take a coffee break first. | 10:10.11 |
| chrisl | I need to go out for a few hours, back later....... | 11:09.56 |
| kens | ybe | 11:10.02 |
| Robin_Watts | hunts for the test files that rays customer is using... | 11:14.14 |
| | OK, I'm officially stumped :( | 11:47.36 |
| | Hey tor8. | 11:48.37 |
| tor8 | Hi Robin | 11:48.52 |
| Robin_Watts | Have you been following my emails to the customer about mupdf on the ipad? | 11:49.19 |
| | I have a con-call today at 6pm my time with them - let me know if you think I've said anything incorrect or misleading in the emails. | 11:49.42 |
| tor8 | catches up on today's emails. | 11:51.46 |
| | Robin_Watts: it's all good. should save the last email of yours in a text file in mupdf/doc/ though :) | 11:55.14 |
| sebras | Robin_Watts: why are you doing my job? ;) | 11:58.14 |
| Robin_Watts | I think I know what's up with bug 692836 | 11:58.24 |
| | sebras :) | 11:58.29 |
| | I was answering questions from a customer about how to get multithreaded stuff working with mupdf. | 11:59.18 |
| | I can forward the email if you like - not sure it'll be that much use to you, but... | 11:59.47 |
| tor8 | Robin_Watts: we should encapsulate outline and link loading in (pdf|xps)_load_outline and *_load_links so they can go in the document interface | 12:01.38 |
| Robin_Watts | tor8: If you want I can hold off on fiddling any more until you've got the document interface going ? | 12:02.37 |
| tor8 | I've run into a mental wall with the text device ... :( | 12:02.58 |
| | just need to get over that hump | 12:03.10 |
| Robin_Watts | Stick a pin in it, and do the document one ? | 12:03.14 |
| tor8 | yeah, that's probably best so I don't keep you waiting | 12:03.33 |
| Robin_Watts | Well, once the document one is done, we can merge mupdfdraw and muxpsdraw, rename mupdf to muview etc... | 12:04.31 |
| tor8 | exactly, all things we want done for 1.0 | 12:04.45 |
| Robin_Watts | yeah. | 12:04.51 |
| tor8 | I'll bang on the doc interface now then. It's been congealing in my brain for some time now, just need to iron out the details about what to do with the pdf_page and xps_page types | 12:05.31 |
| | typedef void fz_page was one idea, but that's pretty awful | 12:05.52 |
| Robin_Watts | tor8: I'm a fan of having a fz_page structure with the common things in, then having fz_page_pdf start with an fz_page base; | 12:06.44 |
| tor8 | yeah, except there aren't any common things :) | 12:07.28 |
| Robin_Watts | Well, all function entry points become virtual ones in the base. | 12:07.52 |
| | And fz_run_page(page, blah, blah) becomes something like page->run_page(page, blah, blah); etc | 12:11.46 |
| tor8 | yeah, that's my intention | 12:12.30 |
| | my only headache is how to do the types for the arguments in the function pointers | 12:13.30 |
| Robin_Watts | You almost did it with the device stuff; but in that you have a fixed structure, and a user pointer. | 12:13.44 |
| tor8 | do we want pdf_run_page to take a fz_document* and cast it or pdf_document*, or do we add a thin shim layer to do the type conversion | 12:14.00 |
| Robin_Watts | We have it take a fz_page and upcast it itself. | 12:14.15 |
| | It's allowed to upcast, because it knows it can only ever be called on a pdf page - hence it's safe. | 12:14.40 |
| tor8 | I'd be happier with that if we could then keep the function static to hide it, but we can't do that when the functions are all spread out over many files | 12:15.35 |
| Robin_Watts | tor8: Oh, well, you can have a static shim to do the upcast in whatever file offers fz_new_pdf_page or whatever. | 12:16.58 |
| | which then calls a public function. | 12:17.10 |
| tor8 | yeah, that sounds like a better idea. I can put them in the same file that 'registers' the pdf document handler. | 12:17.55 |
| | which is another question, how to say which document types we handle | 12:18.09 |
| | I'd like to have a fz_open_document that can autodetect which file types we can deal with | 12:18.41 |
| Robin_Watts | tor8: Have an fz_dochandler type. And have a list of those; one per doc type. | 12:19.07 |
| tor8 | now is when I want the plan 9 c compiler... | 12:19.23 |
| kens | Hmm, anyone fancy porting MMuPDF to teh Playbook ? : | 12:19.30 |
| | http://www.theregister.co.uk/2012/02/03/free_playbook/ | 12:19.30 |
| kens | lunches | 12:19.57 |
| tor8 | it has anonymous structs, and will automatically upcast a struct to said embedded anonymous struct implicitly when needed | 12:20.13 |
| | so this sort of "make a common superclas struct" becomes really easy and doesn't have you messing with a gazillion typecasts | 12:20.45 |
| Robin_Watts | IME the typecasts don't get out of hand. | 12:21.26 |
| | Just upcast once at the start of the function. | 12:21.49 |
| | tor8: Have you answered Raeds mail from the 2nd ? | 12:23.45 |
| tor8 | no. and I'm loath to, since that touches the text device stuff that I'm revamping. | 12:25.35 |
| | I didn't see it until just recently | 12:26.14 |
| Robin_Watts | I'd be tempted to send him a mail saying "We're reworking this just now. Give us a few days." | 12:26.40 |
| tor8 | yeah. shall you or I? | 12:27.27 |
| Robin_Watts | text device is your baby now ;) | 12:27.46 |
| tor8 | I'll do it then :) | 12:28.02 |
| Robin_Watts | I think he wants to be able to read a rotation angle out of the xml output, when we only give him a transformation matrix. | 12:28.48 |
| | I think he's going to be disappointed. | 12:28.57 |
| tor8 | the text_style struct doesn't even have that | 12:30.38 |
| Robin_Watts | It's been ages since I looked at this stuff. | 12:34.01 |
| | But when I last did, we concatenated chars together into spans, and the spans didn't have to match transforms exactly. | 12:34.38 |
| | (to allow for 'wavy' lines of text). | 12:34.53 |
| | As such there IS no single transform to be had. | 12:35.05 |
| tor8 | pretty much, yeah | 12:35.07 |
| | I wonder what he wants the rotation for, it's not needed for any of the usual uses for the text extraction device unless he wants to convert to another format | 12:35.54 |
| | . | 12:35.54 |
| Robin_Watts | We could offer start/end coords for a span ? | 12:36.43 |
| tkamppeter | someone of you knows about the Linux build? 9.05 seems not to insert XCFLAGS into the gcc command lines of the shared library build (sobin/libgs.so.9.05). | 12:38.07 |
| tor8 | we could add a direction vector for each span without too much difficulty | 12:38.17 |
| Robin_Watts | tkamppeter: That would be one for chrisl, I fear. | 12:41.07 |
| | tor8: Presumably we offer a start pos for each span already? | 12:41.36 |
| | Either a direction vector (non-normalised) or an end pos would be equivalent. | 12:42.02 |
| tor8 | Robin_Watts: yeah. you could trivially compute the angle from the bbox positions | 12:45.36 |
| | even in the current state | 12:45.45 |
| Robin_Watts | bbox positions? | 12:46.42 |
| | You can't go from the bbox of a piece of text to it's angle. | 12:47.01 |
| | You can go from start/end pos to angle. | 12:47.11 |
| | but your email looked good. We'll see what he says. | 12:47.27 |
| tor8 | the spans all have the same style, so the same font and size. at the moment the bboxes are formed by the ascender/descender/advance-width | 12:49.24 |
| | if we go with per-glyph bboxes what you say is true | 12:49.24 |
| | Robin_Watts: how do you feel about making fz_malloc_struct call calloc to get zeroed memory? | 12:51.24 |
| Robin_Watts | I thought it already did? | 12:51.38 |
| | hence I'd have no objection at all ;) | 12:52.02 |
| tor8 | it calls fz_malloc, but I take that as a "yes, please!" :) | 12:52.05 |
| kens | FWIW I think the 'raw' text output from teh GS text device would allow Raed to extract the rotation. Of course its a CTM as you would expect. | 12:54.22 |
| | I suspect Raed thinks text only comes in 4 directions | 12:54.58 |
| Robin_Watts | I need to find a copy of PWTTQ1CC.pdf | 12:56.58 |
| CoolCoder | how to find the number of pages in a pdf file? | 12:57.31 |
| Robin_Watts | Anyone have an idea of where I can get it from ? I can't find it in my email (but I only changed clients recently, so my history doesn't go back that far, and the old clients search is broken) | 12:57.56 |
| kens | I'll see if I can find it | 12:58.09 |
| Robin_Watts | CoolCoder: Using what tools ? | 12:58.19 |
| CoolCoder | ghostscript | 12:58.37 |
| kens | pdf_info.ps | 12:58.43 |
| CoolCoder | i am using PHP. i need the command to get this | 12:58.59 |
| kens | I think... | 12:58.59 |
| | Its not a command, you need to run Ghostscript and execute that file along with the PDF | 12:59.17 |
| | Which returns the indformation on the back channel | 12:59.29 |
| | Or you can write PostScript to get just the number of pages | 12:59.46 |
| CoolCoder | example : gs pdffile.pdf_info.ps ? | 13:00.18 |
| kens | gs -FILE=<input.pdf pdf_info.ps I think, but wait a mnute | 13:00.41 |
| CoolCoder | ok | 13:00.50 |
| kens | TCan't find the dratted thing now | 13:01.19 |
| CoolCoder | so far gs is excellent to convert PDF files to JPG. Not the issue is i need to find the page number before start to convert | 13:01.32 |
| | Now* | 13:01.38 |
| | I mean total pages | 13:01.50 |
| | this is same example in Imagick "identify -format %n input.pdf" which retuns the total pages | 13:02.41 |
| | but imagick performance is dead slow when file is bigger | 13:03.40 |
| kens | gs -dNODISPLAY -q -sFile=<input pdf name> gs/toolbin/pdf_info.ps | 13:04.36 |
| | Will return the output on stdout I believe. You'll need to parse teh output to get the number opf pages | 13:05.01 |
| | Or you could use MuPDF. | 13:05.22 |
| | Or write a very simple piece of PostScript and run that instead of pdf_info.ps | 13:05.42 |
| | %! | 13:06.15 |
| | File dup (r) file runpdfbegin | 13:06.15 |
| | ( ) print print ( has ) print PDFPageCount =print ( pages.\n) = | 13:06.15 |
| | flush | 13:06.15 |
| | Umm, that lost a line. Let me know if you want ti and I'll make more of an effort | 13:06.39 |
| CoolCoder | yes. write in pastebin or something please :D | 13:07.25 |
| kens | Robin_Watts : I can't find that PDF file anywahere, or instructions where to get it. | 13:07.34 |
| Robin_Watts | kens: Thanks. I'll have to wait for ray. | 13:07.49 |
| Robin_Watts | lunches | 13:07.57 |
| kens | %! | 13:08.54 |
| | File dup (r) file runpdfbegin | 13:08.54 |
| | (file has ) print PDFPageCount =print (pages.\n) == flush | 13:08.54 |
| | Damn, it still choked on the '/' | 13:09.07 |
| | One more try | 13:09.13 |
| | "%! | 13:10.04 |
| | "File dup (r) runpdfbegin | 13:10.05 |
| | "/PDFPageCount pdfpagecount def | 13:10.05 |
| | (file has ) print PDFPageCount =print ( pages.\n) == flush | 13:10.05 |
| CoolCoder | http://pastebin.com/ | 13:10.11 |
| kens | Just strip of the initial double quotes | 13:10.17 |
| | Save that as a file, then use the same invocation to GS above, but instead of pdf_info.ps specify the file you saved that lot into. | 13:10.52 |
| CoolCoder | ok | 13:11.01 |
| kens | That should just pinrt "file has x pages." on stdout. Obviously you could simplify even further if that's too much | 13:11.27 |
| CoolCoder | ty | 13:11.47 |
| kens | BTW don't try to run that on anything except Ghostscript, it won't work :-) | 13:11.56 |
| CoolCoder | http://pastebin.com/m87CsLZ6 | 13:12.01 |
| | check this is correct | 13:12.06 |
| kens | Looks fine | 13:12.18 |
| | Notice that 'File' is the data you supply on the command line as -sFile=... | 13:12.43 |
| | It needs to be a fully qualified path | 13:12.53 |
| CoolCoder | ok | 13:13.32 |
| | gs -dNODISPLAY -q -sFile=<www09-photos.pdf name> ps_file.ps this will be the command? | 13:14.26 |
| | ps_file.ps is the file postscript | 13:14.54 |
| kens | Yes, presuming that's correct for your filename. THat will need to be in the current directory, as will ps_file.ps. | 13:15.21 |
| | filename = PDF filenaem | 13:15.33 |
| CoolCoder | GPL Ghostscript 9.01: Unrecoverable error, exit code 1 | 13:15.34 |
| kens | No more output ? | 13:15.55 |
| CoolCoder | no | 13:16.23 |
| kens | Hmm try witout -q | 13:16.32 |
| CoolCoder | same | 13:17.01 |
| kens | Are you doing this on teh command line ? | 13:17.09 |
| | If so try simply 'gs;' | 13:17.15 |
| CoolCoder | yes | 13:17.15 |
| kens | gs | 13:17.19 |
| | If you get a "GS>" prompt, type quit | 13:17.32 |
| CoolCoder | i am doing it in the terminal of linux | 13:18.04 |
| | not GS | 13:18.09 |
| kens | OK | 13:18.09 |
| | GS will *give* you a prompt | 13:18.19 |
| | Its interactive in this mode | 13:18.29 |
| CoolCoder | "gs -sFile=<pdf_file.pdf name>ps_file.ps" gives GPL Ghostscript 9.01: Unrecoverable error, exit code 1 | 13:18.47 |
| kens | No, just type 'gs' | 13:19.01 |
| | wihtout the quotes obviously | 13:19.07 |
| CoolCoder | done | 13:19.13 |
| kens | Do you get a prompt ? | 13:19.18 |
| CoolCoder | yes | 13:19.22 |
| kens | OK then type quit | 13:19.27 |
| | Just proving GS wortks at all | 13:19.35 |
| CoolCoder | back to terminal prompt | 13:19.41 |
| kens | Good | 13:19.44 |
| CoolCoder | its working :P | 13:19.47 |
| kens | I know it seems stupid, but.... | 13:19.59 |
| CoolCoder | np. go head | 13:20.08 |
| kens | Oh wait. | 13:20.15 |
| | You put <> round the filename, I meant that as delimiters for you, you don't type those in | 13:20.33 |
| | So: | 13:21.07 |
| | gs -sFile=pdf_file.pdf ps_file.ps | 13:21.07 |
| CoolCoder | this is the output http://pastebin.com/2kXuZ1CQ | 13:22.21 |
| kens | Yes, thought as much. | 13:22.35 |
| | The previous command used > so it overwrote ps_file.ps with the error message. | 13:22.51 |
| | You'll have to remake ps_file.ps | 13:22.59 |
| CoolCoder | ok | 13:23.09 |
| | http://pastebin.com/kN5HA9LX this is the ps_file.ps now | 13:24.16 |
| kens | OK try that. | 13:24.27 |
| CoolCoder | same thing | 13:24.35 |
| kens | Same how ? Undefined in GPL ? | 13:24.55 |
| CoolCoder | http://pastebin.com/4BFFX2SV | 13:25.44 |
| kens | OK so undefinedfilename means it couldn't find the file. | 13:26.05 |
| | The file in question being ps_file.ps | 13:26.17 |
| | Which suggests the file is not in the current directory | 13:26.48 |
| CoolCoder | I have given the full path of the ps file | 13:27.10 |
| | then also same thing | 13:27.12 |
| | its now saved in Desktop | 13:27.20 |
| kens | Not a Ubuntu expert, don't know where esktop would be. | 13:27.37 |
| CoolCoder | one sec | 13:27.40 |
| kens | You can of course also use ./ps_file.ps if its in the current directory, just to be certain. | 13:28.10 |
| CoolCoder | gs -sFile=/home/amjith/Desktop/pdf_file.pdf /home/amjith/Desktop/ps_file.ps this full path of both files gives the same error | 13:28.56 |
| kens | Well Ghostscript is saying ti can't find the file under that name. You don't have any capitalisation problems there ? | 13:29.27 |
| CoolCoder | no | 13:29.44 |
| | Error: /undefinedfilename in (ps_file.ps) | 13:30.08 |
| | which is the field used in the ps? I am not sure about ps | 13:30.38 |
| kens | The variable File is defined on the command line as -sFile=...pdf_file.pdf in your example | 13:31.10 |
| | ps_file.ps then uses File to open the PDF file and get some information from it. | 13:31.30 |
| | The only place I can see where that error could be coming from is the command line. Which says that the file isn't in the location given on the command line | 13:32.19 |
| CoolCoder | How we can change the command | 13:33.28 |
| | Its just curios about knowing ghostscript have no way to return number of pages. | 13:33.59 |
| kens | Well it need sot be correct for your setup. I can't tell you what that is, because I'm not sitting in front of your machine. | 13:34.00 |
| | CoolCoder : Why should it ? Ghostscript is a rendering library | 13:34.21 |
| | Initially intended for PostScript , now capable of handling PDDF, PCL, PXL and XPS | 13:34.40 |
| CoolCoder | ok | 13:35.01 |
| kens | But th information is there, and can be extracted. | 13:35.11 |
| CoolCoder | i think this error is different http://pastebin.com/SafJX3cB | 13:36.54 |
| kens | Yes that is indeed different | 13:37.16 |
| | You are now executing the PostScript file. | 13:37.24 |
| | OK in ps_file.ps remove the 'dup' | 13:37.52 |
| | Also that is missing a line | 13:38.06 |
| | after runpdfbegin should be : | 13:38.33 |
| | "/PDFPageCount pdfpagecount def" | 13:38.41 |
| | You know, it would be easier just to use the pdf_info.ps file. | 13:39.23 |
| tor8 | Robin_Watts: gah. load_links struct ownership is a mess, and we haven't done refcounting of linked lists in mupdf anywhere before... | 13:39.24 |
| kens | IN gs/toolbin | 13:39.35 |
| CoolCoder | http://pastebin.com/fdSucRcU this is the file now? | 13:39.58 |
| kens | Looks like it, but let me try it first. | 13:40.18 |
| | THere's a '/' missing from PDFPageCount | 13:41.45 |
| | THe first one | 13:41.52 |
| CoolCoder | added | 13:41.58 |
| | Error: /typecheck in --setfileposition-- | 13:41.59 |
| kens | Give me a minute, I wasn't finished.... | 13:42.07 |
| CoolCoder | ok | 13:42.28 |
| kens | Getting permissions errors | 13:43.04 |
| CoolCoder | did with root user | 13:43.27 |
| kens | No, I am | 13:43.32 |
| CoolCoder | stll the same error | 13:43.32 |
| | ok | 13:43.34 |
| | please type http://pastebin.com/ then submit paste URL here? | 13:43.37 |
| | (easy to take code without mistakes) | 13:43.58 |
| Robin_Watts | tor8: Yes. | 13:46.31 |
| | I was vaguely thinking about this. | 13:46.46 |
| | It would be nice to be able to have display lists as being storable things. | 13:47.29 |
| tkamppeter | Who is the master of the X11 output device? I got the RC built with x11 now, but the output is terribly slow. | 13:47.31 |
| Robin_Watts | tor8: I think to do such things we need a 'header' object that's fz_storable, and the actual list hangs off that. | 13:48.28 |
| kens | CoolCoder: | 13:49.14 |
| | http://pastebin.com/GMM4YTBM | 13:49.14 |
| CoolCoder | kens: excellent | 13:49.46 |
| kens | Works OK ? | 13:49.52 |
| CoolCoder | yes | 13:49.57 |
| kens | Glad to hear it. | 13:50.02 |
| tor8 | Robin_Watts: that's a lot of extra types though, and removes some of the simplicity of simple linked lists | 13:50.06 |
| kens | Back to bugs :-( | 13:50.09 |
| Robin_Watts | tor8: indeed. | 13:50.15 |
| tor8 | though, fz_storable isn't big so it could live in each node without too much pain | 13:50.36 |
| | the display list is opaque, so that one could get a header for the public api | 13:50.58 |
| | ie fz_storable header | 13:51.14 |
| Robin_Watts | if we're encouraging people to keep display lists kicking around, we really don't want to bloat them more than we have to. | 13:51.20 |
| CoolCoder | kens: you are awesome. thanks for help. this saved my big time. i did the same code in PHP to find the count. but i was not satisfied. PHP code is here http://pastebin.com/QtpaBgXK and in Imagic which kills server if file is big | 13:51.52 |
| tor8 | Robin_Watts: first draft of fz_document interface pushed. the pdfapp viewer uses the interface, but nothing else. | 13:52.12 |
| | Robin_Watts: yeah, I'm worried enough as it is by keeping it as a linked list rather than a dynamic array | 13:52.48 |
| Robin_Watts | hold on a mo... | 13:53.08 |
| | What's the stack stuff in the display list about? | 13:53.19 |
| kens | CoolCoder I don't speak PHP I'm afraid, but I'm happy to hear its working. It shoudl be quick because the page tree is separate to the page contents, so its very quick to parse out. | 13:53.25 |
| CoolCoder | ty | 13:53.40 |
| kens | You are very welcome | 13:53.47 |
| Robin_Watts | OK, that's only used when writing ? | 13:54.38 |
| | We already could add an fz_storable thing into fz_display_list with no problems. | 13:55.05 |
| tor8 | Robin_Watts: something to do with clip mask culling during playback I think | 13:55.25 |
| | to compute clipped bounding boxes for all the nodes | 13:55.39 |
| | and yes, you're right, making the display list storable would be trivial :) | 13:55.55 |
| Robin_Watts | I think the stack is used to compute bboxes during writing, it's not touched during reading. | 13:55.56 |
| | I was worried about multi-threading for a moment there :) | 13:56.12 |
| tor8 | correct, it's used to build the display list, not during playback which is a read-only operation :) | 13:57.04 |
| | Robin_Watts: I went with the upcasting shim layer; the details can be tweaked later but the public api should be stable at least | 13:59.25 |
| | but I think we want to add reference counting to the fz_link struct | 13:59.35 |
| Robin_Watts | nice. | 13:59.36 |
| | Sounds reasonable to me. | 13:59.50 |
| tor8 | given that we generally load it at page-loading time but that's not a strict requirement | 13:59.56 |
| Robin_Watts | At the moment the viewer 'takes ownership' by reading it and setting the link to NULL. | 14:00.12 |
| tor8 | yeah, I saw that bit of nastiness when updating pdfapp.c | 14:00.41 |
| Robin_Watts | Because we populate the link list in xps as we run the page, I have to be careful not to add links in multiple times. | 14:01.42 |
| | Which is why I had the 'links_resolved' bool in there. | 14:01.51 |
| | But that gets screwed up by the app taking ownership. hence the current bug. | 14:02.06 |
| tor8 | the links_resolved bool will have to stay regardless, in case there are no actual links on the page | 14:11.25 |
| marcosw | my internets connection is very poor this morning, which is why the cluster is having trouble. I've downed the machines at my house until my connection improves. | 15:15.37 |
| kens | had that problem yesterday | 15:15.54 |
| tor8 | Robin_Watts: in the name of consistency ... ugh. the pdf_ functions are pretty random about whether they take a pdf_document or fz_context. rather annoying IMO. | 15:18.33 |
| Robin_Watts | Make them all take a doc? | 15:20.27 |
| kens | Ooh, lots of seg falts with reference counting change | 15:20.51 |
| Robin_Watts | Well... Making them take a doc ties them all to a single thread. | 15:21.35 |
| | I suspect that may be what we want though. | 15:21.44 |
| | We may want to consider an fz_doument_change_context call at some point. | 15:22.26 |
| | tor8: essentially, any function that touches (or might touch) the underlying file should take a doc. | 15:32.21 |
| | tor8, sebras: I wonder whether it might not be worth sebras working directly on the trunk rather than a branch. | 15:37.41 |
| | That way if we alter functions that he's already documented, we can immediately update them rather than him having merge pains when he's finished. | 15:38.16 |
| sebras | Robin_Watts: I spoke with tor8 about this last night. | 15:41.59 |
| | my intent is to finish of the text for the initial set of functions. | 15:42.13 |
| | when that is done I want tor8 to merge this to master and then I'll do incremental commits after that. | 15:42.43 |
| Robin_Watts | ok. | 15:43.03 |
| tor8 | Robin_Watts: yeah, I think it's pretty safe to assume all pdf_ functions to be called from one thread and make them all take a pdf_document | 15:43.15 |
| | any multithreading will happen with fz datastructures | 15:43.34 |
| | the display lists, pixmaps, etc | 15:43.41 |
| Robin_Watts | tor8: You know that mupdf is failing all over the place in the cluster at the moment, right ? | 15:44.44 |
| | Has been since the fz_link refcounting commit. | 15:45.13 |
| tor8 | Robin_Watts: yeah, I noticed that :( | 15:46.14 |
| Robin_Watts | tor8: Urm... Have you got fz_drop_link working recursively? | 15:55.16 |
| | That'll blow the stack on index pages | 15:55.29 |
| | Might I suggest a while loop? | 15:56.02 |
| malc_ | build/release/libfitz.a(doc_link.o): In function `fz_free_link_dest': | 16:53.15 |
| | doc_link.c:(.text+0x0): multiple definition of `fz_free_link_dest' | 16:53.15 |
| Robin_Watts | malc_: make clean ? | 16:54.59 |
| malc_ | Robin_Watts: that did it.. thanks | 16:57.26 |
| Robin_Watts | great :) | 16:57.38 |
| Robin_Watts | does the ray_laptop summoning dance. | 17:03.53 |
| henrys_laptop | is that sms? | 17:06.08 |
| Robin_Watts | Nope. I wave caffiene under my webcam. | 17:06.29 |
| henrys_laptop | he's an american tea won't work. | 17:07.03 |
| | just a foot of snow a lot less than predicted. | 17:07.28 |
| malc_ | 30cm of snow.. pathetic | 17:08.14 |
| Robin_Watts | 30.5cm... | 17:08.40 |
| malc_ | 1 foot = 0.3048 meters | 17:08.58 |
| | google told me so | 17:09.01 |
| | must be true | 17:09.04 |
| Robin_Watts | I have an idea that might help with some of ray's customers slow files. | 17:09.24 |
| malc_ | plus we obviously disagree on rounding mode | 17:09.26 |
| Robin_Watts | malc_: no , just the number of decimal places. | 17:10.01 |
| henrys_laptop | Robin_Watts:so I guess you have everything running and all. | 17:10.01 |
| Robin_Watts | henrys_laptop: I have it building. Their profiles are a bit of a mystery to me, but... | 17:10.21 |
| henrys_laptop | malc_:where are you? | 17:10.22 |
| malc_ | Robin_Watts: no, i round towards negative infinity | 17:10.37 |
| | henrys_laptop: RF | 17:10.45 |
| Robin_Watts | this particular file seems to filling an image mask with a halftoned color. | 17:12.00 |
| | inside a clippath. | 17:12.09 |
| | So we have code that looks for runs of 1's in the mask and then outputs them as filled rectangles. | 17:13.13 |
| | 3.8Million filled rectangles. | 17:13.21 |
| | For each of those rectangles, we perform a clip operation. | 17:13.50 |
| malc_ | GPU to the rescue :) | 17:14.00 |
| | or some smarts | 17:14.09 |
| Robin_Watts | BUT... the clippath we are filling trivially covers the entire image. So why use the clippath at all? | 17:14.20 |
| | I'm experimenting with a new function "gx_make_clip_device_on_stack_if_needed" which does the same as "gx_make_clip_device_on_stack" but takes x,y,w,h too, and checks for trivial inclusion/exclusion. | 17:15.24 |
| henrys_laptop | Robin_Watts:which file is this? | 17:16.33 |
| Robin_Watts | WWTTN1CT_6Pages.pdf | 17:16.52 |
| | Their profile seems to miss functions out. | 17:17.11 |
| | and the timings seem similarly wierd. | 17:17.30 |
| | I'd rather have been looking at their slowest file (PWTTQ1CC.pdf) but I can't find a copy. | 17:18.26 |
| henrys_laptop | but the clip device shouldn't have been installed if clipping isn't needed - it is checked when the image is constructed. | 17:19.24 |
| Robin_Watts | Where? | 17:20.10 |
| | I'm getting calls into gx_default_fill_mask | 17:20.26 |
| henrys_laptop | the same place it sets up the rop_dev... | 17:20.38 |
| | hang on let me look. | 17:20.46 |
| Robin_Watts | gx_default_fill_mask: x=5b8 y=da w=62 h=6f | 17:21.52 |
| henrys_laptop | penum->clip_image is the boolean that triggers installing the clip device gxipixel.c:712 ... | 17:22.44 |
| scottsan | Can one of you guys tell me which version of GSView we are now distributing? Thanks | 17:22.54 |
| Robin_Watts | pcpath->inner_box=pcpath->outer_box=c800,0, 27100,10000 | 17:23.04 |
| | Morning scottsan. | 17:23.18 |
| | We don't distribute it, we only point to Russels site - or so I thought... | 17:24.03 |
| | http://pages.cs.wisc.edu/~ghost/gsview/index.htm | 17:24.15 |
| | That has 4.9 and 5.0 on it. | 17:24.22 |
| tkamppeter | chrisl, all OK with current gs905 GIT state. All working. Tested building and running it and uploaded it to Ubuntu Precise. | 17:24.22 |
| chrisl | tkamppeter: great, thanks | 17:25.12 |
| henrys_laptop | scottsan:we aren't distributing it yet we just bought the rights to the name russell still handles it. | 17:25.17 |
| Robin_Watts | henrys: This is in clist playback. I don't go through gxipixel.c | 17:25.39 |
| henrys_laptop | ah I see | 17:26.20 |
| scottsan | Thank you. | 17:31.32 |
| marcosw_ | henrys_laptop: support meeting? | 17:40.56 |
| henrys_laptop | sure we can do it now | 17:42.45 |
| | sure we can do it now | 17:42.59 |
| | start with 692818? | 17:44.11 |
| marcosw_ | I'm still having internet issues; can't get the bugzilla search page to load. give me a sec. | 17:44.53 |
| henrys_laptop | okay | 17:45.01 |
| Robin_Watts | I created 692818. It arguably should be assigned to mvrhel, rather than tor8. | 17:47.21 |
| marcosw_ | search results are now up | 17:47.22 |
| | now waiting for bug 818 to load :-) | 17:47.34 |
| Robin_Watts | Likewise 819 | 17:47.52 |
| marcosw_ | henrys_laptop: shall we reassign 818 and 819 to mvrhel? | 17:48.58 |
| henrys_laptop | yeah I'm doing that with a reminder xps has little priority right now. | 17:49.24 |
| | continuing on | 17:50.52 |
| marcosw_ | what's the next bug that needs to be discussed? 823 and 824 are okay. | 17:51.17 |
| | should 826 to to mvrhel or do you think it's an interpreter issue? | 17:52.03 |
| henrys_laptop | I think alex should analyze simplify - and off to michael. | 17:53.02 |
| | I see these problems and I wonder if we should just have an automated regression check. | 17:53.30 |
| | do you want to drive? | 17:53.45 |
| | I update 826 | 17:54.52 |
| marcosw_ | You should update the bugs, my connection is still problematic. | 17:55.41 |
| henrys_laptop | up to 830 | 17:56.11 |
| marcosw_ | 830 is already fixed. | 17:56.40 |
| henrys_laptop | I'm inclined to assign 831 to tkamppeter | 17:56.54 |
| marcosw_ | or you could assign it to me, I can take a look at the https://bugs.launchpad.net/hplip/+bug/924631 bug report | 17:57.43 |
| | and see if there is enough information to reproduce it. | 17:57.53 |
| henrys_laptop | since I have completion for your name in my browser I'll take that option | 17:58.21 |
| | 832 is the p1 | 17:59.34 |
| marcosw_ | 832 is being worked on. I've updated the customer on our progress. | 17:59.46 |
| henrys_laptop | we were waiting for cpsi output on this. | 18:00.00 |
| | I can also print it on my HP printer but it | 18:01.03 |
| | is not an adobe rip. | 18:01.11 |
| marcosw_ | the CPSI comment is pretty recent :-) | 18:01.17 |
| | what to do about 833? | 18:02.04 |
| henrys_laptop | math stuff? | 18:03.18 |
| marcosw_ | the last clang vs gcc difference with the memcmp() of structures issue. | 18:03.47 |
| | I've fixed most of them but there are some that I haven't done since the structures are really messy | 18:04.10 |
| | it's possible this is one of the remaining ones. | 18:04.31 |
| henrys_laptop | It would be nice to simplify one of these and really understand it. But we just fix all the structure things too and see if it goes away. | 18:05.09 |
| | can you assing the structure stuff to owners? | 18:05.22 |
| marcosw_ | I should probably just buckle down and finish it myself, it's not difficult, just time consuming. | 18:06.29 |
| henrys_laptop | I did assing 833 to you. | 18:06.31 |
| marcosw_ | thx. | 18:06.58 |
| | I should check to see if 835 is a regression but you can leave it assigned as is, in case Alex looks at it before I have time. | 18:07.58 |
| henrys_laptop | okay | 18:08.15 |
| marcosw_ | and 836 looks okay as is. anything else to discuss? | 18:08.46 |
| henrys_laptop | i think that's it. | 18:08.58 |
| marcosw_ | okay. I'm out of town next week but will have internet access so won't need support help. However, I'll be traveling on Tuesday, so will miss the meeting. I'll be online later that day and will read the logs. | 18:10.38 |
| henrys_laptop | got it. | 18:11.14 |
| marcosw_ | bbiab | 18:11.28 |
| Robin_Watts | tor8: ping ? | 18:15.49 |
| tor8 | Robin_Watts: pong. | 18:24.41 |
| Robin_Watts | Just got off the phone with the company. | 18:25.08 |
| | They are happy with what we told them. | 18:25.18 |
| tor8 | cool. :) | 18:25.28 |
| Robin_Watts | They asked when they could clone the context - I told them at any point. | 18:25.29 |
| | They think images render slowly, so I suggested an option to disable the pretty scaler for a render. | 18:26.04 |
| | That can go in the cookie. | 18:26.10 |
| | Then they can do 2 passes if required. | 18:26.17 |
| | They are also concerned about the amount of memory images will take in the displaylists if we hold them uncompressed. | 18:26.41 |
| | Currently they load images at render time, not interpretation time. | 18:26.56 |
| tor8 | I'd prefer a flag for options in the device | 18:26.58 |
| Robin_Watts | tor8: OK. | 18:27.09 |
| tor8 | same with the aa context stuff, I really think that should be part of the draw device | 18:27.13 |
| Robin_Watts | (but some mechanism like that) | 18:27.26 |
| tor8 | yeah. image scaling quality/performance tradeoff should be runtime selectable | 18:27.47 |
| | oh, and we should rip out the fz_accelerate stuff if we aren't going to use it | 18:28.05 |
| Robin_Watts | Having them load images from the file during rendering presents us with locking challenges. | 18:28.11 |
| | I suggested that we could maybe load the images compressed from the file, and only decompress on demand. | 18:28.34 |
| | they seemed to like that idea. | 18:28.43 |
| tor8 | mhm. I'd prefer allowing jpeg compressed data in the images stored in the display list | 18:28.49 |
| Robin_Watts | I said I'd talk it through with you. | 18:28.52 |
| | tor8: Isn't that what I just said? | 18:29.02 |
| tor8 | and zlib compressed random image data for non-jpeg images | 18:29.04 |
| | yes, I'm just typing blindly :) | 18:29.16 |
| Robin_Watts | In Picsels stuff, I short circuited the image decompression at the last stage of the filter. | 18:29.45 |
| | so flate/jpeg/jbig2 etc. | 18:30.02 |
| | OK, so it sounds like we're broadly in agreement. | 18:30.27 |
| tor8 | yes. | 18:30.55 |
| Robin_Watts | I'll have a play with that on monday. | 18:30.57 |
| | (on a branch :) ) | 18:31.14 |
| tor8 | we may also want to delay the "unpack" stage until render time to save memory on 1-bpp and non-alpha cases | 18:31.19 |
| | yeah. I'm going to break a lot of things on monday by changing all the arguments to pdf_document :) | 18:31.42 |
| Robin_Watts | unpack happens after decompression, right? | 18:31.49 |
| tor8 | yes. | 18:31.53 |
| | we decompress and unpack into fz_pixmap now | 18:32.01 |
| Robin_Watts | So if I'm stopping before the decompression stage, and doing that on demand, unpack will be done at render time too. | 18:32.16 |
| tor8 | we should probably change images to a new datatype so we can keep the simple fz_pixmap as draw device render targets | 18:32.25 |
| | a fz_image with the extra stuff needed to handle compressed and non-alpha and bpp != 8 cases | 18:33.14 |
| Robin_Watts | Yeah. fz_image maybe. | 18:33.18 |
| CoolCoder | I am gettign a warning "Warning: the map file cidfmap was not found." while run GS on terminal linux | 19:14.33 |
| chrisl | CoolCoder: unless you've added CIDFont mappings to that file, don't worry about it | 19:29.06 |
| CoolCoder | ok | 19:40.39 |
| Robin_Watts | Have a good weekend everyone. | 20:09.42 |
| malc_ | tor8: found a png mupdf barfs on | 20:42.38 |
| Robin_Watts | a pdf surely? | 20:55.51 |
| malc_ | self built cbz | 20:56.42 |
| | pdf doesn't support pngs to the best of my knowledge | 20:57.04 |
| Robin_Watts | We write pngs. | 20:57.20 |
| | tor8 has been dead set against using libpng. | 20:57.35 |
| malc_ | Robin_Watts: anywho, http://boblycat.org/~malc/969.png is the one mupdf doesn't like | 20:58.03 |
| sebras | Robin_Watts: I know that tor8 managed to display cbz the other day. but is that on master? | 21:02.10 |
| | yes it is! oh... | 21:02.42 |
| malc_ | Robin_Watts: and there are aparently probelms with xps links | 21:08.30 |
| sebras | malc_: I compressed 969.png into a .zip and ran mupdf on that. It runs fine, although valgrind claims there are memory leaks (I'm not sure why). | 21:13.21 |
| malc_ | sebras: yes, i'm trying to figure out which png it is really | 21:14.18 |
| | right.. one of those png's is really a gif, and mupdf can't handle those | 21:24.22 |
| sebras | malc_: ah. | 21:24.38 |
| | tor8: I pushed a fix on sebras/master for freeing the page structure when closing pdfapp. | 21:25.36 |
| malc_ | Robin_Watts: needed http://pastebin.ca/raw/2109511 to prevent segfaults | 21:38.30 |
| | Forward 1 day (to 2012/02/04)>>> | |
IRC Logs
