| | <<<Back 1 day (to 2016/01/17) | 20160118 |
| RobinWattsLenovo | My PC crashed. | 00:44.22 |
| | won't even boot. no image on VGA card. | 00:44.33 |
| | Will try it again in the morning, but I might be fixing that for a while. | 00:44.51 |
| marcosw | RobinWattsLenovo: you shouldn't be using your pc at 12:45 am, it needs to rest. | 01:34.53 |
| | in my experience not booting is usually the powersupply, I've had 3 or 4 of those die in the last year or so. | 01:35.24 |
| RobinWattsLenovo | Guest32558: For the logs: The other tools are all integrated into mutool now. | 08:42.00 |
| kens | How's your PC ths morning RobinWattsLenovo ? | 08:42.29 |
| | Not well I'm guessing | 08:42.34 |
| RobinWattsLenovo | kens: Power light comes on, fans spin, nothing else happens. | 08:42.55 |
| kens | Not good :( | 08:43.02 |
| RobinWattsLenovo | yeah. | 08:43.39 |
| | I've got to drop Helen into the station later. | 08:44.44 |
| | I may pop into Maplins and buy a new PSU to try that. | 08:44.55 |
| kens | You don't hve a spare PC you could cannibalise ? | 08:45.07 |
| | Just to check if its the PSU | 08:45.17 |
| RobinWattsLenovo | I have an old PC, but getting the PSU out is a pain in the bum. | 08:45.36 |
| kens | Yeah I've done it before | 08:45.43 |
| RobinWattsLenovo | massive CPU cooler in the way. | 08:45.47 |
| kens | OH that makes it even harder | 08:45.55 |
| RobinWattsLenovo | New PC has the PSU at the bottom. MUCH easier to change. | 08:52.12 |
| kens | better for balance too I'd have thought | 08:52.41 |
| RobinWattsLenovo | New PSU ordered for collection. | 08:53.08 |
| kens | well its certainly worth trying | 08:53.23 |
| RobinWattsLenovo | Things to try: PSU. Graphics card. Strip out TV capture card. | 08:55.23 |
| | I can more easily get the graphics card out of the last machine than the PSU. | 08:55.53 |
| kens | No onboard graphics ? removing graphcs card and using that would be a good test | 08:55.58 |
| RobinWattsLenovo | No onboard graphics, no. What sort of motherboard do you think I'm using :) | 08:56.21 |
| kens | No idea, these days its hard to zstop Intel chips providing onboard graphcis | 08:56.43 |
| chrisl | I'm surprised you can get a mobo without on board graphics these days....... | 08:56.56 |
| kens | HmmPC is better ? | 10:58.47 |
| Robin_Watts | New PSU seems to have helped. | 11:01.56 |
| tor8 | Robin_Watts: so, I've been trying to figure out ways to make the exception handling in mujs public functions | 12:36.21 |
| | seems like the only sane way to return a jmp_buf is via a void* | 12:36.40 |
| | since jmp_buf is defined as an array type (with a secret private implementation specific actual type inside) | 12:36.57 |
| Robin_Watts | tor8: mujs exception handling is jmpbuf based? | 12:37.17 |
| tor8 | it's very similar to the fz_throw stuff | 12:37.38 |
| | http://git.ghostscript.com/?p=user/tor/mujs.git;a=commitdiff;h=0fd82b60cff02f1fe2a74d820902bd1fc4667d7b;hp=f5b3d15f0cacbca32398f4409dd104634d214175 is the best I can come up with | 12:37.51 |
| Robin_Watts | But just a single layer, rather than a nested set ? | 12:38.00 |
| tor8 | but if you've got ideas to add some type safety I'm all ears | 12:38.01 |
| | it's a nested set, so I have a js_Jumpbuf stack just like in fz_throw | 12:38.18 |
| | but rather than fz_throw/catch/always I just have js_try/js_endtry | 12:38.29 |
| | js_try is the setjmp, endtry pops the internal nested stack structure | 12:38.43 |
| | since everything in mujs is garbage collected, there's less need for the always/catch cleanup balance | 12:39.12 |
| Robin_Watts | tor8: If it was me, I'd just copy fz_{try,catch,always} etc as js_{try,catch,always} | 12:39.53 |
| tor8 | and I don't want to expose the internals to the public interface, so I want the savetry to return the jmp_buf | 12:40.34 |
| | but I've run into places where I really do want to let clients call try/endtry to catch javascript exceptions | 12:40.52 |
| Robin_Watts | tor8: Well, fz_try/fz_catch is about as nice an interface as you can hope to offer to the public, I think. (I mean, we've tried quite hard!) | 12:42.20 |
| tor8 | Robin_Watts: yeah, it's a pretty nice set of macros | 12:42.32 |
| Robin_Watts | and nothing about the internals is exposed, right? | 12:42.34 |
| tor8 | fz_try has if (fz_setjmp(ctx->error->stack[ctx->error->top].buffer) == 0) | 12:42.53 |
| | that ctx->error->stack stuff is things I want to avoid exposing to mujs | 12:43.05 |
| Robin_Watts | Instead of an fz_context, you'd use a js_State | 12:43.17 |
| tor8 | I'm hoping to keep the api for mujs a little bit binary compatible between versions, not expecting the same amount of public churn as mupdf | 12:43.27 |
| | but I expect plenty of internal churn inside the js_State struct | 12:43.44 |
| Robin_Watts | Do you consider the internals of a js_State to be 'public' ? | 12:43.46 |
| tor8 | js_State is an opaque struct to the external api | 12:44.01 |
| Robin_Watts | OK. | 12:44.17 |
| | Yeah, we'd need the error stuff to be 'public' (in that it would be visible), but it's not really public as all access to it is through macros. | 12:45.08 |
| | Suppose you wrap all the exception stuff up into a js_error struct. | 12:45.32 |
| | and then have js_State start with a js_error struct. | 12:45.46 |
| | Then the macros can cast js_state * to a js_error * | 12:46.07 |
| | or (if you want to use a js_error * in the js_state) they can cast a gs_state * to a js_error **. | 12:46.36 |
| | That way only the js_error is public, and we can put a big notice there saying "don't access this directly". | 12:47.05 |
| | If you DO want to avoid all that, and go with a solution that returns a jmp_buf, then why not define a structure like: | 12:49.52 |
| | typedef struct { jmpbuf_t buf } js_jmpbuf; | 12:50.14 |
| | and then return a pointer to that ? | 12:50.23 |
| tor8 | we could probably make the fz_try macros a bit nicer if we were to let fz_push_try return a jmp_buf as well | 12:55.29 |
| | then again, you have the {{{ triple-nesting to catch errors | 12:55.55 |
| Robin_Watts | tor8: I'm always up for improvements to those macros... | 12:56.40 |
| tor8 | void* is such a simple solution... | 12:57.05 |
| | and if it's hidden in macros, I don't really think it's too troublesome | 12:57.23 |
| Robin_Watts | if (fz_setjmp((fz_push_try(ctx).buf)) == 0) | 12:58.01 |
| | if (fz_setjmp(&(fz_push_try(ctx)->buf)) == 0) | 12:58.22 |
| | That is nice, I think. | 12:58.51 |
| | and no casting. | 12:59.00 |
| tor8 | the error context ->stack field is an anonymous struct, we'd have to pull that out | 12:59.27 |
| Robin_Watts | but you still need access to the internals of the stack for always/catch. | 12:59.42 |
| tor8 | yeah, I don't fancy adding a function call for the stack->code access | 12:59.58 |
| Robin_Watts | If we dropped always, then catch doesn't need the code. | 13:00.20 |
| | So for mujs, this could work. | 13:00.30 |
| tor8 | the ctx->error->stack[ctx->error->top] stuff could be simplified if we make the 'top' a pointer to a stack slot itself | 13:00.31 |
| Robin_Watts | lunches. bbs. | 13:10.21 |
| | tor8: 2 commits on robin/master. | 14:53.17 |
| | oh, sorry, 4 commits. | 14:53.36 |
| | That adds the bidirectional code to MuPDF and the code to run it. | 14:53.51 |
| | Next stage is to update the layout stuff to use it. | 14:54.10 |
| | I may have to dive back to SmartOffice for a bit though before I do that. | 14:55.37 |
| kub | kens: hello, did me email make its path to you? | 14:57.37 |
| Robin_Watts | kub: Just ignore the copying file. sorry about that. | 14:58.22 |
| kub | Robin_Watts: NP, just to be explicite, what you like. | 14:59.43 |
| kens | kub your last email (removing the domain) worked well for me, I will ask Scott if he received it | 14:59.51 |
| kub | kens: thanks | 15:00.01 |
| | kens: you where right. Indeed the site was hacked a while ago, still needs work though. | 15:01.16 |
| kens | Ah, well at least that explains the domain blocking | 15:01.32 |
| kub | true | 15:01.45 |
| kens | OK mail sent to Scott, but he's in Texas so it might take a while to hear back | 15:02.58 |
| tor8 | Robin_Watts: so I did some napkin math for the flow structure. the entire lord of the rings trilogy is less than 500k words, so if we use two flow nodes for each word (one for the word, one for the space) even if they take 44 bytes each, and average 10 chars per word ... that's about 50Mb of memory | 15:03.52 |
| Robin_Watts | That sounds a lot for a tiny embedded device, but not a ridiculous amount, true. | 15:05.11 |
| tor8 | Robin_Watts: when do you use bitfields and when do you use bit masks? | 15:05.15 |
| Robin_Watts | I never use compiler bitfields. | 15:05.27 |
| kens | Rats. Alex made a dumb change 8 years ago. I can fix that but its been masking a problem with the null device for all that time. Now I have to fix that too :-( | 15:05.37 |
| tor8 | Robin_Watts: hmm, I thought you did... | 15:05.47 |
| | I never use them, but I've never had a real need to | 15:05.59 |
| Robin_Watts | Maybe I do in the displaylist device. | 15:06.04 |
| tor8 | I thought we did somewhere | 15:06.08 |
| Robin_Watts | Yeah, the displaylist device. | 15:06.31 |
| | hmm. Maybe I should move to use bitfields for clarity. | 15:06.47 |
| tor8 | I think merging the type and flags into one bitmask is awkward. two shorts would be clearer and use the same packing. | 15:07.12 |
| | but compiler bitfields would possibly be even better | 15:07.35 |
| Robin_Watts | Yeah. Will fix. | 15:07.48 |
| kens | kub Scott got that email OK, looks like I cna bow out of the conversation now :-) | 16:08.22 |
| Robin_Watts | tor8: Updated version online. | 16:35.19 |
| rayjj | my user experience on Windows 10 leaves me wondering if I should have stayed with 7 :-/ | 16:45.21 |
| kens | THat's impressive, a faulty commit causing a regression that didn't get noticed for 8 years.... | 16:53.08 |
| age_killer | hi guys, I am trying to find out if there is something like a queue for Ghostscript, my goal is to have a script that merges random number of pdf's | 17:06.50 |
| | is something like this doable at all | 17:07.00 |
| kens | Well you can always write it | 17:07.15 |
| | It depends totally on what you mean by a 'queue' | 17:07.23 |
| | Note that Ghostscript does *NOT* merge PDFs | 17:07.36 |
| age_killer | what about the -dBATCH flag then | 17:08.13 |
| kens | What about it ? | 17:08.24 |
| age_killer | with it I can merge two files into a single one | 17:08.52 |
| kens | No you can't | 17:09.02 |
| | -dBATCH simply tells Ghostscript to exit after processing the input, instead of waiting for more input | 17:09.23 |
| age_killer | okay, I think I got what you mean, that GS does not really merge files, it basically creates a third file that contains the two input files | 17:09.50 |
| kens | Not even that | 17:09.58 |
| | It creates a brand new PDF whose visual appearance should be the same as the visual appearance of the input | 17:10.18 |
| | The content of the new file bears no relation to the content of the input files | 17:10.32 |
| age_killer | you mean that the DEVICE flag is taking care of the visuals? for example my output file contains the first input file as the first page and my second input file as a second page | 17:12.50 |
| kens | Not really what I mean no. | 17:13.03 |
| | Ghostscript interpretes the input (whether PDF, PostScript or, with other front ends, PCL or XPS) into a series of graphics primitives (such as move, line, curve, fill, stroke etc) | 17:13.42 |
| | These are then passed to the device for procsessing. THe device can callupon the graphcis library for services, and generally devices use these to render the operations to a bitmap | 17:14.16 |
| | However, the high level devices are capable of reconstructing these operations into higher level output, such as PDF or PostScript. | 17:14.37 |
| | That does not mean its the same output as the input, just that the marking operations of the input have the same effect as the marking operations of the output | 17:15.13 |
| age_killer | I see, thanks for the clarification and sorry for the newbie statements I've made :) | 17:15.26 |
| kens | -sDEVICE selects a device, you are, presumably, using the pdfwrite device | 17:15.28 |
| age_killer | yes, I am | 17:15.50 |
| kens | age_killer : its a **very** common misconeption about how GS and the pdfwrite device work..... | 17:15.58 |
| | And you'll find lots of places online where people confidently (and incorrectly) state that ths is what it does, sadly. I try to correct these when I can | 17:16.37 |
| rayjj | age_killer: and note that the pdfwrite and ps2write high level devices collect information from as many files as you give as input arguments (making temp files as they process) and create the PDF (or PS) file right before exit | 17:16.54 |
| age_killer | guys, thanks for your answers and clarifications | 17:17.48 |
| rayjj | age_killer: and you can have PDF input files and PS input files mixed willy-nilly as inputs to create a single PDF or PS file | 17:18.25 |
| kens | thinks I should put that explanation into the ps2pdf.htm documentation..... | 17:19.18 |
| | That explanation was almost copherent | 17:19.30 |
| rayjj | age_killer: so to get back to your initial comment, you aren't limited to just two input files | 17:19.35 |
| age_killer | what I am curious about is is there a way to work with a random number of files, putting each file in something like a queue and then put them all together into a single file | 17:19.46 |
| rayjj | age_killer: not sure what you mean by "queue" | 17:20.12 |
| | you can list as many files as you want on the command line | 17:20.31 |
| kens | Just do gs -<switches go here> file1 file2 file3..... | 17:20.42 |
| age_killer | yes, but my issue is that the number of files that would be processed will most likely vary from 2 to n... and I am not sure if I can dynamically tell GS the number of input files it should process | 17:22.11 |
| rayjj | age_killer: and if you have all of the input files in a folder, you can even use * to expand to the list | 17:22.25 |
| kens | You have to know how many files there are to start, then you just put all the input filenames on the command line | 17:22.39 |
| rayjj | age_killer: you don't have to tell gs -- it gets the number of args | 17:22.46 |
| | age_killer: now if you are calling gsapi_init_with_args (from C) you pass nargs | 17:23.22 |
| age_killer | yeah, I figured that much, just need to figure out how to pass it a random number of variables... | 17:24.44 |
| rayjj | age_killer: what system are you running on (windows or linux/macosx)? And are you invoking gs from the command prompt, a script or via the C api ? | 17:24.49 |
| age_killer | I am using plain BASH | 17:24.51 |
| | Ubuntu 15.10 | 17:25.08 |
| kens | The number of variables an't be random, you *must* know whch files you are going to pass in before you start, surely | 17:25.12 |
| rayjj | age_killer: so, bash has "shift" to process initial script variables, then you can use $* for the rest of the args | 17:26.21 |
| | that's if you are writing a script to process an arbitrary list of files | 17:26.54 |
| age_killer | yeah, I figured that much so far, guess I'll have to scratch my head a bit more at the "drawing board" :) | 17:26.54 |
| | at least I am trying to, lol | 17:27.09 |
| | thank you very much for your input and clarifications it really was helpful | 17:27.39 |
| rayjj | age_killer: but bash can also create a list of inputs using "*" (as in infiles/*.pdf) | 17:27.45 |
| | if the input files are in "infiles" | 17:28.11 |
| kens | chrisl do we know if the AIX build works with 9.18, and waht compiler do we mandate, gcc ? | 17:29.24 |
| | oh chrisl is afk | 17:29.50 |
| rayjj | the thing that is tricky about * expansion is that the order can be somewhat tricky, but bash is good at post processing lists using sed, awk, sort, etc. | 17:29.50 |
| | have to run an errand. bbiab | 17:30.50 |
| age_killer | rayjj: that is a nice proposal, I didn't think about it, will give a try, THANK YOU VERY MUCH :) | 17:31.24 |
| kens | OK off to do food-related stuff night all | 17:33.12 |
| rayjj | age_killer: your term "queue" is what was confusing. bash (nor batch language on windows) don't have such a thing. both can handle "variables" $1, $2, ... in bash %1 %2, ... in batch | 17:33.13 |
| age_killer | I was refering to something like a print queue, since I am working with files, sorry for the confusion | 17:34.40 |
| rayjj | and bash has $# as a special variable that is the number of arguments to a bash script, and "shift" and $* (and lots of other things to process the arguments to a script) | 17:34.42 |
| age_killer | thanks again for your input, rayjj :) | 17:36.30 |
| tor8 | Robin_Watts: bidi-impl.h is missing | 17:39.53 |
| | we already have unicode bidi classification functions (include/mupdf/fitz/ucdn.h) | 17:44.56 |
| | Robin_Watts: I sent you an email with some more Bidi thoughts. I think it may be a mistake trying to do the reordering during layout. Doing it during drawing is probably going to be a cleaner use of existing APIs and fits more naturally. | 18:17.02 |
| | when drawing lines, we already need to flatten the flow into an array of characters to create the fz_text object | 18:17.39 |
| Robin_Watts | tor8: I'm digesting your email. | 18:34.09 |
| | I prefer the idea of calculating the 'direction' of each word just once. | 18:35.25 |
| | After all it's a property of the text. | 18:36.42 |
| | There are 2 concepts of direction for the text that we need to keep track of. | 18:37.24 |
| | Suppose in arabic we have logical letters ABC DEF GHI | 18:38.16 |
| | Then those get displayed IHG FED CBA. | 18:38.34 |
| | So on a character level they go right to left, and on a 'block' level they go right to left. | 18:38.51 |
| | But ABC 123 DEF would be displayed FED 123 CBA because normal "arabic" numerals (even in a right to left context) still display left to right. | 18:39.58 |
| | ABC 123 465 DEF would appear as FED 456 123 CBA | 18:40.24 |
| | Hence for every 'word' we have 2 bits of information; whether the chars go right to left, and whether the blocks of text get accumulatefd right to left on the page. | 18:41.26 |
| | So, I agree that blocks should be rendered character-wise left to right at draw time, but they should be laid out blockwise at layout time. | 19:19.43 |
| | And that's what I'm working towards. I've got the blockwise layout done I think (though it's hard to tell with the absence of fallback fonts) | 19:20.11 |
| | Ok, with your fallback font fix in, it looks MUCH nicer :) | 19:27.04 |
| | And I think blockwise layout is right. | 19:31.59 |
| | tor8: OK, updated version that does charwise and blockwise stuff on robin/watts. Example epub as http://ghostscript.com/~robin/ManyLang.epub | 20:00.40 |
| | Mirror chars are still wrong (as seen by (blah) becoming )halb( ) | 20:06.21 |
| | Need to ponder this some more and talk it over with you tomorrow. | 20:07.09 |
| | OK, mirror chars fixed. | 20:18.08 |
| bofh_ | is this patch publicly posted somewhere or not yet? (I assume it's not in the main git) | 20:19.29 |
| Robin_Watts | bofh_: You can look at my repo. http://git.ghostscript.com/?p=user/robin/mupdf.git;a=summary | 20:21.28 |
| | tor8: For the record, your lexing commit, and the simplify try/catch one look fine. | 20:22.34 |
| | The font one seems plausible, and certainly gives nicer results for me, so if you're intending that to be committable, go for it. | 20:23.02 |
| bofh_ | Robin_Watts: also, something I'm having trouble understanding: what's the purpose of pdf_load_hail_mary_font? I can't seem to figure out what it does or why it exists | 21:26.02 |
| | (working on text extraction improvements) | 21:26.12 |
| | also thanks | 21:26.23 |
| Robin_Watts | The hail mary font is where you go where nothing else has worked. | 21:29.24 |
| bofh_ | ah, so it's literally worst-case fallback? | 23:20.33 |
| | any reason why it works that way with the whole storable mechanism instead of just calling pdf_load_builtin_font()? | 23:20.58 |
| | Forward 1 day (to 2016/01/19)>>> | |
IRC Logs