| | <<<Back 1 day (to 2013/06/18) | 2013/06/19 |
| mvrhel_laptop | nice email to the customer ray_laptop | 05:14.14 |
| | night all | 06:25.36 |
| chrisl | kens: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=42ee1094 | 07:39.10 |
| kens | I think the comment should read substream instead of subroutine ? | 07:40.15 |
| chrisl | Er, yes - let me double check..... | 07:40.42 |
| | Yeh, I'll change that | 07:41.04 |
| kens | IObviously its not a problem, just had me puzzled for a moment as to what I was looking at | 07:41.07 |
| chrisl | Another "interesting" fixed limit..... | 07:41.56 |
| kens | Which limit is that ? | 07:42.13 |
| | NUM_RESOURCE_CHAINS ? | 07:42.23 |
| chrisl | No the 11 substreams | 07:42.32 |
| kens | Really ? I hadn't noticed that, though it does prick a vague memory | 07:42.56 |
| chrisl | I think it's 11, but it's definitely a fixed limit | 07:43.15 |
| kens | That dereference in gdevpdf.c is a classic blunder | 07:43.59 |
| chrisl | To be honest, these things should be reference counted, but that would be a *massive* project | 07:44.23 |
| kens | Yes, it all started using garbage collected memory, and its way too late to change now | 07:44.46 |
| | And is the source of so many ehadaches | 07:44.55 |
| | All looks fine to me chrisl | 07:45.11 |
| chrisl | Thanks, I'll push that - another one down :-) | 07:45.40 |
| kens | I finally figured out what's wrong with bug #694353 as well. | 07:45.47 |
| | And indeed its a broken PDF | 07:45.58 |
| | Its been a busy week for bug reports :-( | 07:46.32 |
| chrisl | Yeh, I did wonder about Marcos suddenly reporting a bunch of PDF related bugs just after Alex's departure! | 07:47.11 |
| kens | Yeah, not fair! | 07:47.26 |
| | :-) | 07:47.31 |
| chrisl | So, is there a chance of handling the breakage in 694353? | 07:47.55 |
| kens | Yeah its not too bad, its an image which has 2 filters (and in itself this is mad its [/ASCII85Decode/DCTDecode]) | 07:48.34 |
| | And it has a /DecodeParams for the stream too, but the DecodeParams array is [<<>>] | 07:48.53 |
| | Notice only one set of params, for 2 filters..... | 07:49.02 |
| | And an irrelevant set at that | 07:49.13 |
| | I think if we ignore teh decodeparams where teh number is not consistent with teh number of filters, we'll be OK | 07:49.34 |
| | I'm just trying to code that neatly in PS at the moment (its a bit tricky becuae its used in a forall) | 07:50.01 |
| chrisl | That sounds sane - decode params are optional for those filters. Any filter it's required for will error out in the filter code | 07:50.16 |
| kens | Yes, and there is absolutely no way to know which filter teh params are for if there aren't the same number of each | 07:50.48 |
| chrisl | Any idea what created the PDF? | 07:51.22 |
| kens | iTextsharp I think, just a sec | 07:51.32 |
| chrisl | Oh, a regular source broken files :-( | 07:51.51 |
| kens | <</Producer(iTextSharpÂ’ 5.4.2 | 07:51.58 |
| | Note that the file contains several Flate Encoded streams, but feels it necessary to ascii85 encode the DCT stream.... | 07:52.32 |
| | Presumably just to make the biggest stream bigger | 07:52.47 |
| | OK that fix worked, now for a cluster push | 07:56.12 |
| chrisl | I beat you to it.... | 07:57.09 |
| kens | :-P | 07:57.18 |
| | It took me an age to find the offending area in teh PDF interpreter | 07:57.44 |
| chrisl | It's not very well laid out, IMO | 07:58.45 |
| kens | You mean its spaghetti | 07:58.58 |
| chrisl | Yeh, and the way it redefines procedures at various points drives me bonkers | 07:59.37 |
| kens | Me too :-( | 07:59.47 |
| chrisl | Again, I appreciate the idea of keeping the high level logic in Postscript, but there's *so* much in there that really should be done in C via internal operators, instead of coded in PS | 08:01.07 |
| kens2 | chrisl do you remember where Till posted instructions on how to figure out what CUPS is doing with Ghostscript ? ie getting hold of the PostScript file and the command line ? | 08:10.58 |
| chrisl | I'm not sure he ever did | 08:13.52 |
| kens2 | Oh, well no problem then. The erporter with the CUPS problem will have to figure it out themselves | 08:14.20 |
| chrisl | CUPS problem? Which one is that? | 08:14.46 |
| kens2 | Arrived last night 'PDF printing very slow' opr soemthing | 08:15.02 |
| | 694360 | 08:15.19 |
| chrisl | Hmm, I haven't been getting the bug notification mails :-( | 08:15.44 |
| kens2 | That's worrying | 08:15.54 |
| chrisl | This is the best I've had: https://wiki.ubuntu.com/DebuggingPrintingProblems#Capturing_print_job_data | 08:17.31 |
| kens2 | Hmm, what I really was hoping for was a GS command line. Of course, the reporter also hasn't suppliued an example file, nor indicated which pritner they are using.... | 08:18.46 |
| | If they are expecting me to go pore through the Debian bug report they are going to be disappointed | 08:19.14 |
| chrisl | My usual response is to say report it to CUPS, and the CUPS people can work out how to reproduce the problem in Ghostscript, then we'll investigate | 08:20.15 |
| kens2 | Oh and I see Till has declared it a GS bug, and then told the reporter what to do, which he hasn't followed. | 08:20.15 |
| chrisl | Hmmm, I'm not getting mails from gs-bugs, gs-commits nor gs-regression | 08:21.39 |
| kens2 | Well, Till told him to send the file and GS command line, I've told him to attach the file and give us a command line. So at least we're consistent | 08:21.43 |
| | chrisl I didnt' get mail for your commit | 08:21.55 |
| chrisl | Did you get mail for changing bugs status (I've changed three this morning)? | 08:22.23 |
| kens2 | I got mail for one, the pdfwrite one | 08:22.39 |
| | Presumably because I own it | 08:22.51 |
| chrisl | Yeh, so the lists are down :-( | 08:23.04 |
| kens2 | It looks that way | 08:23.13 |
| sebras | tor8: welcome to the internet. | 08:23.37 |
| kens2 | I did get some email to support, but my mailbox was surprisingly empty this morning. I naively assumed it was just a quiet night | 08:24.43 |
| chrisl | I got the ones about the HPGL file | 08:25.10 |
| kens2 | Yes, that's the ones I got,, also I think one from Ray and a customer | 08:25.25 |
| sebras | tor8: I notice that the header-fixes were merged. did they go in with any noticable changes compared to what we did? | 08:25.33 |
| kens2 | sent mail to tech and support | 08:26.05 |
| tor8 | sebras: uppercase include guard defines, but no other major changes | 08:26.07 |
| kens2 | tech seems to be wroking | 08:26.27 |
| sebras | tor8: alright, and fixing up the pdf #includes I assume. | 08:26.31 |
| kens2 | So the GMail lists are OK I guess, I think the other ones are 'non-gnu' lists or something like that | 08:27.01 |
| | And suddenly a mail deluge | 08:27.19 |
| sebras | tor8: or no, seems like you left that out of the patch series..? | 08:27.20 |
| chrisl | kens2: I restarted mailman on casper | 08:27.24 |
| sebras | tor8: is there a reason for that or did you just forget or postpone? | 08:27.42 |
| kens2 | chrisl I still don't see your other 2 changes, but maybe they'll be along i na bit | 08:28.27 |
| tor8 | sebras: postponed until we have cleaned up the pdf interdependecies | 08:28.59 |
| chrisl | kens2: They've reached me, I changed two bugs to "in progress" | 08:29.23 |
| kens2 | OK, not a problem. I think I'll close 694070 since the reporter says its fixed in 9.07 | 08:29.50 |
| chrisl | Yep, you could mention git bisect | 08:30.23 |
| kens2 | I did :-) | 08:30.32 |
| tor8 | Robin_Watts: too many different kinds of errors for that, we'd be better off looking up internationalised string from the error message string itself. | 08:30.32 |
| kens2 | Another massive mail delivery | 08:31.22 |
| | chrisl now I see your commit and bug changes | 08:31.50 |
| | No SEGVs excellent ! | 08:32.11 |
| chrisl | Strange, mailman was running on casper, but must have got it's knickers in a twist with the disk space incident | 08:32.31 |
| kens2 | I did wonder if it might have been related to that | 08:32.47 |
| chrisl | Well, it's working now.... | 08:33.11 |
| kens2 | Yep, I'm happy. I see you've picked up on that one you did the patch for | 08:33.29 |
| chrisl | Yep, I'm just going to commit that patch once I eventually clear the remaining stuff out my git stash | 08:34.19 |
| kens2 | Yes, I did say in the thread that seemed the best approach | 08:34.33 |
| chrisl | Especially as it seems to be in use anyway - despite my request | 08:35.15 |
| kens2 | :-) | 08:35.25 |
| Belleropone | hi | 09:26.35 |
| | anyone can help me with ghostscript ? | 09:26.49 |
| kens2 | Probably, depends on the question | 09:27.05 |
| Belleropone | hi kens2 | 09:27.27 |
| | i am using ghostscript to print my pdf outpur (from ERP) | 09:27.47 |
| kens2 | chrisl, shouldn't ghostbot be saying hello for us ? | 09:27.51 |
| chrisl | kens2: I dunno, I didn't mess with that - Robin_Watts did that stuff | 09:28.12 |
| Belleropone | that pdf should print from my solaris server to Epson dot matrix printer | 09:28.34 |
| | everything is ok 2 days ago | 09:28.51 |
| | but today the output from my printer is different | 09:29.22 |
| | i am using this command : | 09:29.42 |
| | gs -q -dNOPAUSE -dBATCH -sDEVICE=epsonc -sOutputFile={outfile} {infile} | 09:29.43 |
| kens2 | So something changed | 09:29.43 |
| | (dot matrix ? really ?) | 09:29.53 |
| Belleropone | yes, dot matrix, i need carbonize papers | 09:30.08 |
| | really | 09:30.15 |
| | carbonize paper, with 6 ply paper | 09:30.30 |
| kens2 | is astonished a dot matrix printer is still working :-) | 09:30.33 |
| Belleropone | nothing changed... :| | 09:30.59 |
| | FYI, i am using Oracle Applications ERP | 09:31.25 |
| | when i reprint the PDF output from 2 days ago (which is print nicely), today, some print is stack one another | 09:32.47 |
| kens2 | Well, if its different output, then something has changed | 09:33.06 |
| Belleropone | it is the same output | 09:33.40 |
| kens2 | You just said it was diffferent | 09:34.33 |
| Belleropone | the printer output is different | 09:34.45 |
| | :| really giving me headache | 09:35.34 |
| kens2 | So *something* has changed | 09:35.50 |
| | But I'm not sure how we can help you | 09:36.12 |
| | We certainly don't have a printer to try it on | 09:36.22 |
| Belleropone | oww | 09:37.25 |
| | hey, doesn't ghostscript have "paid" version ? | 09:37.56 |
| | where i can get support ? | 09:38.57 |
| kens2 | Its liccenced commercially, that's not quite the same as a paid version | 09:39.07 |
| | As a free user, your best bet for support is here, or stack overflow | 09:39.25 |
| | If you have a reproducible bug you cna raise a Ghostscript bug report | 09:39.46 |
| chrisl | Besides, if we actually can't help you, paying money won't change our abilities | 09:39.58 |
| Belleropone | ow... i thought it is like linux, where i can get support beside forum | 09:41.10 |
| kens2 | Artifex do support contracts, but as chrisl said, if we can't help you for free, we can't help you for money either | 09:42.31 |
| | Its also unclear why you think this is a Ghostscript problem | 09:42.47 |
| | It worked before, you haven't changed GS, now it doesn't. Seems to me *something* must have changed | 09:43.09 |
| chrisl | Belleropone: yes, but generally we can only help if we can either reproduce the problem, or at least have a *very* clear idea of what the problem is - that's true whether you're a free user or a commercially supported one. | 09:43.23 |
| Belleropone | i because i use the same pdf, and using the command i paste before | 09:44.02 |
| | the output from printer is different | 09:44.14 |
| | that's why i guess it is gs | 09:44.37 |
| | if i may, i can send you the scanned output from yesterday, and today | 09:45.09 |
| | not yesterday, i mean 2 days ago :D | 09:45.25 |
| kens2 | Maybe your printer is broken | 09:45.28 |
| | If you send Ghostscript the same input, under the same conditions, it will give you the same output | 09:46.06 |
| | So somethign must have changed to get different output | 09:46.25 |
| Belleropone | hmmmm | 09:47.04 |
| | let me take a deeper examine | 09:48.05 |
| | btw, who are you guys ? | 09:48.20 |
| | the developer ? | 09:48.27 |
| kens2 | Yes | 09:48.30 |
| Belleropone | ow... that's great :D | 09:48.42 |
| Robin_Watts | tor8: OK. So drop fz_throw, rename fz_throw_message to fz_throw ? | 09:48.47 |
| Belleropone | this ghostscript is great | 09:49.22 |
| | i really can print pdf to dot matrix printer | 09:49.39 |
| tor8 | Robin_Watts: yes. and rethrow. keep the caught/caught_message | 09:50.26 |
| Robin_Watts | tor8: What do you want to happen with rethrow? | 09:51.25 |
| | fz_rethrow() is the most common usage. | 09:51.32 |
| tor8 | my other thought was to reverse the two | 09:51.43 |
| Robin_Watts | fz_rethrow_message(); is less popular. | 09:51.46 |
| tor8 | fz_(re)throw -> fz_(re)throw_code | 09:52.00 |
| | fz_(re)throw_message -> fz_(re)throw | 09:52.10 |
| Robin_Watts | fz_rethrow never mentions a code. | 09:52.21 |
| | It's either fz_rethrow(ctx) or fz_rethrow_message(ctx, message, ...) | 09:52.38 |
| | The vast majority of calls are fz_rethrow(ctx) (though obviously it doesn't look like that from the patch) | 09:53.08 |
| tor8 | right, and there are almost 200 plain rethrows so going in and adding messages there will be a lot of work | 09:53.18 |
| sebras | tor8: weren't those the RJW-lines..? | 09:53.41 |
| tor8 | okay, so just drop fz_throw and rename fz_throw_message -> fz_throw, and leave rethrow and caught as is? | 09:54.40 |
| Robin_Watts | tor8: That would be my preference I think. | 09:54.53 |
| | Unless paulgardiner or sebras have any more cunning thoughts. | 09:55.09 |
| paulgardiner | Forgetting my reservations about the whole thing, I was liking the current names in the patch | 09:55.14 |
| tor8 | we have 450 regular throws in the old code | 09:55.18 |
| paulgardiner | What's the current planned changes? | 09:55.29 |
| Robin_Watts | paulgardiner: 1) Remove fz_throw entirely (as it's never used). 2) Rename fz_throw_message to fz_throw | 09:55.58 |
| tor8 | paulgardiner: we're discussing using: fz_throw(code, message), fz_rethrow() and fz_rethrow_message(message) | 09:56.17 |
| paulgardiner | Oh okay. I think I get it. So we have no way to throw without a message, but that's fine because we don't want one. Is that it? | 09:56.44 |
| tor8 | I proposed dropping fz_rethrow as well, but there are 200 call sites that need an informative message to be added | 09:56.46 |
| sebras | Robin_Watts: fz_throw() is used all over the place, is it not..? | 09:57.30 |
| paulgardiner | Maybe I'm misunderstanding , but that sounds odd. Wouldn't that be forcing us to add a message everywhere we have clean up code | 09:58.06 |
| tor8 | sebras: Robin_Watts has a patch on robin/master that adds an error code to fz_throw and turns all fz_throw inside a fz_catch into rethrows | 09:58.08 |
| Robin_Watts | sebras: All the fz_throws in the existing code became fz_throw_messages in my patch. | 09:58.10 |
| | We're proposing reverting that. | 09:58.19 |
| sebras | oh, let me have look at the correct branch. :) | 09:58.32 |
| tor8 | paulgardiner: yes, so I'm backing down on that proposal. | 09:58.35 |
| paulgardiner | Sounding good to me then | 09:59.05 |
| tor8 | fz_throw always with message, fz_rethrow with optional message is our current idea | 09:59.06 |
| paulgardiner | Yep good | 09:59.25 |
| | I still have some reservation about the whole idea, but I trust your combined intuition over mine alone :-) | 10:00.13 |
| sebras | tor8: sounds good to me. | 10:00.18 |
| tor8 | paulgardiner: your reservation about rethrow passing along the unmodified error code? | 10:01.19 |
| sebras | where did the use for the error code come up? what kind of errors do we want to be able to distinguish because we think we can fix them...? | 10:01.20 |
| tor8 | sebras: EAGAIN | 10:01.27 |
| | for progressive loading | 10:01.31 |
| sebras | tor8: so basically the reason is that we might see errors because we don't have enough of the pdf to display a particular page. | 10:02.21 |
| Robin_Watts | sebras: Right. And we spot the errors at the top level and know that we should retry later. | 10:02.46 |
| paulgardiner | tor8: my reservation is about having the message so devorced from the code. I think with most systems, you either rethrow, or throw a completely different error (hence different code and message). | 10:02.47 |
| | But perhaps this is simply better than what is usual. | 10:03.13 |
| sebras | paulgardiner: isn't rethrow just a replacement for writing out catch and throw..? | 10:03.42 |
| Robin_Watts | paulgardiner: I think we have to think of our system as a combined error/logging one. | 10:03.49 |
| | The error codes are normative, the error messages informative. | 10:04.13 |
| paulgardiner | Robin_Watts: yes, that had occured to me. It does make a lot of sense as such | 10:04.21 |
| Robin_Watts | When viewed like that, I don't think there is a strangeness. | 10:04.33 |
| paulgardiner | sebras: yes, but rethrow would not provide a new message | 10:04.43 |
| sebras | paulgardiner: true. we used to have an error stack however. | 10:05.15 |
| | paulgardiner: from a debugging perspective this makes sense (and would reqire rethrow to provide a message). | 10:05.34 |
| paulgardiner | Actually, yes. As combined error and logging it really does make a lot of sense. | 10:06.18 |
| sebras | Robin_Watts: hm.. what does "top level" in your example refer to? is that code still inside mupdf? | 10:07.11 |
| | Robin_Watts: or is that in the client app? | 10:07.19 |
| tor8 | sebras: client app, I believe | 10:07.47 |
| sebras | tor8: ok, so we're saying that we want to provide an error code (EAGAIN) to tell the client app whether it should try again (because the document might not have progressed far enought yet) or an error code (EINVAL) for documents that are actually broken..? | 10:09.01 |
| Robin_Watts | sebras: The former. | 10:09.22 |
| sebras | Robin_Watts: isn't it both cases? we want the app to be able to distinguish the two cases, no..? | 10:09.44 |
| Robin_Watts | sebras: Right, but the client app should check for the error being EAGAIN and try again. Anything else is taken to be fatal. | 10:10.17 |
| sebras | Robin_Watts: what operation failing inside mupdf would result in EAGAIN? failing to load an object? | 10:10.48 |
| | or failing to load a part of the xref perhaps. | 10:10.59 |
| Robin_Watts | sebras: specifically, it it thrown by the stream code when you try to read off the end of the current extent of the stream. | 10:11.36 |
| tor8 | Robin_Watts: how does that work with the xref loading? I vaguely recall something about the repair mode being driven incrementally. | 10:13.56 |
| paulgardiner | tor8: to get the windows build with openssh to work, I had to change the gen_adobe_ca.h include within crypt_pkcs7.c to ../generated/gen_adobe_ca.h. Will that be correct for other platforms too? | 10:16.29 |
| sebras | Robin_Watts: in you patch you have a TryLater in pdf_repair_obj() where it is trying to look for PDF_TOK_ENDSTREAM (and if it can not find it scan for it). | 10:19.03 |
| | Robin_Watts: wouldn't this cause problems with the approach you mentioned above? | 10:19.15 |
| Robin_Watts | tor8: Let me update the patch. | 10:21.25 |
| | sebras: hold on. | 10:21.32 |
| paulgardiner | tor8: progressive vs repair mode, I wondered that too. I wondered why the xref sections are needed at all when you are progressively loading the file, seeing as repair mode generates them on the fly | 10:21.38 |
| tor8 | paulgardiner: no, it should be done with -I../generated in the project or makefile | 10:21.56 |
| paulgardiner | tor8: okay. Will do | 10:22.12 |
| tor8 | I might have missed those in the vcproj files | 10:22.21 |
| | I think I did them though, but might've missed some | 10:22.37 |
| paulgardiner | Just missed a couple | 10:23.58 |
| | tor8: fix pushed to paul/master | 10:27.08 |
| Robin_Watts | There are some win32 solution fixes on robin master too. | 10:32.33 |
| | OK, robin/master updated as we talked about. | 10:41.44 |
| | robin/progressive has the latest version of the progressive patch on too. | 10:41.59 |
| tor8 | Robin_Watts: fz_rethrow_message should have __printflike() | 10:43.59 |
| Robin_Watts | tor8: will fix. | 10:44.14 |
| tor8 | also, what is fz_pass_thru? | 10:44.22 |
| Robin_Watts | paulgardiner: Your win32 fixes look good. | 10:44.35 |
| tor8 | Robin_Watts: your win32 header project fixes look good | 10:45.04 |
| Robin_Watts | tor8: fz_pass_thru(ctx, FZ_ERROR_TRYLATER) does: if (fz_caught(ctx) == FZ_ERROR_TRYLATER) fz_rethrow(ctx); | 10:45.05 |
| tor8 | fz_pass_through, please | 10:45.28 |
| Robin_Watts | saves me lots of typing (and saves a function call in the rethrow cases) | 10:45.32 |
| | ok. | 10:45.34 |
| paulgardiner | Is fz_pass_thru still needed? | 10:45.51 |
| Robin_Watts | paulgardiner: Yes. For the occasional place where TRYLATER has to be treated differently to GENERIC. | 10:46.20 |
| paulgardiner | Oh for places where we would otherwise loop rather than just throw a new message | 10:46.51 |
| Robin_Watts | I've pushed pauls win32 fixes along with mine. | 10:47.50 |
| paulgardiner | Hmmm. The name fz_pass_through doesn't give any indication that it's a thing specific to TRYLATER | 10:47.54 |
| Robin_Watts | paulgardiner: It's not. | 10:48.03 |
| | It passes the specified error through. | 10:48.14 |
| paulgardiner | Takes an error code | 10:48.16 |
| | ? | 10:48.17 |
| | as arg? | 10:48.22 |
| Robin_Watts | fz_pass_through(ctx, error) | 10:48.34 |
| paulgardiner | Right. | 10:48.40 |
| | I was just watching the talker. not looking at the patch. | 10:49.03 |
| tor8 | fz_rethrow_if(ctx, error) or some such? | 10:49.06 |
| Robin_Watts | tor8: I'm always prepared to accept better names :) | 10:49.27 |
| tor8 | fz_rethrow_error perhaps? pass_through can mean so many things | 10:49.51 |
| paulgardiner | fz_rethrow_specific? | 10:50.14 |
| tor8 | paulgardiner: I've got a list of nitpicks I found when slicing up the headers | 10:50.46 |
| Robin_Watts | Of that set, I prefer fz_rethrow_if | 10:50.57 |
| tor8 | pdf_specifics I'd write as pdf_document_cast (or something like it) | 10:51.35 |
| paulgardiner | yeah, if is good, accept it sounds like it should take a boolean | 10:51.36 |
| tor8 | HOTSPOT needs a PDF_ prefix | 10:51.41 |
| | the Ff field flags should be uppercase and also PDF_ prefixed | 10:51.52 |
| paulgardiner | tor8: yeah, pdf_document_cast is good | 10:51.58 |
| tor8 | and crypt_pkcs7 should be moved to pdf sources | 10:52.07 |
| | a general theme (for Robin_Watts as well) is conversion function naming | 10:52.31 |
| paulgardiner | yes, all sounds like improvements to me | 10:52.55 |
| tor8 | I prefer the form: Y Y_from_X(X) rather than Y X_to_Y(X) | 10:52.56 |
| | the bin2hex, cquote and fontdump tools could probably be combined into one tool with a flag for ascii string or hex dumping | 10:53.59 |
| | cquote probably doesn't strictly need to exist, bin2hex should work fine for it too | 10:54.30 |
| | but having a readable generated header is of course not a bad thing | 10:54.45 |
| Robin_Watts | The only possible objection I have to the conversion function naming is down to where we expect the function to live. | 10:56.19 |
| | elephant_to_giraffe lives in the elephant house. giraffe_from_elephant lives with the giraffes. | 10:56.49 |
| tor8 | there you go with your hierarchical naming again ;) | 10:57.16 |
| Robin_Watts | but with our new ability to split functional units into several compilation units without making the implementation details public, that's less of a problem. | 10:57.53 |
| tor8 | image_to_pixmap is the only X_to_Y variant left | 10:57.54 |
| Robin_Watts | ok, I'll fix it. | 10:58.12 |
| | So, did we have a winner in the fz_pass_thru sweepstakes? | 10:58.32 |
| | fz_rethrow_if ? | 10:58.47 |
| tor8 | Robin_Watts: fz_new_image_from_pixmap has the 'new' magic word in it | 10:59.14 |
| | depending on the reference counting, perhaps pixmap_from_image should have 'new' too? | 10:59.27 |
| | i.e. fz_image_to_pixmap -> fz_new_pixmap_from_image | 11:00.42 |
| | fz_rethrow_if looks funky, but it is the most obvious of the suggestions | 11:01.20 |
| | fz_rethrow_if_error or _if_code perhaps? or is that just making it longer but not improving clarity | 11:01.53 |
| Robin_Watts | I'll go with rethrow_if for now, and we can tweak it if we find a better version. I don't think this is being committed today :) | 11:02.39 |
| | OK, exception handling commit should be good to go. The rethrow_if stuff is in the progressive loading one (a new version of that is also up) | 11:03.44 |
| paulgardiner | fz_rethrow_specified_error | 11:03.51 |
| | But yes "if" is fine | 11:04.03 |
| Robin_Watts | paulgardiner: I'd prefer your earlier suggestion of rethrow_specific to that, but it's still too much to type :) | 11:04.29 |
| tor8 | exception patch LGTM | 11:04.59 |
| | I would suggest adding FZ_ERROR_MEMORY or OUT_OF_MEM as one of the codes thrown in malloc/realloc | 11:06.16 |
| | in case clients have their own caches they can clear out | 11:06.39 |
| | which our scavenging malloc can't touch | 11:06.54 |
| Robin_Watts | tor8: yeah, that occurred to me this morning (and I then promptly forgot it) | 11:10.25 |
| | I'm going for a run. Must read mvrhel's patches when I get back. | 11:11.06 |
| | tor8: For that purpose I'd rather expose a 'scavenge' callback in the context though. | 11:15.55 |
| tor8 | Robin_Watts: right. still, it might be a way to signal fatal errors separate from document-based errors | 11:21.21 |
| henrys | knew guillaume was going to say that sigh | 12:34.32 |
| Robin_Watts | tor8: good point. | 12:37.35 |
| tor8 | FILE, FORMAT or SYNTAX for document parsing errors? | 12:39.39 |
| | less crucial but if we're adding codes may as well make use of some basic categories | 12:40.01 |
| Robin_Watts | tor8: I think we should be driven by need in such things. | 12:40.44 |
| tor8 | fair enough. | 12:41.28 |
| | Robin_Watts: so, reshuffling source files? | 12:55.33 |
| | paulgardiner: any suggestions? | 12:55.49 |
| | sebras: you too. | 12:55.57 |
| sebras | tor8: pong. | 12:56.39 |
| tor8 | sebras: we want to clean up the top level directory of mupdf (it's getting cluttered) | 12:57.13 |
| sebras | tor8: maybe move android ios winrt win32 debian and friend under apps. | 12:57.49 |
| tor8 | one idea we discussed was putting the library source files in one directory (say "source" or "library") and the platform specific apps in another (say "platform") | 12:57.54 |
| sebras | I think that would go a long way actually. | 12:57.57 |
| paulgardiner | tor8: Not ignoring you - just struggling to think of anything useful to say | 12:58.01 |
| sebras | hm.. certs/ seems a bit unnecessary given that it is just a single file..? | 12:58.48 |
| tor8 | and another for "data" files (the stuff that gets compiled into generated) | 12:59.12 |
| sebras | tor8: could we put the cert-file there too? | 12:59.32 |
| tor8 | the names of the top level directories could possibly be discussed | 12:59.35 |
| | sebras: yes. | 12:59.39 |
| paulgardiner | There is already a grouping in fitz based on the part of the name before the first _ | 12:59.49 |
| Robin_Watts | back. | 13:00.02 |
| | I like "platform" | 13:00.10 |
| sebras | tor8: why is ucdn on the top level and not under thirdparty? | 13:00.13 |
| paulgardiner | Maybe those prefixes could become subdirectories | 13:00.26 |
| Robin_Watts | and "source" (or "src") would seem to be the convention that other people follow. | 13:00.39 |
| | paulgardiner: I'd like to drop the prefix_ from the fitz files, I think. | 13:00.57 |
| sebras | yes, platform is a good name. | 13:01.02 |
| | as is src given that we already conform to the standard of having an include directory. | 13:01.36 |
| paulgardiner | Robin_Watts: I was suggesting dropping the prefix on the files and putting them into directories named with the prefix | 13:02.02 |
| | ... assuming the prefix sharing is to do with modularity | 13:02.22 |
| Robin_Watts | I don't think that's warranted now, is it? | 13:02.29 |
| | The prefix sharing was partly to do with object files being uniquely named before. | 13:02.45 |
| sebras | Robin_Watts: so you favour fitz/open.c over fitz/stm_open? | 13:02.53 |
| | .c | 13:02.55 |
| tor8 | sebras: it's not a common upstream library | 13:02.56 |
| Robin_Watts | sebras: I favour fitz/stream.c over fitz/base_stream.c | 13:03.21 |
| tor8 | object file uniqueness is the main reason for the current prefix based file names | 13:03.32 |
| | that can be trivially solved in the makefile | 13:03.40 |
| | but maybe less so on android and msvc solutions? | 13:03.51 |
| paulgardiner | Probably not. Just a suggestion in reply to tor8's source-file-shuffling-suggestion request | 13:03.56 |
| Robin_Watts | If we split stream into separate .c's (say stream_open.c, stream_seek.c, stream_read.c etc) then I'd be happy with a prefix. | 13:03.56 |
| tor8 | Robin_Watts: stream-open.c, stream-seek.c, stream-read.c and stream-imp.h | 13:04.31 |
| Robin_Watts | tor8: oops, yes. | 13:04.39 |
| tor8 | pdf/stream.c is separate from fitz/stream.c though | 13:04.57 |
| | that's the kind of collision in the build system I'm wary of | 13:05.06 |
| | in the makefile I can easily add prefixes (or subdirs) in the build/debug/ output directory | 13:05.26 |
| | not sure how win32 vcproject handles it | 13:05.36 |
| | we can always drop the prefixes on fitz files | 13:06.19 |
| | whether we also drop the pdf- and xps- prefixes is the issue at hand | 13:06.32 |
| Robin_Watts | We might have to split libmupdf into libfitz/libpdf etc. | 13:06.38 |
| tor8 | Robin_Watts: in the vcproject? | 13:06.48 |
| Robin_Watts | yeah. | 13:06.55 |
| tor8 | well, that would work for me | 13:06.56 |
| | then they end up in separate output directories | 13:07.05 |
| Robin_Watts | indeed. | 13:07.10 |
| tor8 | libmupdf-fitz.lib libmupdf-pdf.lib libmupdf-xps.lib | 13:07.35 |
| Robin_Watts | Might have a slight wrinkle with circular dependencies. | 13:07.39 |
| tor8 | we shouldn't have any circular dependecies between the fitz/ and pdf/ stuff | 13:08.14 |
| Robin_Watts | fz_open_document (in libfitz) would depend on pdf_open_document (in libpdf) which would depend on fz_malloc (in libfitz) | 13:08.28 |
| tor8 | apart from that one, yes | 13:08.36 |
| Robin_Watts | libmupdf-doc :) | 13:08.49 |
| tor8 | but I think static libraries are safe for that though | 13:08.54 |
| | but might need convoluted linker lines. but libmupdf-doc is fine. | 13:09.12 |
| Robin_Watts | I think MSVC copes, but gcc et al don't. | 13:09.21 |
| tor8 | yeah. -lfitz -lpdf -lfitz is what's needed on some gcc based tool chains | 13:09.51 |
| | but the unix makefile should just make one libmupdf.a anyway, IMO | 13:10.16 |
| Robin_Watts | To play devils advocate... | 13:10.45 |
| | leaving the pdf_ prefixes does mean you can tell what the file is from the tab in MSVC alone. | 13:11.04 |
| tor8 | that's a good point | 13:11.29 |
| | source/pdf/pdf-stream.c then? | 13:11.35 |
| Robin_Watts | Yeah, drop the 'base_' and 'res_' ones from fitz. | 13:11.49 |
| tor8 | yeah. | 13:11.54 |
| Robin_Watts | and keep the pdf/xps ones, etc. | 13:12.02 |
| | paulgardiner, sebras: concur? | 13:12.08 |
| tor8 | I think I may want to keep the draw- prefix (but drop the draw files in fitz/) | 13:12.09 |
| | http://ghostscript.com/~tor/stuff/layout.txt | 13:12.30 |
| sebras | tor8: let me have a look. | 13:12.39 |
| tor8 | need comments on names | 13:13.01 |
| sebras | tor8: where did the include directory go? | 13:13.08 |
| tor8 | sebras: forgot it :) | 13:13.14 |
| Robin_Watts | I'd prefer resource to data, personally. | 13:13.15 |
| | sebras: The include directory is done :) | 13:13.26 |
| sebras | Robin_Watts: agree, data is a bit too abstract. | 13:13.37 |
| tor8 | yeah. resource is best. | 13:13.55 |
| sebras | tor8: you forgot apps/ too. | 13:13.57 |
| tor8 | sebras: apps is in source/tool/ | 13:14.05 |
| | or tools/ | 13:14.08 |
| | not decided on whether I like or hate plural s in directory names | 13:14.22 |
| Robin_Watts | I would prefer apps to tools. | 13:14.29 |
| tor8 | that directory would contain only the command line tools | 13:14.48 |
| | mutool and mudraw | 13:14.51 |
| Robin_Watts | tools possibly implies "tools used during the build", like echogs, or mkrom etc. | 13:14.53 |
| sebras | Robin_Watts: I guess the idea is that x11 will move out from there and into platform at some point. | 13:14.54 |
| tor8 | the pdfapp stuff would move into platform somewhere | 13:15.00 |
| Robin_Watts | OK., | 13:15.07 |
| tor8 | platform/viewer perhaps | 13:15.08 |
| sebras | tor8: alright. | 13:15.16 |
| | tor8: and ucdn? | 13:15.32 |
| tor8 | Robin_Watts: but yes, I see your point (re tools used during build) | 13:15.34 |
| | but those live in scripts | 13:15.40 |
| | sebras: in source/ | 13:15.47 |
| Robin_Watts | If the viewer is moving out, my apps objection is greatly reduced. | 13:16.01 |
| | I could live with tools. | 13:16.04 |
| sebras | Robin_Watts: how about "tool"? | 13:16.19 |
| Robin_Watts | sebras: Do we just have 1 ? | 13:16.29 |
| tor8 | no, we have many | 13:16.37 |
| Robin_Watts | Then tools, IMHO. | 13:16.47 |
| sebras | Robin_Watts: tor8 opted for tool though. | 13:16.48 |
| tor8 | but we have "include" not "includes" | 13:16.48 |
| Robin_Watts | "include files" | 13:17.00 |
| | and include is the "standard" | 13:17.07 |
| tor8 | resources too then? | 13:17.17 |
| | certs, fonts, cmaps? | 13:17.22 |
| Robin_Watts | resources (or 'res' cos I'm lazy) | 13:17.43 |
| | I reckon plurals, personally. | 13:17.52 |
| | scripts :) | 13:18.07 |
| tor8 | okay, reload the page | 13:18.07 |
| Robin_Watts | source, not library, personally. | 13:18.26 |
| tor8 | alright, I'll go with plurals | 13:18.56 |
| | library sounds a bit more like binaries would go there, but source contains only our library sources | 13:19.23 |
| | still, I'm fine with "source" | 13:19.34 |
| sebras | tor8: or sources? >;) | 13:19.44 |
| tor8 | sebras: source can be an "uncountable" noun :) | 13:19.58 |
| sebras | how about platforms? | 13:20.00 |
| tor8 | platform is short for platform specific source ;) | 13:20.13 |
| | we don't contain the actual platforms there | 13:20.20 |
| sebras | ok then. they aren't real objections. | 13:20.27 |
| tor8 | but I'll bow to a majority vote | 13:20.28 |
| Robin_Watts | platform | 13:20.35 |
| sebras | cbz would also go into source as I understand it. | 13:20.58 |
| | tor8: have you had customer requirements for .so? maybe it is wise to consider that about now since you will have to rewrite the Makefiles a bit. | 13:21.40 |
| | what is muimage.c and does it relly warrant a directory of its own? | 13:22.17 |
| tor8 | I personally think muimage can live with cbz | 13:22.44 |
| | sebras: it's a plain image fz_document type | 13:22.56 |
| | mupdf hello.jpg | 13:23.05 |
| Robin_Watts | I think every document type should get its own dir, personally. | 13:23.16 |
| tor8 | rename cbz to comic and support both zipped, unzipped directory and plain image files | 13:23.38 |
| | Robin_Watts: muimage.c is a bit generic of a name (it collides with many other "image" files) | 13:24.04 |
| Robin_Watts | If they use the same source, then share the dir. Currently they don't, so they shouldn't. | 13:24.13 |
| tor8 | Robin_Watts: rename muimage to img? | 13:24.25 |
| Robin_Watts | tor8: I'm always open to better names. | 13:24.28 |
| | ok. | 13:24.29 |
| tor8 | or jpeg? :) | 13:24.46 |
| sebras | tor8: do we support png? | 13:24.55 |
| tor8 | sebras: jpeg, png and tiff IIRC | 13:25.03 |
| Robin_Watts | sebras: jpg/png/tiff. | 13:25.07 |
| tor8 | same set as xps | 13:25.20 |
| | we could add jpeg2k fairly trivially | 13:25.33 |
| | but I don't see a lot of pressing need for it | 13:25.43 |
| sebras | tor8: then maybe cbz should be separate img for the time being imho. | 13:25.53 |
| Robin_Watts | lunches | 13:30.52 |
| tor8 | Robin_Watts, paulgardiner, sebras: http://ghostscript.com/~tor/stuff/fitz-files.txt | 13:39.00 |
| | list of new name candidates | 13:39.05 |
| | stext = structured text (the text extraction device) | 13:39.14 |
| paulgardiner | Looks pretty good to me | 13:40.23 |
| sebras | looks | 13:41.52 |
| tor8 | reload | 13:42.09 |
| sebras | tor8: crypt_pkcs7 -> dash. | 13:42.09 |
| tor8 | sebras: mv crypt_pkcs7.c ../pdf/ | 13:42.19 |
| sebras | tor8: I'd still appreciate if it was dashing(!) though. | 13:43.08 |
| | ...but something tells me that signature-checking never will be. | 13:43.23 |
| | tor8: I'd be tempted (given the naming and length of the files) to combine draw-scale*.c into one file. | 13:46.16 |
| | tor8: what is fitz-files.txt btw? I assume it shouldn't be in the listing..? | 13:46.57 |
| | tor8: func.c -> function.c? | 13:47.11 |
| tor8 | sebras: reload :) it's the list that I uploaded and I renamed func.c to function.c already :) | 13:47.22 |
| | sebras: draw-scale.c and draw-scale-simple.c are exclusive and alternative versions of the same code | 13:47.52 |
| | maybe a different scheme based on #ifdef is better there | 13:48.01 |
| | or runtime choice of the implementation | 13:48.17 |
| sebras | tor8: that might be even better. | 13:48.25 |
| | tor8: from an architectural standpoint it is strange that svg output is a device and pcl/pwg is not. | 13:49.07 |
| | tor8: where did strema-seek.c go? | 13:49.47 |
| | you mentioned it before. | 13:50.06 |
| tor8 | stream-seek was a hypothetical example | 13:50.27 |
| sebras | tor8: what is trans.c? the transitions? | 13:50.30 |
| | tor8: oh. I was suprised not to find it in the current source. :) | 13:50.49 |
| tor8 | yes, transitions. I'll rename. | 13:51.01 |
| sebras | tor8: I have no problem with the image- prefix. | 13:51.35 |
| tor8 | image.c has fz_image | 13:51.50 |
| | image-xxx.c works on fz_pixmaps | 13:51.55 |
| sebras | tor8: ok, so what about pixmap- then? | 13:52.19 |
| tor8 | possible. I'll let robin decide :) | 13:52.45 |
| | once he gets back from lunch... | 13:52.56 |
| | Robin_Watts: when/if we clean up the text extraction api more, text=input to device, raw-text=span soup, structured-text=analyzed and sorted text | 13:57.52 |
| Robin_Watts | load-xxx might be nicer than image-xxx. | 14:08.10 |
| | As otherwise you might be surprised to see that we handle images of type xxx without ever using the image-xxx file :) | 14:08.33 |
| tor8 | Robin_Watts: and device/output-svg? | 14:22.15 |
| Robin_Watts | dev-svg.c would work for me. | 14:25.17 |
| | If we DO want to use subdirs for devices, then I'd have thought that a subdir per device would make more sense than a subdir with all the devices in. | 14:25.51 |
| tor8 | so now we have some inconsistencies | 14:27.18 |
| | draw-device | 14:27.23 |
| | display-list without device prefix | 14:27.29 |
| | stext-extract | 14:27.33 |
| | device-bbox/trace | 14:27.44 |
| | device-svg | 14:27.47 |
| | stext-extract might become stext-device | 14:28.21 |
| | then svg-device and if svg gets more files then they can go with the svg- prefix as well or move into an svg-device subdir | 14:28.48 |
| | or the reverse: device-stext and device-draw and then auxiliary files stext-xxx and draw-xxx but that seems backwards to me | 14:30.07 |
| Robin_Watts | list-device, draw-device, stext-device | 14:30.44 |
| tor8 | I'd still go with display-list though (since it has both the device and the playback in one file) | 14:31.33 |
| Robin_Watts | tor8: we could now split it into 2 files plus an implementation header though. | 14:31.59 |
| tor8 | I don't want to split just yet, the playback part is only 200 odd lines | 14:33.07 |
| Robin_Watts | buys shoes identical to a pair I currently own off the web. helen would be ashamed of me. | 14:33.09 |
| tor8 | Robin_Watts: I buy shoes blindly off the web ;) | 14:33.31 |
| Robin_Watts | I don't think we need to get TOO het up about the internal naming as it's not a cast in stone public thing. We can rename etc later. | 14:33.58 |
| | consistency is nice though, of course. | 14:34.05 |
| tor8 | yes. so display-list.c to match the public display-list.h or list-device.c? | 14:34.24 |
| | this means we'll also end up with trace-device.c and bbox-device.c | 14:35.52 |
| Robin_Watts | Personally, list-device.c | 14:37.03 |
| tor8 | Robin_Watts: do we always want to build non-v8 versions even if v8 is present? | 15:37.47 |
| Robin_Watts | tor8: I would say so. | 15:38.12 |
| | Otherwise the cluster will only ever test the v8 versions, and we might break the others without realising. | 15:38.32 |
| tor8 | Robin_Watts: right. | 15:39.18 |
| Robin_Watts | Morning mvrhel_laptop | 15:55.53 |
| mvrhel_laptop | Good morning | 15:56.32 |
| Robin_Watts | I pushed your patches to golden (with a couple of whitespace fixes) | 15:57.20 |
| mvrhel_laptop | Robin_Watts: ok thanks. I am going to have more commit here in the next hour. mainly project compiler settings due to complaints form windows app certification | 15:57.54 |
| Robin_Watts | ok. | 15:58.04 |
| kens2 | OK that last bug has left me with a headache, so I'm off. Goodnight all | 16:05.45 |
| Robin_Watts | night kens2 | 16:05.55 |
| tor8 | Robin_Watts: two commits on tor/master and reshuffle proposal on tor/shuffle | 16:33.36 |
| Robin_Watts | tor8: ok. I'll look now. | 16:33.47 |
| | I've run into a problem with the error code stuff, and my head is frazzled. | 16:34.07 |
| | If the 'fz_always' block calls any functions that use try/catch it loses the errcode for the fz_catch. | 16:34.52 |
| tor8 | I'm pleasantly surprised that git rebase -i handles renames when moving edits backwards in time :) | 16:34.56 |
| | Robin_Watts: ohhh... that's a headache to solve I bet! | 16:35.40 |
| | Robin_Watts: what is the ctx->error->stack[i].code for? | 16:36.38 |
| Robin_Watts | That's the magic coe to make us enter always/catch correctly. | 16:37.02 |
| tor8 | hm, if code in fz_always block throws an exception, where do we end up? | 16:37.33 |
| Robin_Watts | catch. | 16:37.53 |
| tor8 | and the problem is that the second throw overwrites the first throw's code? | 16:38.19 |
| | I'm not sure I think that's actually a problem :) | 16:38.27 |
| | we were doing something that went wrong, and in the process of cleaning up, another error happened | 16:38.57 |
| Robin_Watts | tor8: The problem is that having a try is enough to overwrite the code. | 16:39.13 |
| | I think I need to move errcode into the indexed thing. Will ponder that. | 16:39.36 |
| tor8 | oh, right. | 16:39.42 |
| | you zero the error code on a try | 16:39.47 |
| Robin_Watts | yeah. | 16:39.53 |
| tor8 | would it be bad if we just left it as is on a try, and just set it to the code on throw, and reset on caught? | 16:40.20 |
| | maybe move to a temporary place on catch and move back from temporary on rethrow | 16:40.39 |
| Robin_Watts | tor8: That would require a function call on every catch. | 16:43.03 |
| | but only on 'taken' catches. | 16:43.34 |
| | actually, I can avoid the function call, I think. | 16:45.04 |
| tor8 | I think just setting on try should be enough for our purposes, no? | 16:45.31 |
| | and caught would always read out the latest thrown code | 16:45.44 |
| Robin_Watts | I currently set it to 0 on try. | 16:45.57 |
| | and that causes the problem. | 16:46.05 |
| tor8 | yes, I wonder why you need to do that though... | 16:46.18 |
| | I can't think of a reason | 16:46.25 |
| Robin_Watts | Why do I set to 0... | 16:46.28 |
| | good question :) | 16:46.39 |
| | Let me just try not doing that :) | 16:46.45 |
| | hah. That solves it. | 16:49.56 |
| | Thanks. | 16:50.10 |
| | tor8: The md5 pixmap stuff was in a separate file, so the linker can elide it for the 99% of programs that won't need it. | 16:59.12 |
| | We only use it in mudraw. No viewer will use it. | 16:59.42 |
| tor8 | Robin_Watts: the md5 functions are used in normal pdf crypto functions as well | 17:00.09 |
| | the basic password algorithm is md5 based | 17:00.19 |
| Robin_Watts | right, but that particular function (the md5 of pixmaps) is only used in the one place. | 17:00.31 |
| tor8 | and it's a tiny function... | 17:00.43 |
| Robin_Watts | right, it is a tiny function. | 17:01.01 |
| | but it doesn't hurt us to have it separate. | 17:01.10 |
| tor8 | if it had pulled in a big dependency that isn't normally used, I'd agree it would belong in a separate link unit | 17:01.32 |
| | but since md5 is already needed elsewhere, I didn't see the harm | 17:01.43 |
| Robin_Watts | ok. | 17:02.08 |
| | they both look fine. | 17:02.20 |
| | I have the x11 changes here too, but you beat me to it. | 17:02.34 |
| tor8 | and it seemed a bit silly to have a file with 5 lines in it :) | 17:02.44 |
| | so the shuffle branch has a pretty big reworking of the Makefile | 17:03.33 |
| | the vcprojects will need a lot of work as well | 17:03.44 |
| | and I'm considering just swallowing the ucdn files into source/fitz/ and be done with it | 17:03.59 |
| Robin_Watts | tor8: I pushed mvrhel_laptop's commits. So I'll need to rebase yours on top of them. | 17:13.54 |
| | Unless you want to do it. | 17:13.57 |
| tor8 | I'll rebase | 17:14.32 |
| | Robin_Watts: ./build/generated or ./generated ? | 17:16.36 |
| Robin_Watts | Having everything that gets built in build is nice, but might be odd for android etc. | 17:17.59 |
| | as they don't build in build. | 17:18.06 |
| | and nor does win32. | 17:18.11 |
| | So generated might make more sense. | 17:18.20 |
| tor8 | Robin_Watts: okay. new tor/shuffle | 17:21.02 |
| | and tor/master rebased | 17:21.08 |
| Robin_Watts | I've pushed 2 of the 3 from tor/master | 17:21.36 |
| | Is the third one ready to go? | 17:21.48 |
| tor8 | yes. that's a harmless Makethird fix | 17:22.00 |
| | that's not affected by the directory layout, but prepares for it | 17:22.16 |
| Robin_Watts | Pushed. | 17:24.00 |
| | An exception handling fix on robin master | 17:24.09 |
| | The Android build is broken; I have a commit up that fixes some of it, but I need to fix the includes etc too. | 17:24.33 |
| tor8 | Robin_Watts: the android build needs to be remade significantly for the include and sources earthquakes | 17:25.08 |
| | exception fix on robin/master looks good | 17:25.21 |
| | the exception fix for android on robin/master is also good | 17:26.15 |
| Robin_Watts | Thanks. | 17:26.39 |
| tor8 | when updating android, could you check if we can get rid of Core2.mk? | 17:26.55 |
| | LOCAL_SRC_FILES could possibly use the same $(wildcard ) tricks | 17:27.31 |
| Robin_Watts | tor8: I think I plan to leave android broken until after shuffle goes in. | 17:28.29 |
| tor8 | I'm fairly happy with the shuffle on tor/shuffle now | 17:30.58 |
| | but do give it a thorough look | 17:31.07 |
| Robin_Watts | It's a bit of a nightmare to review because of the way viewgit shows it. | 17:31.35 |
| tor8 | Robin_Watts: just check it out :) | 17:32.09 |
| | gitk and viewgit both suck for viewing file renames | 17:32.20 |
| Robin_Watts | win32 projects need fixing. | 17:33.54 |
| tor8 | I was hoping you could do that :) | 17:34.03 |
| Robin_Watts | will do. | 17:34.09 |
| tor8 | for the makefile I made three libs | 17:34.14 |
| Robin_Watts | That will let me look at stuff. | 17:34.16 |
| tor8 | libmupdf.a and libmupdf-js-none.a and libmupdf-js-v8.a | 17:34.27 |
| | rather than libmupdf.a and libmupdf-v8.a | 17:34.40 |
| | so if we add further js implementations, switching between them should be easier | 17:35.11 |
| | -Iinclude -Iscripts -Igenerated should be enough for all the -I directives (excepting thirdparty) | 17:36.19 |
| Robin_Watts | did you really use 'Resources' rather than 'resources' ? | 17:36.29 |
| | or is that just windows being crap ? | 17:36.34 |
| tor8 | nope, all lowercase for me | 17:36.39 |
| Robin_Watts | Fonts and Images ? | 17:36.50 |
| tor8 | all file names except README and COPYING and CHANGES (and the mixed case ones in android) are lowercase | 17:37.48 |
| | for lack of a better name, the pdfapp stuff ended up in platform/x11 | 17:39.10 |
| Robin_Watts | resources/fonts/ has CamelCase names, right? | 17:39.54 |
| tor8 | yeah, the individual font and cmaps have camelcase names | 17:40.10 |
| Robin_Watts | tor8: You've not updated generate.bat, right? | 17:48.20 |
| | ok, I've done it. | 17:50.54 |
| | tor8: 2>d:\cvs\artifex\mupdf.git\source\fitz\ucdn.c(94) : warning C4018: '<' : signed/unsigned mismatch | 17:55.45 |
| | 2>d:\cvs\artifex\mupdf.git\source\fitz\ucdn.c(96) : warning C4018: '<=' : signed/unsigned mismatch | 17:55.47 |
| | Those aren't new, but... | 17:55.53 |
| | Where has crypt_pkcs7.c gone ? | 18:06.43 |
| | Into pdf. | 18:09.05 |
| | Slightly odd that for windows I build source files from platform/x11 | 18:12.14 |
| | platform/shared ? | 18:12.28 |
| | tor8, paulgardiner: Currently the win32 project file only includes the pkcs7 stuff in the tools that need it, not in the mupdf lib itself. Is there a reason for that ? Would it not be neater to have it in the mupdf lib? | 18:14.39 |
| | tor8: win32 fixes on robin/shuffle | 18:22.37 |
| | actually, I think I broke the openssl stuff. will fix it. | 18:23.49 |
| | after I mow the lawn :( | 18:24.34 |
| mvrhel_laptop | tor8: are you there? | 18:27.17 |
| | do you have a good version of the mupdf logo with transparent background? | 18:27.50 |
| | or Robin_Watts | 18:28.19 |
| | or is the vector file around someplace for the logo | 18:28.38 |
| | henrys: do you know where I can get a vector version of the logo? | 18:31.37 |
| marcosw | Robin_Watts: ping | 18:35.45 |
| mvrhel_laptop | i think he is mowing the lawn | 18:38.16 |
| | maybe everyone is | 18:38.25 |
| henrys | no I don't I'll ask Miles for you if you like. | 18:43.40 |
| | mvrhel_laptop: ^^^ | 18:43.58 |
| mvrhel_laptop | henrys: oh. I can ask him | 18:44.16 |
| henrys | alright | 18:44.29 |
| marcosw | henrys: I re-ran the mupdf/fuzzing tests and found 3 segfaults in the current build, all in jbig/j2k decoders. I've assigned them to you. | 18:47.59 |
| henrys | marcosw:something for zeniko to work on he didn't get enough problems last time because they were all in ghostscript. | 18:49.04 |
| tor8 | mvrhel_laptop: http://ghostscript.com/~tor/mupdf-logo/ | 18:55.33 |
| mvrhel_laptop | awesome. thanks tor8 | 18:55.47 |
| tor8 | mvrhel_laptop: if you're looking for an app icon there's a 512x512 version in the 'ios' directory | 18:55.58 |
| mvrhel_laptop | tor8: oh ok. that might work too. I need something that I can put on a transparent background and get proper aliasing | 18:56.35 |
| | with the background | 18:56.43 |
| tor8 | mvrhel_laptop: the simplified-logo.xcf has high res bitmaps in layers you can use gimp to make it transparent | 18:57.09 |
| mvrhel_laptop | ok | 18:57.21 |
| tor8 | it's the one I used for the app icons | 18:57.24 |
| mvrhel_laptop | thanks | 18:57.28 |
| | I am passing the windows certification tests now, after fixing a bunch of stuff. now trying to make things look pretty | 18:57.55 |
| tor8 | mvrhel_laptop: http://git.ghostscript.com/?p=mupdf.git;a=blob;f=ios/iTunesArtwork.png;h=45aec0b78c35ad190c53476268b956076e59baa7;hb=HEAD | 18:58.22 |
| marcosw | henrys: I saw that the other jbig2/j2k issues had all been assigned to you, so did the same for the new ones as well. | 18:59.03 |
| tor8 | that's the app icon we use for both ios and android | 18:59.07 |
| mvrhel_laptop | ok. I will do the same | 18:59.14 |
| tor8 | mvrhel_laptop: I really ought to get a win8 device to test your app | 18:59.27 |
| mvrhel_laptop | although, I will make the gray transparent | 18:59.40 |
| | as this will be similar to what the apps icons are like in win8 | 18:59.54 |
| tor8 | yeah, that probably fits the win8 theme better | 19:00.02 |
| henrys | marcosw:yes that's fine. I'll change the who_owns_what document soon | 19:00.03 |
| tor8 | how will the black outline work on the background though? | 19:00.11 |
| | is the app backdrop colored? | 19:00.21 |
| mvrhel_laptop | yes. it is a darker gray | 19:00.28 |
| tor8 | okay, that ought to work. as long as it's not black-on-black :) | 19:00.42 |
| mvrhel_laptop | and it will have MuPDF in white letters at the bottom | 19:00.47 |
| | no it should be ok | 19:00.52 |
| | tor8: you can install win8 with vmware i think on your machine | 19:01.33 |
| tor8 | mvrhel_laptop: I'd still need a proper license though? | 19:02.14 |
| mvrhel_laptop | well, yes | 19:02.19 |
| | its not freeware | 19:02.34 |
| | :) | 19:02.38 |
| tor8 | miles will pay for that though, I don't doubt :) | 19:02.39 |
| | (proper, as opposed to upgrade) | 19:03.01 |
| mvrhel_laptop | yes, miles will gladly pay for it | 19:03.03 |
| Robin_Watts | mvrhel_laptop: back. | 19:04.42 |
| | marcosw: pong | 19:04.47 |
| mvrhel_laptop | Robin_Watts: tor8 took care of me | 19:04.58 |
| Robin_Watts | mvrhel_laptop: ok. I have a vector version of the MuPDF logo here that I knocked up. | 19:06.03 |
| | It's not perfect, but it's close. | 19:06.09 |
| mvrhel_laptop | oh really. well let me have that one too | 19:06.35 |
| tor8 | Robin_Watts: you saw the link to the original logo SVG? | 19:06.37 |
| mvrhel_laptop | please | 19:06.37 |
| Robin_Watts | tor8: I have win8 running under VMware player. I bought a copy for 65-70 quid. | 19:06.44 |
| tor8 | or is that the one you based it off | 19:06.48 |
| Robin_Watts | tor8: I did not. I did mine before I knew about the 512x512 one | 19:07.16 |
| tor8 | Robin_Watts: the xcf is even bigger than the 512x512 | 19:07.27 |
| | non-antialiased render of the svg cropped to the app icon viewport | 19:07.48 |
| Robin_Watts | tor8: Where is the svg one ? | 19:07.54 |
| tor8 | http://ghostscript.com/~tor/mupdf-logo/ has both svg and high-res xcf | 19:08.12 |
| | the logo does weird stuff with the white areas, so it's not usable as is on a transparent background | 19:08.33 |
| Robin_Watts | What's xcf ? | 19:08.38 |
| tor8 | gimp's format | 19:08.42 |
| Robin_Watts | Ah. | 19:08.51 |
| tor8 | layered bitmaps | 19:08.58 |
| Robin_Watts | I could tweak my one (done in xara) to match. | 19:09.16 |
| mvrhel_laptop | ah. the svg one is working out nicely | 19:12.45 |
| | oops. the white reflections in the handle are transparent though | 19:13.52 |
| | tor8: those really should be white yes? | 19:14.00 |
| Robin_Watts | they should | 19:14.16 |
| tor8 | mvrhel_laptop: yeah, that's what I meant earlier when I said the svg has funky white area | 19:14.22 |
| | s | 19:14.23 |
| mvrhel_laptop | ok | 19:14.41 |
| tor8 | the xcf should be high res enough for anything you need | 19:14.53 |
| | if you want I can make it a png? | 19:15.14 |
| Robin_Watts | tor8: OK. robin/shuffle done now, I think. | 19:15.32 |
| mvrhel_laptop | that would be easier for me. I dont have gimp installed. | 19:15.37 |
| tor8 | mvrhel_laptop: give me a few minutes | 19:16.08 |
| | mvrhel_laptop: http://ghostscript.com/~tor/mupdf-logo/mupdf-simplified-logo.png | 19:20.47 |
| mvrhel_laptop | tor8: ok great. thanks | 19:21.05 |
| | that will do the job | 19:22.12 |
| Robin_Watts | mvrhel_laptop: Do you want it as an icon? | 19:22.31 |
| | i.e on a background rectangle? | 19:22.40 |
| mvrhel_laptop | Robin_Watts: the icons in win8 in the tiles have transparent backgrounds. this is what I wanted | 19:23.14 |
| | they are placed over a gray backdrop | 19:23.24 |
| | in the tiles | 19:23.35 |
| Robin_Watts | OK. For Android I needed: http://ghostscript.com/~robin/muPDFlogo.png | 19:24.31 |
| mvrhel_laptop | not here . that would look odd in win8 | 19:24.54 |
| Robin_Watts | well, I've updated my .xar so I can produce others easily if required. | 19:25.38 |
| mvrhel_laptop | ok. logos all updated and look good. testing certification on the arm device now to make sure that is fine too | 19:56.32 |
| | need to eat lunch | 19:57.21 |
| | bbiab | 19:57.23 |
| | Robin_Watts: ok. I have pushed my updates that I needed before doing a store submission if you want to review | 20:11.39 |
| ray_laptop | mvrhel_laptop: I think that most of what is needed to do the color/monochrome detection for MultipleDataSources in the clist is there. Just a little refactoring and corrections. | 20:27.52 |
| mvrhel_laptop | ray_laptop: ok that is good | 20:28.16 |
| | Robin_Watts: http://msdn.microsoft.com/en-us/library/windows/apps/hh694069.aspx | 20:28.53 |
| ray_laptop | mvrhel_laptop: when trying to explain to the customer why we needed extra buffers and what would be needed, I stepped into the code and found out that buffers were already being allocated | 20:29.02 |
| mvrhel_laptop | do we have a current ECCN number | 20:29.17 |
| | ray_laptop: ah that is good | 20:29.28 |
| ray_laptop | mvrhel_laptop: and the 'row_has_color' can handle separated planes if the 'spread' is calculated correctly (and the unpack done outside this function where we have access to the 'planes') | 20:31.20 |
| mvrhel_laptop | bbiaw | 20:47.15 |
| Robin_Watts | mvrhel_laptop: My reading of that would be that we do NOT need an ECCN. | 23:13.36 |
| mvrhel_laptop | oh ok | 23:13.49 |
| Robin_Watts | because all our use of encryption is for the list of tasks there. | 23:13.58 |
| mvrhel_laptop | yes. I see now | 23:14.38 |
| | e.g. Authentication | 23:14.45 |
| | digital signatures etc | 23:14.52 |
| | I should have read that more carefully | 23:15.01 |
| | sorry to have bothered you with it | 23:15.07 |
| Robin_Watts | no worrie.s | 23:17.00 |
| tor8 | Robin_Watts: we do decryption of encrypted file contents though... | 23:17.21 |
| Robin_Watts | That's password encryption in my book. | 23:17.42 |
| | and/or authentication/drm. | 23:18.16 |
| tor8 | right. drm would cover it, I guess. | 23:20.54 |
| Robin_Watts | mvrhel_laptop: That commit looks OK to me. Want me to push it ? | 23:22.18 |
| mvrhel_laptop | Robin_Watts: let me add one little thing to it | 23:22.29 |
| Robin_Watts | mvrhel_laptop: A newline to the end of status.h ? :) | 23:22.43 |
| | and mupdfwinrt.vcxproj.filters ? | 23:23.00 |
| mvrhel_laptop | I can do that too, plus I need to remove image_md5.c from the project | 23:23.04 |
| Robin_Watts | and Package.appmanifest ? | 23:23.25 |
| mvrhel_laptop | Robin_Watts: so those files are generated automatically. you want me to go in and edit them with a new line at the end? | 23:23.56 |
| Robin_Watts | in that case, no. | 23:24.05 |
| | had they been manually edited we could have stopped git whinging, but not if they are autogenerated :) | 23:24.37 |
| mvrhel_laptop | well, they are generated based upon a gui like file that I edit | 23:26.23 |
| | at least in the case of Package.appmanifest | 23:26.31 |
| | mupdfwinrt.vcxproj.filters is a split off from the old vcproj file in older visual studio | 23:27.04 |
| | and is generated based upon what you have in the solution | 23:27.19 |
| | and the project in the solution that is | 23:27.30 |
| | Robin_Watts: ok I pushed the appended one | 23:27.50 |
| | did the win32 project get updated from the removal of image_md5.c | 23:28.24 |
| | I did not see it in the commits | 23:28.28 |
| Robin_Watts | Possibly not. | 23:29.20 |
| mvrhel_laptop | Robin_Watts: so I heard back from my friend at MS | 23:29.42 |
| | he said we need to do this | 23:29.49 |
| | http://msdn.microsoft.com/en-us/library/windowsphone/help/jj215905(v=vs.105).aspx | 23:29.51 |
| | about the PDF Reader app | 23:29.54 |
| Robin_Watts | but I've just completely rebuilt it for the shuffle branch, so hopefully that'll get pushed soon, and everything will need to change again :) | 23:29.56 |
| mvrhel_laptop | item 1 | 23:30.16 |
| Robin_Watts | right. | 23:30.22 |
| mvrhel_laptop | henrys: who do we want to take care of that? | 23:30.46 |
| Robin_Watts | IMHO, we should send them a direct message stating that we believe they use MuPDF, and saying that if we don't hear back from them, we will be considering what legal action to take. | 23:31.26 |
| mvrhel_laptop | right | 23:31.37 |
| Robin_Watts | Then if we don't get a response, we do the takedown thing. | 23:31.42 |
| | cos if they fail to respond to that, they won't respond to anything. | 23:32.04 |
| mvrhel_laptop | I had not gotten a response from them asking for the code (since it is supposedly GPL) | 23:32.29 |
| | I will pass this along to Miles so that he is aware of it and push on | 23:32.59 |
| Robin_Watts | Miles is in surgery today. | 23:33.07 |
| | So I suspect he may not be operating at full speed for a few days. | 23:33.27 |
| | mvrhel: pushed to golden. | 23:34.38 |
| mvrhel_laptop | Robin_Watts: Thanks | 23:34.46 |
| | oh his shoulder | 23:34.55 |
| Robin_Watts | mvrhel_laptop: yeah. | 23:36.31 |
| | mvrhel_laptop: I'm working on making mupdf support progressive display of files as they download. | 23:36.50 |
| mvrhel_laptop | nice | 23:36.57 |
| Robin_Watts | Is there a mechanism for working on a file as it is downloaded under winrt ? | 23:37.15 |
| | or would we need to write our own http fetcher for that as part of the app? | 23:37.41 |
| | The current plan is that you'll wrap the downloading thing into a slightly modified fz_stream. | 23:38.28 |
| | When you try to open it, mupdf will try to read from the file. If it reads off the end of the current stream, the stream code throws an error of a particular type. | 23:39.18 |
| | That bubbles up and returns to the app. | 23:39.34 |
| | The app can then check the type of the error it gets, and knows to retry when more data has arrived. | 23:39.52 |
| | How utterly alien does that sound? :) | 23:40.51 |
| | alien enough that it's scared mvhrel off, it seems :) | 23:52.03 |
| | Bedtime for me. I'll read logs in the mornings in case you (or anyone else) has any thoughts. | 23:52.22 |
| | Forward 1 day (to 2013/06/20)>>> | |
IRC Logs
