| | <<<Back 1 day (to 2013/06/10) | 2013/06/11 |
| kens | Its obviously been down for a while, I notice some stuff form yesterday is not in the logsd | 07:53.13 |
| chrisl | It's annoying that the process is usually still running, so a simple cron job to check for the process won't work :-( | 07:54.11 |
| kens | THat is annoying yes. | 07:54.23 |
| chrisl | Maybe we should just reset it every 12 hours, regardless | 07:55.41 |
| kens | That's not a bad idea, I only noticed it wasn't working because the logs for the last 2 days were empty | 07:56.09 |
| chrisl | I'll give it some thought, there may be some other way to spot when it's not functioning | 07:57.03 |
| vtorri | Robin_Watts, so to do to catch the error ? I want to exit my function in that case | 08:01.18 |
| | so what* | 08:09.41 |
| Robin_Watts | vtorri: It's possible the code didn't think there was an error. | 08:55.50 |
| | vtorri: cAn we see the file in question? | 09:05.23 |
| tor8 | Robin_Watts: the nvidia path extension does all its rasterization using the stencil buffer | 09:09.08 |
| | then it draws triangles that cover the bbox of the path, and use the stencil buffer to mask | 09:09.33 |
| | so no AA | 09:09.39 |
| Robin_Watts | tor8: but supersampling, right? | 09:09.59 |
| tor8 | yes, multisampling should work IIRC | 09:11.55 |
| | the depth, stencil and color buffers are all supersized | 09:12.09 |
| | but the fragment shader only runs once per pixel, irregardless of how many samples there are per pixel | 09:12.32 |
| Robin_Watts | tor8: I could be wrong on this ,but I assumed that the stencil buffer was an 8 bit thing, with 'coverage' measurements, effectively. | 09:13.50 |
| tor8 | no, it can be any number of bits (8 being most common) | 09:14.10 |
| | but each bit plane can be tested separately | 09:14.21 |
| Robin_Watts | Right, so we use the 8 bit thing, and treat it as coverage. | 09:14.33 |
| tor8 | the rendering extension uses the bits to count winding | 09:14.33 |
| | so there's a max limit to how many overlaps a non-zerowinding filled path can have depending on the stencil buffer depth | 09:15.41 |
| | the stencil buffer can also be used to clip the paths with another path, recursively up to some limit | 09:19.40 |
| | Robin_Watts: worse news; it depends on compatibility profile for parts of the fixed function pipeline to do the glPathCover step :( | 09:24.33 |
| | but I think the approach of using the stencil buffer to do path rendering can be re-implemented trivially | 09:25.03 |
| Robin_Watts | tor8: What's "compatibility profile" ? | 09:28.13 |
| tor8 | an opengl context can have different profiles when you create it | 09:28.45 |
| | to target specific versions of opengl | 09:28.54 |
| | usually either a forward compatible core profile context (which only does opengl 3.0, no fixed function allowed) | 09:30.02 |
| | or compatibililty profile, which supports all the garbage from the 80's and onward | 09:30.19 |
| | GLES 1.1 is based on fixed function (no shaders allowed) | 09:30.48 |
| | GLES 2.0 is based on shaders (no fixed function allowed) | 09:30.59 |
| | so it only applies to desktop opengl | 09:31.05 |
| Robin_Watts | tor8: OK, so I understand what a compatability profile is. | 10:05.07 |
| | Which type does the nvidia code require? forward or backwards? | 10:05.25 |
| tor8 | it needs the backward compatible profile for fixed function features | 10:17.16 |
| | like setting the colors and transform | 10:17.23 |
| | stuff which is in a 3.0 / gles2 handled by the shaders | 10:17.39 |
| Robin_Watts | tor8: Can we do the stencil step using their extension, and then just do the cover step using our own (non compatibility profile using) code ? | 10:23.53 |
| tor8 | Robin_Watts:I don't think so, looking at it the stencil step also uses fixed function stuff for the path transform | 10:24.30 |
| | so if we use their extension, we'll have to use backwards compatible opengl on the desktop only | 10:24.57 |
| | I think it'd probably be better to reimplement their algorithm outside of the driver | 10:25.13 |
| Robin_Watts | urgh. | 10:25.29 |
| tor8 | it should be fairly simple to do what they do, but with triangles and rendering to the stencil buffer manually. | 10:25.39 |
| Robin_Watts | tor8: If you're interested, I have the email address of a couple of people at NVidia that I spoke to at AnDevCon. | 10:26.20 |
| | They said they could put me in touch with the papers author. | 10:26.33 |
| | We might be able to get a non-compatability requiring version from him? Or at least a copy of some code to avoid having to reimplement everything. | 10:27.38 |
| tor8 | a copy of some code to make it work on GLES2 would be useful | 10:28.23 |
| | but it's probably tied into their super secret proprietary driver | 10:28.37 |
| tor8 | lunches. | 10:28.59 |
| Robin_Watts | Hmm. I have a business card here. Usual name, title, address, email, web etc. Then I have "T <phone number>" (fair enough) | 10:37.19 |
| | Then I have "C <what looks like a phone number>" | 10:37.29 |
| | C ? What's C mean ? | 10:37.33 |
| kens | Clacks ? | 10:41.19 |
| Robin_Watts | Unlikely. Clacks is "Anthill Inside", right? :) | 10:44.52 |
| kens | Yep :-) | 10:44.59 |
| Robin_Watts | tor8: Introduction mail sent. | 10:55.10 |
| paulgardiner | Morning... just about | 10:57.23 |
| Robin_Watts | Morning | 10:57.40 |
| sebras | vtorri: some PDF files with errors in they mupdf can handle. e.g. the PDF spec mentions that the PDF version-marker at the beginning of the PDF might be anywhere within the first 1KB of file contents IIRC. | 11:51.38 |
| sebras | doesn't have pdfref at hand, so this is from memory. | 11:52.03 |
| Robin_Watts | kens: I suspect bug 691729 may need to come to me when it's reopened. | 11:57.38 |
| kens | Yes I think so RObin, I just wanted to test it first, but before the files were there I couldn't | 11:58.05 |
| | IAs you can probably tell I've been grabbing/reassigning some of Alex's bugs (and closing a few) | 11:58.40 |
| Robin_Watts | kens: yeah, seems sensible. | 11:58.53 |
| kens | I did find at least one case which works with current code, so testing seems important ;-) | 11:59.13 |
| henrys | kens:I take it you want to go through Alex list first. | 12:43.02 |
| kens | henrys I didn't feel up to do anythign complicated today so I thought I would take a quick look. Many can be reassigned to me very easily (all those relating to pdfwrite ;-) | 12:43.51 |
| | It was easy enough to do some others at teh same time, so I did. | 12:44.25 |
| henrys | kens:fine by me. | 12:46.12 |
| | kens:please refer javascript/forms folks to mupdf. | 12:51.04 |
| kens | Good point, yes I'll do that. | 12:51.16 |
| henrys | probably have some down time over the next hour or so cable company is replacing my modem (end of life for the current model). | 12:55.39 |
| kens | Oh what fun :-( | 12:55.52 |
| henrys | so the only interesting thing I've seen at WWDC from apple is a trash can, http://www.anandtech.com/Gallery/Album/2859#4 is the next generation of mac pro. Looks like it is not built for expandability | 13:00.21 |
| kens | Well, not internal expandability | 13:00.40 |
| henrys | I guess the new MacBooks announcement will be today | 13:01.06 |
| | impressive that it is 1/8 the size of the current Mac Pro and about 2x faster. | 13:05.45 |
| kens | Robin_Watts : ping | 13:32.46 |
| | Robin_Watts : ping | 13:51.39 |
| sebras | Robin_Watts: Cellphone number? | 13:53.28 |
| | Robin_Watts: there are still wired devices you know... | 13:53.39 |
| Robin_Watts | Cellphone! | 13:59.01 |
| | Normally, I expect M for Mobile. | 13:59.14 |
| | kens: pong | 14:00.34 |
| tor8 | henrys: less impressive when you consider how absurdly out of date the current macpro is... | 14:10.54 |
| | and ios7 apparently looks like windows 8... | 14:11.19 |
| | and they're moving to a "auto layout" scheme with constraints rather than everything being pixel based fixed layouts! that's a first for apple. | 14:11.45 |
| Robin_Watts | kens: pong | 14:16.42 |
| | tor8: Ah. Are they adopting Athena widgets then? | 14:16.55 |
| kens | Robin_Watts : how hard would it be to write a tiffscaled32 that does CMYK ? | 14:16.59 |
| Robin_Watts | kens: Urm... use a planar device, and the downscaler will work on that already. | 14:18.03 |
| kens | The user is already using tiff32nc | 14:18.24 |
| | So presumably they want TIFF output | 14:18.43 |
| Robin_Watts | kens: The answer is that it's just a cut/paste job. | 14:19.25 |
| kens | OK thanks robin | 14:20.19 |
| Robin_Watts | kens: And whether we use a planar device or not internally, doesn't affect whether they get tiff out at the end. | 14:20.32 |
| | All the tiff devices that cope with spot colors are planar internally. | 14:20.48 |
| | oh. tiff32nc does MinFeatureSize stuff. | 14:21.41 |
| | I guess we do that in the downscaler too though, so it's probably still Ok. | 14:22.00 |
| kens | I was just wondering if its worth making a tiffscaled32 device, to macth the regular tiff array | 14:30.35 |
| | bug 691729 works 'as expected' with tiffscaled devices, but not with -dGraphicsAlphaBits | 14:31.18 |
| Robin_Watts | OK, I'll do that. | 14:32.05 |
| | I can probably do that in a bit. | 14:32.16 |
| | tor8: ping! | 14:33.17 |
| tor8 | Robin_Watts: yes? | 14:39.43 |
| Robin_Watts | I'm looking at zenikos comments on bug 694303 | 14:40.12 |
| | Can I check stuff with you? | 14:40.19 |
| | In pdf/pdf_repair.c | 14:40.23 |
| | In pdf_repair_obj | 14:40.33 |
| | we read a token in. (which will hopefully be a dictionary object) | 14:41.01 |
| | If it is a dictionary object ,we then parse it. | 14:41.23 |
| | Then (unless we've hit 'stream' or 'endobj' or error or eof or an int) we try to read another object. | 14:42.34 |
| | Normally that should be 'endobj', right? | 14:43.08 |
| | or 'stream' | 14:43.26 |
| kens | Robin_Watts : thanks, I'll put that in the bug thread | 14:43.27 |
| Robin_Watts | kens: feel free to assign me the bug with a note saying "robin will code tiffscaled32" | 14:43.50 |
| kens | OK I'll do that thanks | 14:43.57 |
| tor8 | Robin_Watts: yes. so, the check for naked dictionaries (if we see a << outside of the X Y obj ... endobj context) is to find encryption dictionaries and the trailers | 14:44.49 |
| paulgardiner | Robin_Watts, tor8: Did we decide that my fz_interactive-removal commit (the version on Robin_Watts' repo) was good to go? | 14:44.52 |
| Robin_Watts | tor8: Right. The problem that zeniko is showing up is that he's constructed a file where 'endobj' is missing. | 14:45.31 |
| | So the next thing read is the integer that starts the next object. | 14:45.48 |
| tor8 | shouldn't that end up in the atobjend: case? oh wait, that's only for streams | 14:46.26 |
| Robin_Watts | So we go into the if (tok == PDF_TOK_INT) thing and we 'unread' the bytes to try to backtrack over the integer. | 14:46.27 |
| tor8 | Robin_Watts: right. I think I see what we're doing. I'm being forgetful. | 14:47.11 |
| | it's a premature optimization | 14:47.20 |
| | we only parse dictionaries as complete objects, because we can ignore everything else | 14:47.33 |
| | if we run the normal object parser, we should be able to catch it | 14:47.47 |
| | just read one "object" as in the array parsing code | 14:47.54 |
| Robin_Watts | You've lost me. | 14:48.12 |
| | The problem that I can see here is that we no longer set 'buf->len' as part of the number parsing code. | 14:48.53 |
| | hence the backtracking we do is for the wrong number of chars. | 14:49.07 |
| tor8 | when we see the 'obj' keyword, we call pdf_repair_obj which is supposed to parse one full object | 14:49.08 |
| Robin_Watts | tor8: Right. | 14:49.16 |
| tor8 | we try to be smart and only parse dictionaries completely | 14:49.22 |
| Robin_Watts | and that makes sense, I think. | 14:49.32 |
| tor8 | if we parsed properly, we'd parse one object, see that the next token isn't a stream or endobj and could just continue at the top level and not have read too much | 14:49.56 |
| | more reliably than we do now | 14:50.05 |
| Robin_Watts | tor8: I think we can fix this as is. | 14:50.33 |
| tor8 | we could make it return the last token it parsed to the top level | 14:50.37 |
| | anyway, I'm needed elsewhere so I'm afraid I have to go away again | 14:50.51 |
| | I'll check in later tonight. the repair code isn't very well thought through so feel free to rip it apat. | 14:51.19 |
| | apart* | 14:51.23 |
| Robin_Watts | Ok. I shall code up a fix. Yell when you get back. | 14:51.23 |
| tor8 | will do. | 14:51.43 |
| henrys | tor8:I'm thinking about a switch back to linux | 14:51.53 |
| | oops missed him | 14:52.11 |
| Robin_Watts | henrys: burning your polonecks? | 14:53.44 |
| henrys | slowly I see expandability slipping away. I have had many machines that I would have tossed if I couldn't speed them up with and upgrades ssd, graphics etc. Apple wants to see you a toaster that lasts 3 years and you buy another, appealing to them not to me. | 15:04.30 |
| | s/see/sell | 15:04.42 |
| Robin_Watts | henrys: Right. Apple has driven the "computer as unexpandable consumer good" thing for years. | 15:06.13 |
| vtorri | Robin_Watts, how do i send it ? mail ? | 15:29.33 |
| Robin_Watts | mail is fine. or put it online and paste the link. | 15:29.50 |
| vtorri | i'm not sure that the paste site will hold it completely | 15:30.36 |
| Robin_Watts | henrys: I've always built my own PCs with an eye on expandability, but increasingly, it becomes hard to change too much without building a whole new machine. | 15:31.19 |
| | motherboard/CPU/RAM are pretty much tied together these days. | 15:31.36 |
| | but being limited in adding HDs/PSUs/Graphics cards is something I would find very hard to swallow. | 15:32.08 |
| vtorri | Robin_Watts, http://www.speedyshare.com/sqkcS/sample.ps | 15:32.10 |
| Robin_Watts | vtorri: Got it. Let me finish what I'm doing now - mupdf is in pieces - then I'll look. | 15:34.03 |
| vtorri | thank you | 15:34.17 |
| Robin_Watts | vtorri: OK, so when we try to open that file, we spot that it's not a well formed PDF file. | 16:04.45 |
| | so we try to 'repair' it. | 16:04.51 |
| vtorri | postscript and pdf are closed file format ? (at least for the header) | 16:05.36 |
| chrisl | vtorri: no, PS and PDF file formats are nothing alike | 16:06.08 |
| vtorri | so the mupdf behavior is quite strange | 16:06.27 |
| ray_laptop | vtorri: If I understand what you mean by 'closed', then PS is NOT closed | 16:06.28 |
| vtorri | not 'clsoed' as 'closed source' | 16:06.49 |
| ray_laptop | PS is actually a programming language | 16:06.50 |
| vtorri | i know what PS is :) | 16:07.00 |
| ray_laptop | vtorri: OK. | 16:07.06 |
| chrisl | vtorri: why is mupdf's behaviour strange? | 16:07.14 |
| vtorri | close as 'similar' | 16:07.20 |
| Robin_Watts | With careful programming you can set PS up so that a PDF file is a valid PS program. | 16:07.33 |
| vtorri | chrisl, i can't detect that it is not a PDF file | 16:07.45 |
| | at least I don't know how to do that with the mupdf API | 16:08.13 |
| | Robin_Watts told me that my code seems good | 16:08.33 |
| Robin_Watts | vtorri: As soon as you try to load the first page, it will complain to you. | 16:08.42 |
| vtorri | ho | 16:08.51 |
| | ok | 16:08.56 |
| | so i have to also call fz_load_page(doc,0) ? | 16:09.38 |
| chrisl | vtorri: mupdf will assume you're passing it a file it can understand, and will try to interpret it as such - seems reasonable to me | 16:09.50 |
| vtorri | i don't know what mupdf does, so... My first guess was : fz_open_document would return NULL or throw an exception if the document was not a PDF file | 16:11.13 |
| | but i was wrong | 16:11.20 |
| Robin_Watts | We *could* make mupdf bale out if it fails to find a header in the first 1024 bytes. | 16:11.24 |
| | but then we risk giving up on files which we could repair perfectly well. | 16:11.46 |
| vtorri | understandable | 16:12.28 |
| Robin_Watts | Possibly we could update the code so that in cases where we've repaired, we try to check that there is a first page to load? | 16:12.52 |
| vtorri | so i have to also call fz_load_page(doc,0) in the same 'try' block than fz_open_document() ? | 16:12.54 |
| Robin_Watts | but then that might make us bale on cases where only the first page of a document is damaged. | 16:13.08 |
| | vtorri: That would be one solution, yes. | 16:13.41 |
| vtorri | ok | 16:13.51 |
| | and is it possible to redirect the messages that mupdf writes in the terminal ? | 16:14.11 |
| Robin_Watts | vtorri: We write error messages to stderr. | 16:14.59 |
| | You can do what you want with stderr. | 16:15.08 |
| vtorri | hmm | 16:15.26 |
| | ok, thanks | 16:15.28 |
| kens | In the absence of a meeting this week, I'd like to talk about bug #687796, especially with henrys | 16:16.36 |
| henrys | okay I'll be ready in 5 or so minutes | 16:17.04 |
| kens | OK let me know | 16:17.15 |
| Robin_Watts | kens: I think you're right. | 16:17.18 |
| kens | :-) | 16:17.25 |
| Robin_Watts | I reckon we should take on all Sags patches, pay the bounty, then think about deleting the file entirely. | 16:17.51 |
| chrisl | <sigh> that means I'll have to try to remember how to use mupdf...... | 16:18.05 |
| kens | I'm inclined that way as well | 16:18.09 |
| | I always use MuPDF for decompressing PDF files, its faster and works better (IMO) | 16:18.30 |
| | Trying to actually adopt all of SaGS patches might be difficult, as I think some things have changed | 16:19.04 |
| chrisl | Yeh, it's just another tool - I do feel that maintaining a solution in C rather than PS is the right way | 16:19.09 |
| Robin_Watts | chrisl: I copy "mutool" to be "pdfclean". That way I can call "pdfclean -difggg in.pdf out.pdf" rather than doing "mutool clean ...." | 16:21.08 |
| chrisl | Robin_Watts: yes, I just mean I've to remember the command line params etc | 16:21.47 |
| Robin_Watts | -d for decompress is the only really important one. | 16:22.04 |
| kens | Its about the only one I remeber (because I use it a lot of course) | 16:22.27 |
| Robin_Watts | Unless you want images and fonts decompressed you can add i and f too. | 16:23.02 |
| | and the g's are for garbage collection. | 16:23.16 |
| kens | I usually do want those decompressed :-) | 16:23.18 |
| Robin_Watts | kens: yeah, but you're odd :) | 16:23.28 |
| kens | cannot argue that one | 16:23.41 |
| chrisl | Well, I generally want fonts decompressed, too | 16:23.47 |
| Robin_Watts | assert(setOfOddPeople.includes("chrisl") == true); | 16:24.54 |
| kens | One suspects Artifex engineers are a subset of the set of odd people | 16:25.20 |
| chrisl | :-) also can't argue with that - although I think it's fairly logical that debugging fonts is easier when the data is uncompressed...... | 16:25.50 |
| henrys | kens:I'd rather point folks to mupdf also | 16:28.10 |
| | and the bounty is fine | 16:29.21 |
| kens | OK henrys, then I'll close the bug and suggest to SaGS he claim the bounty | 16:30.32 |
| vtorri | Robin_Watts, would it be possible to consider sending messages to something else than stderr ? | 16:32.15 |
| | Robin_Watts, like storing them for example | 16:32.25 |
| | then it's up to the user to do whatever he wants with them | 16:32.40 |
| | or adding a callback which sends by default the message to stderr | 16:33.17 |
| Robin_Watts | vtorri: We could probably add something in the context, yes | 16:37.16 |
| vtorri | Robin_Watts, we do that in our log library | 16:37.39 |
| | a user defned callback which by default sends messages to stderr | 16:38.02 |
| | defined* | 16:38.07 |
| kens | OK I'm off, night all | 16:54.32 |
| henrys | chrisl, marcosw: maybe russel can set put his stuff on casper and one of you propagate it to the download area? | 17:08.19 |
| | does that make sense. | 17:08.41 |
| | ? | 17:08.49 |
| chrisl | henrys: that would be an option - do we expect much bandwidth from it? | 17:08.56 |
| henrys | I have no idea but it could be high and that's why we got the new download site | 17:09.38 |
| | chrisl:let me know if you want me to contact him. | 17:10.04 |
| chrisl | henrys: okay, we can do that. If it gets to be a pain, we can probably create a cron job to check for updates, and do the uploads | 17:10.47 |
| | henrys: I'll see about pulling all the current stuff off wisc this week | 17:11.17 |
| henrys | presumably he can stage it in his public_html account make sure it looks okay then one of us will propagate it. | 17:11.22 |
| chrisl | Yeh, that's what I'd expect | 17:11.51 |
| marcosw_ | henry: we can do either that or give ghost gum permission to edit the whatever directory we set up for him to use in /var/www. | 17:12.48 |
| chrisl | marcosw_: this is for the actual downloads, rather than for the pages | 17:13.35 |
| marcosw_ | right, than henrys' suggestion is the correct solution. | 17:14.29 |
| chrisl | marcosw_: for the web pages we can either do as you suggest, or have something like the setup that the mupdf.com currently uses | 17:15.14 |
| marcosw_ | I believe mupdf.com is currently hosted out of tor's directory, but that's on my list of changes to fix (i.e. move it to /var/www) | 17:16.01 |
| chrisl | Exactly, we could point to files in Russell's user area - just an option | 17:16.45 |
| marcosw_ | henrys et.al.: I have a serious deadline for a paper submission later today, so I'm going to sign off irc to avoid being distracted. I'll try to check my email a couple of times during the day, but if something urgent comes up (i.e. the cluster catches fire) please text me. | 17:20.05 |
| henrys | okay | 17:20.21 |
| Robin_Watts | Anyone got a program capable of viewing cmyk tifs ? | 17:33.07 |
| | S'OK. Fixed. | 18:00.31 |
| | tor8: hey. | 20:24.13 |
| | proposed fix on robin/master | 20:24.18 |
| | Also, were you happy with pauls commit? | 20:24.28 |
| tor8 | *reading the irc logs* | 20:24.39 |
| | paul's commit was fine. there came in a bug report about strncpy being used in some of paul's code. | 20:25.15 |
| | we should be using fz_strlcpy (as strncpy does the wrong thing... strncpy is for filling out fixed size records, it always pads with zeroes to the length and doesn't necessarily zero terminate) | 20:26.01 |
| | Robin_Watts: ick. your solution is too hacky for my taste. | 20:35.19 |
| | why does the startxref == 0 cause a SEGV? | 20:36.21 |
| Robin_Watts | tor8: when we read the xrefs in, we do: | 20:36.44 |
| | while (startxref != 0) { read an xref and reset startxref to where the next one is } | 20:37.05 |
| | if we enter that code with startxref = 0, we never read any xref. | 20:37.14 |
| tor8 | ah! | 20:37.19 |
| Robin_Watts | the code that looks up objects assumes that we've always read at least one xref. | 20:37.27 |
| tor8 | that part of the patch looks good then | 20:37.40 |
| Robin_Watts | I didn't think my solution was hacky. | 20:37.42 |
| | When we're doing a repair, if we hit a number, we previously lexed it, only to have to jump through hoops to unlex it again. | 20:38.25 |
| | (hoops that would not really ever have been entirely reliable) | 20:38.36 |
| tor8 | the shortcut special behaviour flag to the lexer for one specific case | 20:38.37 |
| Robin_Watts | with my new code, we stop as soon as we encounter a number without parsing it. | 20:38.57 |
| | The lexer is already partly a combined lexer/parser for numbers. | 20:39.13 |
| tor8 | I'd prefer if we don't jump through hoops to be able to lex it twice, why can't we just return the previously lexed int in the calling code? | 20:39.15 |
| Robin_Watts | tor8: maybe we could. | 20:39.42 |
| | it would make pdf_repair_obj a nastier signature though. | 20:40.06 |
| tor8 | it doesn't even lex, the repair flag should be called peek_for_int_and_return_early | 20:40.13 |
| Robin_Watts | dinner time. I'll try reworking it a bit tomorrow. | 20:42.04 |
| vtorri | ok, fz_load_page gives an error | 20:53.16 |
| | (with the postscript file) | 20:53.24 |
| | is there a better way to check if the doc is a pdf or not ? | 20:53.42 |
| sebras | vtorri: not using mupdf. at least not right now. | 21:08.56 |
| vtorri | ok | 21:10.40 |
| | thanks | 21:10.45 |
| | tor8, what about adding a function that sets the callback for printing messages | 21:11.57 |
| | tor8, hence a user can choose whatever he wants to display messages | 21:12.15 |
| | tor8, by default, messages are printed to stderr | 21:12.26 |
| sebras | vtorri: doing so sounds reasonable to me. if you attach a patch in bugzilla we'll certainly take a look at it. | 21:13.10 |
| vtorri | sebras, ok, thanks | 21:13.23 |
| | i want that because we have our own log system and it would be nice to catch mupdf messages and display them with that log system | 21:14.14 |
| sebras | vtorri: some dependencies, like libopenjpeg, does this too. | 21:15.42 |
| vtorri | really ? | 21:15.54 |
| | in 2.0 then | 21:15.57 |
| | i can't remember something like that in 1.* | 21:16.14 |
| sebras | vtorri: has done so since 1.3 IIRC. | 21:16.30 |
| vtorri | damn | 21:16.38 |
| | in libopenjpeg ? | 21:16.47 |
| | or the apps ? | 21:16.51 |
| | sebras, here is our output with the log system | 21:18.06 |
| | http://www.maths.univ-evry.fr/pages_perso/vtorri/files/log.png | 21:18.08 |
| sebras | vtorri: see fz_opj_error_callback() in fitz/image_jpx.c | 21:18.18 |
| vtorri | ok | 21:18.59 |
| | indeed | 21:19.02 |
| | sebras, and you would want the same kind of system ? | 21:19.43 |
| sebras | vtorri: we already have a rate-limiting in e.g. fz_warn(). I'd assume we want to keep that and just replace the calls to fprintf() and fflush() in fitz/base_error.c with some function pointers stored in fz_error_context. | 21:22.50 |
| | vtorri: that's what I'd start with myself. | 21:23.16 |
| vtorri | and an enum to tell if it's a warning, an error or an info | 21:24.16 |
| | ? | 21:24.18 |
| sebras | vtorri: I think it would be easier for the receipient to have multiple callbacks (as libopenjpeg). | 21:25.08 |
| vtorri | ok | 21:25.41 |
| | i'll try to write something this week | 21:26.37 |
| | sebras, only error and warning ? | 21:26.55 |
| sebras | vtorri: and something replacing flush. | 21:28.43 |
| vtorri | ok | 21:28.53 |
| sebras | vtorri: if it makes sense. | 21:29.05 |
| vtorri | i'll begin with something simple | 21:29.23 |
| | i've never touched mupdf code | 21:29.30 |
| | Forward 1 day (to 2013/06/12)>>> | |
IRC Logs
