| | <<<Back 1 day (to 2012/10/07) | 2012/10/08 |
| sebras | tor8: Robin_Watts: ok, so I forgot to sleep and watched falcon 9/dragon launch. while I waited I fixed the silly bugs in the SHA code over at sebras/master. I wonder what the spacex-people did while _they_ waited... ;) | 01:54.07 |
| pietro10 | Hi. I'd like to get a clone of just the 35 core fonts. I noticed that I can get them from the git repo at http://git.ghostscript.com/?p=user/tor/core35.git;a=summary but you seem to have cloning disabled (judging from other IRC logs). Is there are a different way to clone the repo or another place to get the fonts? Thanks. | 03:04.49 |
| alexcher_ | pietro10: The fonts are in ghostpdl.git repository. | 03:13.42 |
| pietro10 | thanks | 03:16.52 |
| | I was asking because I wanted to use the standard fonts with Heirloom troff, which alas does not provide metric definitions for most of the standard PostScript fonts | 03:27.39 |
| sebras | tor8: looks like you might have set up your core35 repo incorrectly. even I can not clone the tree. getting a snapshot through gitweb works fine though. | 07:30.22 |
| chrisl | sebras: probably easier to go here: http://downloads.ghostscript.com/public/fonts/ | 07:36.42 |
| tkamppeter | I have a new attached-pdf-not-correctly-rendered bug, bug 693369. | 07:56.12 |
| kens | I don't think that's a pdfwrite/ps2write problem | 07:57.29 |
| | Because it doesn't render correctly woth Ghostscript | 07:57.38 |
| | Looks like you have it correctly assigned | 07:57.51 |
| | tkamppeter : in Acrobat I see the smae result | 07:59.48 |
| | Or at least, very similar | 08:00.01 |
| tkamppeter | kens, Poppler displays it correctly. | 08:01.06 |
| kens | MuPDF, Ghostscript and (most importantly) Acrobat all display it the same way | 08:01.26 |
| | I believe Poppler is wrong | 08:01.34 |
| tkamppeter | kens, so it is perhaps a bug of Cairo, not discovered because the Cairo developers only test their output with Poppler. | 08:02.56 |
| kens | tkamppeter I would say that is most likely the case, yes | 08:03.12 |
| | This of course is why we like to test with several different PDF consumers | 08:03.30 |
| | It would take me a little while to determine what is going on, but I suspect it will turn out to be a /Widths problem | 08:03.58 |
| | That is, Poppler is using the metrics from the font, and everyone else is using teh metrrics from the FontDescriptor, or something similar | 08:04.37 |
| | I just quickly tried several versions of Acrobat from 4 to X and they all show the same behaviour | 08:05.00 |
| | OK a quick look at the text 'der spiegel' shows that it is set using font /f-1-0, hich is object 6 in the PDF file. If I look at object 6 I see that it has a /Widths array where the widths are all 0. | 08:07.53 |
| | THe PDF Reference says that /Widhts 'should match' the actual wdths in the font. It *also* says that if they don't Acrobat will use the widths in the font. THis is a lie. Acrobat *always* uses the /Widths array, which is why Ghostscript does too. | 08:10.14 |
| | I had a quick go at removing the /Widths array and Acrobat complained. I'm pretty certain this isn't a Ghostscript problem, so I don't really want to spend a lot of time on it. | 08:11.54 |
| chrisl | This must be new behaviour for poppler/cairo - evince 3.4.0 using poppler/cairo 0.18.4 shows the same results as Ghostscript | 08:12.19 |
| kens | chrisl that *is* interesting, and not a good direction for Cairo to break compatibility with Acrobat | 08:12.48 |
| chrisl | My guess is that they're trying to something like ignore the Widths if they appear to be nonsense | 08:13.45 |
| kens | chrisl I would imagine that is true. Admirable, except that it breaks compatibility with the de facto standard | 08:14.14 |
| | I would also point out that the nonsense /Widths were produced by Cairo ;-) | 08:14.41 |
| chrisl | LOL!! | 08:14.53 |
| | Unfortunately, there are applications out there that mess with the Widths for "effect", including (I've seen at least one) using all zeros, so it would be best to match Acrobat here! | 08:16.15 |
| kens | Definitely, we do this for good reasons. | 08:16.33 |
| tkamppeter | kens, sorry, Poppler shows the same problem. | 08:16.39 |
| kens | (Reluctantly, because of the spec, but still) | 08:16.48 |
| | tkamppeter : I'm actually relieved to hear that ;-) | 08:17.41 |
| tkamppeter | kens, printed it unfiltered on two native PDF printers from HP (LaserJet P3005 and Color LaserJet CM3530) and both show the problem, too. | 08:21.39 |
| sebras | chrisl: I know, I was just researching pietro10's remarks about the git. it makes no sense to have a git public which can not be cloned. | 08:21.45 |
| kens | tkamppeter : well I think that absolves us ? :-) | 08:21.59 |
| sebras | chrisl: I guess it might be something in .git/config. | 08:22.06 |
| | never tried ssh. | 08:22.13 |
| chrisl | sebras: well, the git repos under our names aren't really for general public consumption, they're just for our own convenience. | 08:23.33 |
| Robin_Watts | chrisl: well, they are supposed to be useful for other people to pull changes from. | 08:24.47 |
| | hence having them not clonable doesn't sound right, | 08:25.06 |
| chrisl | Robin_Watts: If it was a mupdf, jbig2dec or ghostpdl repos, I'd be a little concerned, but I'm not really worried about repos that are just archives of third part stuff | 08:30.10 |
| | s/part/party | 08:30.22 |
| Robin_Watts | What do we gain by NOT having it clonable? | 08:30.30 |
| chrisl | Why do we care? | 08:30.57 |
| Robin_Watts | It's not standard. | 08:31.13 |
| chrisl | There's a standard? I must have missed it..... | 08:31.25 |
| Robin_Watts | Whenever we do something "unexpected", we ought to have a reason for it. | 08:31.29 |
| chrisl | Well, having the zip of the fonts in a repos is unexpected, from my POV | 08:32.02 |
| tkamppeter | kens, thanks, I have reported the problem to Cairo now. | 08:40.07 |
| kens | Thanks tkamppeter | 08:40.17 |
| sebras | chrisl: true enough. | 08:50.55 |
| | paulgardiner: it's an exceptionally good monday morning, is it not? :) | 08:51.09 |
| paulgardiner | not knowing to what sebras refers, checks the bug list for new bugs reporting exceptions in the android app. :-) | 08:53.11 |
| sebras | believes paulgardiner has psychic abilities. (check the logs instead) | 08:54.03 |
| paulgardiner | sebras: can you give me a good date/time to start from? | 08:55.25 |
| | got it | 08:55.49 |
| | So that's two different crashes provoked by madly clicking the pagebar? There was the one where android killed the app because lack of response to UI (for which I believe I have a fix) and now this one with divide by zero. | 08:58.53 |
| sebras | exactly. | 09:00.04 |
| | the division by zero is new. | 09:00.12 |
| paulgardiner | ah no. divide by zero is with an old version. It's an attempt to create a bitmap with width and height zero. Is that right? | 09:00.36 |
| sebras | I'm not sure. let me try it again. | 09:00.57 |
| paulgardiner | Ah right. It involves the backarrow too? So the slow-response-to-UI-event one is still the only one provoked by just by madly clicking the page selector? | 09:02.59 |
| sebras | paulgardiner: http://pastebin.com/qgWttZSY this is with mupdf 1.1 | 09:08.17 |
| | paulgardiner: yes I believe you're right, however the slow-response-to-UI-event results in the app being force terminated. | 09:08.55 |
| | paulgardiner: in the pastebin-log I'm opening a file, clicking on some pages pressing the back-arrow and selecting another pdf for opening. | 09:09.53 |
| | basically while the old one is still rendering. | 09:10.00 |
| paulgardiner | Yeah, closing an activity with on-going AsyncTasks is something I need to look into. The android docs warn of its being problematic, but give the explanation of what to do as "take a look at this app of ours" :-) | 09:13.23 |
| | The dead-to-UI problem I believe I have a fix for. | 09:14.38 |
| sebras | paulgardiner: oh, well, if mupdf would just not force clode in the case of background AsyncTasks then it would make sense at least. | 09:16.35 |
| paulgardiner | Possibly, although that might leave a native library in an undefined state. | 09:18.33 |
| sebras | paulgardiner: right. and should you want me to test anything, just ping me. | 09:24.39 |
| paulgardiner | Great. Thanks. | 09:30.31 |
| Robin_Watts | Morning mvrhel_laptop | 14:26.30 |
| | mvrhel_laptop: I have simplified the SEGVing file, and walked through it to see where the writer and reader side are getting out of sync. | 14:33.47 |
| | I've found the relevant bit of code that's breaking it. | 14:34.06 |
| | But I can't tell if it's a bit of code that's missing from the reader, or a bit of code that shouldn't be in the writer. Or whether there is some deeper problem here which means that neither is right. | 14:34.36 |
| | If you could spare a few minutes at some point, I'd be grateful. | 14:34.51 |
| mvrhel_laptop | Robin_Watts: ok give me about 20 minutes | 14:55.02 |
| Robin_Watts | mvrhel_laptop: Sure. Thanks. | 14:55.16 |
| | tor8: ping | 14:56.00 |
| sebras | tor8: Robin_Watts: you did notice me fixing the SHA-stuff, right? | 15:17.11 |
| Robin_Watts | sebras: D'Oh. I spotted you mentioning it this morning, and then promptly forgot. | 15:17.34 |
| | I will look in a sec. | 15:17.40 |
| sebras | Robin_Watts: if you don't have time that's fine. | 15:18.36 |
| Robin_Watts | sebras: No worries. I'm just preparing a commit at the moment. | 15:19.07 |
| sebras | oki. | 15:19.13 |
| Robin_Watts | tor8, sebras: 4 patches on my master branch, but ignore the functions and pdf_write ones. | 15:21.59 |
| mvrhel_laptop | Robin_Watts: I am here now | 15:28.45 |
| | looking at the code | 15:28.50 |
| | I don't remember why I put that limit in the clist case | 15:29.12 |
| Robin_Watts | I could try removing it and then pushing? | 15:29.44 |
| mvrhel_laptop | but the two should match up | 15:29.47 |
| | Robin_Watts: yes | 15:29.51 |
| Robin_Watts | Or I could copy that code to the clist playback side. | 15:30.17 |
| mvrhel_laptop | Robin_Watts: yes... :) | 15:30.31 |
| | I am not sure why I did this | 15:30.37 |
| | I am also confused why it would be needed | 15:30.44 |
| Robin_Watts | I keep going back and forth on whether that code makes sense in the writer. | 15:30.57 |
| mvrhel_laptop | i.e. when would pdev -> num components be larger than the target | 15:31.05 |
| | and why | 15:31.10 |
| Robin_Watts | I mean, the pdf14 device *does* add new planes. | 15:31.12 |
| | In this instance, we start of with max_comp=14 and num_comp=14. | 15:31.37 |
| | And the compositor is created with 13 spots. | 15:31.52 |
| mvrhel_laptop | huh? | 15:32.14 |
| | this sounds like a limit issue | 15:32.22 |
| Robin_Watts | So it gets max_comp=64 and num_comp=13+4=17 from the get_pdf14_clist_device_proto | 15:32.39 |
| mvrhel_laptop | oh | 15:33.04 |
| Robin_Watts | Which is then set back down to 14/14 by the code in question. | 15:33.09 |
| mvrhel_laptop | right | 15:33.15 |
| | so this is due to us bumping up to the limit of the number of colorants when the psdcmyk device is set up | 15:33.34 |
| Robin_Watts | right | 15:33.40 |
| mvrhel_laptop | ok. that is probably a case that was not so well tested | 15:33.49 |
| Robin_Watts | In the reading code, we get 64/17 from get_pdf14_device_proto and we just run with that. | 15:34.07 |
| mvrhel_laptop | I would say that the pdf14 device should be limited | 15:34.10 |
| Robin_Watts | OK, so I'll copy that code into the reader too. | 15:34.25 |
| mvrhel_laptop | if the psdcmyk device is limited then the pdf14 device should also be limited | 15:34.35 |
| | no use running around with extra planes | 15:34.49 |
| | that never get used | 15:34.54 |
| Robin_Watts | Does that affect that actual number of planes the pdf14 has? | 15:34.57 |
| mvrhel_laptop | no just the color ones | 15:35.06 |
| Robin_Watts | (i.e. shape/alpha + colors) | 15:35.07 |
| | OK. | 15:35.09 |
| | Then copying it makes sense to me. I'll give that a whirl. Thanks. | 15:35.28 |
| mvrhel_laptop | sure | 15:35.34 |
| Robin_Watts | sebras: I find this SHA code very hard to follow. | 15:50.50 |
| | I understand the use of 112 (eventually). | 15:55.05 |
| | But the change from for(j = 0; j < 16; j++) to for(j = 0; j < 8; j++) seems odd to me. | 15:55.45 |
| | uint64_t *'s are pointers to 8 byte things. | 15:56.02 |
| | digest is a 128 byte thing. | 15:56.12 |
| | therefore I'd expect there to be 16* uint64_t accesses, not 8. | 15:56.35 |
| | oh, the digest becomes a 64byte thing in your patch. Sorry. | 15:57.18 |
| | OK. Looks good to me then. | 15:57.27 |
| sebras | exactly, that was the bug. I messed this up back when I was porting stuff from someone else's codebase. | 15:59.31 |
| Robin_Watts | pushed. | 15:59.59 |
| | tor8: ping | 16:00.42 |
| tor8 | Robin_Watts: pong. | 16:00.50 |
| Robin_Watts | tor8: Hi. I've pushed a couple of small tweaks to my master branch. | 16:01.14 |
| | One of them introduces some consts into the code. | 16:01.21 |
| | I know you hate const, but I think these make sense. | 16:01.31 |
| | With C if you do bar("foo"); then "foo" is a char *. | 16:01.46 |
| | With C++ I believe it's a const char *. | 16:01.55 |
| | which means all the calls to things like pdf_dict_gets(dict, "Rotate"); etc will give warnings. | 16:02.19 |
| tor8 | Robin_Watts: they make sense, and don't infect constness elsewhere since they're all "leaf" functions | 16:02.35 |
| Robin_Watts | Cool. | 16:02.41 |
| | I should have volunteered to do the VS2005 rebuilds. I have it set up here, so it's no problem for me. | 16:03.07 |
| | Would you like me to make a replacement zipfile for you to upload somewhere? | 16:03.23 |
| | Morning henrys`. You at the show? | 16:04.21 |
| kens | Right, I've had enough. My head hurts from figuring out pdfwrite's so called colour handling. I'm off, goodnight all. | 16:04.45 |
| Robin_Watts | night kens. | 16:04.51 |
| | Oh, are you on your new shiny machine yet ? | 16:05.01 |
| tor8 | Robin_Watts: let's do that when we release the forms alpha thing | 16:05.07 |
| kens | No :-( | 16:05.09 |
| Robin_Watts | tor8: OK. | 16:05.27 |
| kens | Robin_Watts : I want to move the /Users to D: from C: and to do tha I need to either re-install Windows 7, or 'repair' it. When I try to repair it using the supplied DVD it can't find the existing installation, which I find alarming. | 16:05.57 |
| henrys` | I'm at the show! | 16:06.01 |
| Robin_Watts | kens: I left Users on C. | 16:06.23 |
| | But I mapped 'Documents' to D. | 16:06.29 |
| kens | Robin_Watts : So I have a support call to the supplier saying 'why is this happening, and what do I do about it?' and I'm waiting for a reply | 16:06.38 |
| | Robin_Watts : I could move alll the fodlers by using the 'Location' tab, but I'd rather move teh whole Users sub-tree. | 16:07.04 |
| | But to be honest, I'm mostly worried by the fact that the repair can't see an wexisting installation! | 16:07.21 |
| Robin_Watts | kens: Hmm. There may be a good reason for keeping Users on C. | 16:07.27 |
| | Stuff like ini files is saved to Users, right? And you might want that on the SSD. | 16:07.51 |
| kens | Robin_Watts : The 'godd reason' is becauwse it apparently never occured to anyone at Microsoft tha tyou would want it eslewhere.... | 16:07.56 |
| Robin_Watts | All the app local settings etc too. | 16:08.24 |
| kens | You cna move it during installation(with sufficient poking) or afterwards (by doing a special kind of repair and symlink) | 16:08.29 |
| | Robin_Watts : Like I said, I'm mainly concerned that when I try a erpair it can't find the installation. THat concerns me because if I ever do want to repair it I'd like to be able to.... | 16:09.07 |
| Robin_Watts | kens: Yeah, fair enough. | 16:09.25 |
| kens | The 'repair' tools can't see *any* of the disks. | 16:09.26 |
| Robin_Watts | Is that because you boot into the repair tools from the CD, and the CD hasn't got RAID drivers for your setup? | 16:09.59 |
| kens | Robin_Watts : that's possible, but it can't see the SSD either, and that uses the standard Windows SATA driver | 16:10.27 |
| | And even so, I'd like it to be able to see the RAID too..... | 16:10.47 |
| Robin_Watts | henrys_graph_exp: If the WiFi connection is typical of connections at shows, then as every stall holder logs in, it'll get slower and slower until the poor little router expires under the weight of 700 devices... | 16:11.09 |
| | henrys_graph_exp: Dunno if you can get email where you are, but paulgardiner has apparently put a new version of the app up somewhere for you. | 16:11.47 |
| paulgardiner | I put it here: http://intranet.glidos.net/~paul/MuPDF-Forms20121008.apk | 16:13.14 |
| henrys_graph_exp | paulgardiner:great I'll start setting it up now. | 16:16.32 |
| Robin_Watts | henrys_graph_exp: Do you have some good examples of form pdf files? | 16:17.11 |
| henrys_graph_exp | he sent them in the email | 16:18.01 |
| paulgardiner | henrys_graph_exp: I'll see if I can find a spreadsheet-like one too. | 16:20.52 |
| Robin_Watts | A tax form one might be good if it works OK, cos that's probably the form that most people might actually have to use. | 16:21.52 |
| paulgardiner | managed to tease it into life only about 1/2 h ago, so it hasn't had a huge amount of testing. | 16:22.34 |
| | That's handy: one of the ones I sent was tax... although it was UK tax. | 16:23.04 |
| Robin_Watts | I'm trying to test it now. Seems to work Ok on the transformer, except for me not having any forms files on there :) | 16:23.08 |
| paulgardiner | Robin_Watts: I'll send you the ones I sent to henry | 16:24.02 |
| Robin_Watts | Thanks. | 16:24.10 |
| henrys_graph_exp | now I've found an office and don't have to hang out at the booth, things are looking up. | 17:14.07 |
| | excuse my memory lapse but what was the verdict on reading pdf's > 2G on a 64 bit machine? That actually is going to come up here at the show shortly. | 17:20.51 |
| | alexcher? | 17:21.03 |
| chrisl | henrys_graph_exp: it won't work just now because of the limit on PS integers - I have work in progress to resolve it (on 32 bit platforms, too) | 17:28.28 |
| marcosw | Robin_Watts: I'm having trouble getting bmpcmp.c to compile. Can you see if it's something with my setup? | 17:29.49 |
| henrys_graph_exp | chrisl:thanks for the info. | 17:33.08 |
| chrisl | henrys_graph_exp: what I have just now uses 64 bit integers in PS, but with stuff in there to pass the PS CET when CPSI mode is true. Now I can tackle the stream code. | 17:34.22 |
| henrys_graph_exp | is this a theoretical fix or do you have a 2 gig example? | 17:34.54 |
| chrisl | I don't have an example, I'll get one when I'm ready to test it | 17:35.17 |
| henrys_graph_exp | good thought experiments usually don't pan out in ghostscript. | 17:36.04 |
| chrisl | Well, this is at least *part* of what's needed - unless we want to wait for the C PDF parser..... | 17:37.04 |
| mvrhel_laptop | henrys_graph_exp: how is the show looking? | 17:37.54 |
| henrys_graph_exp | it's okay, I'm not very happy with our location, we are all the way in the back facing the emergency exit. | 17:46.02 |
| | next to the guy selling foot inserts ... | 17:46.31 |
| | bbiab moving locations. | 17:46.53 |
| Robin_Watts | marcosw: back, sorry. | 18:05.13 |
| | Did you get bmpcmp.c to compile ? | 18:05.20 |
| | Balls. looks like I've broken the build. | 18:09.03 |
| | Has anyone pulled the gs source in the past 2 hours? | 18:34.33 |
| | marcosw: ping | 18:40.10 |
| marcosw | yes | 18:40.15 |
| Robin_Watts | did you get it working? | 18:40.20 |
| marcosw | no, I"m still meeting with my advisor | 18:40.28 |
| Robin_Watts | sorry. | 18:40.34 |
| mvrhel_laptop | bbiaw | 18:41.44 |
| marcosw | Robin_Watts: I'm out of the meeting now. | 18:49.28 |
| Robin_Watts | Right, you were saying you were having trouble building bmpcmp ? | 18:49.52 |
| | bmpcmp.c has a buildline at the top of it. | 18:50.23 |
| | Which I stole from your cluster code, if I recall correctly. | 18:50.51 |
| marcosw | doesn't work anymore. | 18:51.24 |
| Robin_Watts | cos of pnglibconf.h ? | 18:53.12 |
| marcosw | yes. | 18:53.30 |
| Robin_Watts | gs/obj/pnglibconf.h ? | 18:54.04 |
| marcosw | In file included from gs/toolbin/bmpcmp.c:16: | 18:54.50 |
| | gs/libpng/png.h:434:27: error: pnglibconf.h: No such file or directory | 18:54.51 |
| Robin_Watts | gcc -Igs/libpng -Igs/zlib -Igs/obj -o bmpcmp -DHAVE_LIBPNG gs/toolbin/bmpcmp.c gs/libpng/png.c gs/libpng/pngerror.c gs/libpng/pngget.c gs/libpng/pngmem.c gs/libpng/pngpread.c gs/libpng/pngread.c gs/libpng/pngrio.c gs/libpng/pngrtran.c gs/libpng/pngrutil.c gs/libpng/pngset.c gs/libpng/pngtrans.c gs/libpng/pngwio.c gs/libpng/pngwrite.c gs/libpng/pngwtran.c gs/libpng/pngwutil.c gs/zlib/adler32.c gs/z | 18:55.06 |
| | lib/crc32.c gs/zlib/infback.c gs/zlib/inflate.c gs/zlib/uncompr.c gs/zlib/compress.c gs/zlib/deflate.c gs/zlib/inffast.c gs/zlib/inftrees.c gs/zlib/trees.c gs/zlib/zutil.c -lm | 18:55.08 |
| | That relies on gs having been built so that libpngconf.h exists. | 18:55.23 |
| | in gs/obj | 18:55.29 |
| | Are you looking for something that will work on the cluster? | 18:55.56 |
| marcosw | gs has been built and there is a ./gs/obj/pnglibconf.h | 18:55.59 |
| Robin_Watts | Note the addition of -Igs/obj | 18:56.11 |
| marcosw | maybe an -Igs/obj will help | 18:56.13 |
| | right. Deja vu. | 18:56.25 |
| Robin_Watts | :) | 18:56.29 |
| dbrgn | hi. any mupdf devs here? :) someone mentioned in this ticket http://bugs.ghostscript.com/show_bug.cgi?id=691330 that an autoreload feature has been implemented. i built mupdf from source, but it doesn't seem to autoreload a changing pdf file... | 20:05.26 |
| | sebras Robin_Watts tor8 | 20:11.23 |
| | (oh sorry, i referenced the wrong ticket. i was talking about this one http://bugs.ghostscript.com/show_bug.cgi?id=691332) | 20:12.34 |
| sebras | dbrgn: hi! | 20:16.37 |
| | there are two ways of reloading a file: 1. press r in the viewer or 2. send a SIGHUP signal to the mupdf process (if you are on linux). | 20:17.57 |
| dbrgn | sebras: hi, thanks for taking the time to answer :) yep, i know those two ways to reload a file, i was just curious if there was a fully automatic way to reload a file (as requested in the bug ticket). this would be very convenient in combination with TeX build tools, because you wouldn't have to trigger the reload explicitly. i could just put the command in my buildscript, but it doesn't really belong in there because other people working on the same document | 20:20.18 |
| | if you don't want mupdf to monitor file changes by default, you could add a compile flag or a commandline switch to enable it... | 20:21.37 |
| sebras | dbrgn: wouldn't adding something along the lines of "kill -HUP $(pidof mupdf)" to your buildscript solve your problem? | 20:23.06 |
| dbrgn | i saw several people on the internet looking for a way to automatically reload a pdf file in mupdf while looking for a solution myself. one guy actually used a x input simulation tool to send the "r" keystroke, which is pretty overkill :) | 20:23.12 |
| sebras | yes, especially since SIGHUP is present. :) | 20:23.37 |
| dbrgn | sebras: it would in my case, but other people that don't use mupdf use my buildscript too. i guess the line wouldn't hurt, but it's setup specific... | 20:23.44 |
| | (i already commented the mentioned script concerning the SIGHUP feature...) | 20:24.22 |
| sebras | I think the main gripe is how to make this platform independent. mupdf is on MacOSX, iOS and Android as well (and the library itself is also being used in Windows). | 20:24.35 |
| dbrgn | hm, yeah. on linux, there's inotify. on windows there's System.IO.FileSystemWatcher (.NET, i'm not sure whether you can use that from C). on dalvik, there's android.os.FileObserver. | 20:28.35 |
| | but still it's not really platform independent, you'd have to work with platform detection, maybe with a polling fallback (which would suck though)... | 20:29.15 |
| sebras | exactly, this is why it isn't implemented yet. | 20:29.42 |
| | a new viewer is being worked on though, so there is still a chance that this might show up there. | 20:30.16 |
| dbrgn | ok (although i really liked the old ui-free viewer :)). | 20:30.42 |
| | the main advantage of it would be decoupling of building and reloading. | 20:30.56 |
| sebras | dbrgn: the intent is to have the new one be more feature-rich but still not have widgets get in your way of reading the documents. to the best of my knowledge anyway. :) | 20:31.40 |
| | dbrgn: yeah, I see the benefit of it. | 20:31.55 |
| dbrgn | anyways, would be great if you would implement that sometime. thanks for the nice work! :) and good night (or day, depending on your location). | 20:32.06 |
| | ok, sounds good :) | 20:32.21 |
| sebras | .se, so night is correct. :) you're welcome. | 20:32.41 |
| dbrgn | (PS: i didn't take a look at the sourcecode, but you have really clean, almost warning free build scripts :) not something you see every day...) | 20:33.21 |
| sebras | tor8: Robin_Watts: I updated the manpage with SIGHUP-information, and added a silly print of the encryption dictionary to pdfshow. I'm not sure whether tor8 likes this or if it is feature creep. if you like it -- take it, if not -- let me know and I'll get rid of it. | 21:07.51 |
| | Robin_Watts: your fz_function patch is lacking something, I get lots of undefined references. | 21:08.15 |
| | eh, and I caused 693368... :-P | 21:08.56 |
| | your patches look good though. | 21:09.03 |
| | Forward 1 day (to 2012/10/09)>>> | |
IRC Logs