IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2013/01/22)2013/01/23 
Robin_Watts https://play.google.com/store/apps/details?id=com.artifex.mupdfdemo&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5hcnRpZmV4Lm11cGRmZGVtbyJd10:20.32 
paulgardiner Lovely10:27.28 
sebras Robin_Watts: how come that the developers page does not link to mupdf.com..?10:40.31 
Robin_Watts Does now :)10:41.29 
  Might take a few hours to show up.10:41.44 
sebras ah. :)10:41.53 
tor8 Robin_Watts: argh! now I finally figured out why the tinting on the file picker icons didn't work...11:37.56 
  setBackgroundResource() should be setImageResource()...11:38.10 
Robin_Watts tor8: Ah.11:38.54 
tor8 Robin_Watts: also, the lack of a path to where the navigation is is driving me nuts...11:39.16 
Robin_Watts Well, if you fix the icons we can rebuild and reupload, and I can test the auto update thing with Helens phone :)11:39.21 
tor8 Robin_Watts: I want to experiment more with the icons11:39.36 
  I'm not entirely happy with some of them11:39.44 
  maybe we should make a list of all icons we can think of that we'll want to use11:40.38 
  thinking ahead of the features for annotation that are in development11:40.48 
Robin_Watts tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=75643c9a1353b77b59e4c3006298a5feac81e33a11:53.45 
  Fixes various files. I've just been through the bmpcmp.11:53.57 
tor8 Robin_Watts: fz_transform_vector for transforming points that are used as vectors (i.e. ignore the translation)?12:08.58 
Robin_Watts tor8: could do, I guess.12:11.24 
  Would that be useful anywhere else?12:12.09 
tor8 Robin_Watts: probably not12:17.47 
Robin_Watts If it was used in more than one place then that function would be more clearly a win.12:19.30 
  Woo Hoo! I have smart advance working with pretty scrolling effects within a page.12:22.47 
  Need to sort the advance to next page thing now.12:22.59 
kens network kicking time14:06.27 
tor8 Robin_Watts: http://ghostscript.com/~tor/stuff/mupdf-debug-batch.apk yet another set of icons15:51.50 
  rather fat and rounded, but it turned out nicer than I would have expected15:52.04 
paulgardiner Yeah, I quite like those15:55.12 
tor8 paulgardiner: the set is a bit more complete than the old "iconic" set as well15:55.38 
  if it ends up missing things, it'll be harder to find ones that match though... given how much character it has15:56.10 
Robin_Watts I'm up to my ears in this smart motion stuff.15:57.47 
  It looks really promising, I just can't get the moving back a page to work.15:57.57 
  tor8: Ugh. I hate the directory icon,16:24.26 
  All the others seem nice though.16:25.20 
  http://ghostscript.com/~robin/MuPDF-debug.apk16:26.25 
  tor8, paulgardiner: That has a first version of smart motion implemented. Let me know what you think.16:26.45 
paulgardiner Like it. Seems to work fine.16:30.19 
Robin_Watts Morning henrys16:42.20 
henrys howdy Robin_Watts16:42.37 
Robin_Watts tor8: Oh! fz_transform_vector already exists!16:47.22 
tor8 Robin_Watts: ahem. I didn't know that!16:47.53 
Robin_Watts I'll update the review :)16:48.11 
henrys chrisl:we seem to generating tiff configuration files somewhere other than the build "gendir", I didn't track it down, I noticed in when trying to build a windows system in a shared directory after a unix build. I did clean and even blew away the "gendir"16:54.10 
  chrisl:not a big deal but if it is something easily fixed great.16:54.31 
tor8 Robin_Watts: I would prefer a different name for "p2", like "dp" or something more diff/delta-ish. other than that it looks good.16:54.35 
  Robin_Watts: I used 'dir' in a few other places16:55.02 
chrisl henrys: I mentioned that a *long* time ago. Problem: gendir doesn't exist during configure - also, when I checked it before, the libtiff configure script didn't work from a different directory16:55.59 
mvrhel_laptop good morning16:56.15 
Robin_Watts Morning michael.16:56.30 
  tor8: p2 => dir done16:57.05 
mvrhel_laptop cool. I will try the download on the nexus when I get back home (at coffee shop now)16:57.19 
tor8 Robin_Watts: push away!16:57.40 
Robin_Watts ta.16:57.44 
henrys chrisl:ah okay16:57.46 
tor8 Robin_Watts: paulgardiner: two quick android related reviews on tor/icons16:58.00 
chrisl henrys: I did think we could do something like create a "tiff-config" directory - *if* the tiff configure works now16:58.57 
Robin_Watts tor8: Urm... so if I'm in /mnt/sdcard/Download, the file picker will have "/mnt/sdcard/Download" where it used to have .. ?16:59.30 
kens OK off for pizzagoodnight all16:59.40 
Robin_Watts night kens16:59.44 
tor8 Robin_Watts: yeah. feel free to improve it.16:59.46 
  Robin_Watts: but it has the "up" arrow there so it made sort of sense16:59.56 
henrys chrisl:does it make sense to have gendir created by configure?17:00.01 
Robin_Watts tor8: it would be nicer if it said "[/mnt/sdcard]" and the title bar said: "MuPDF 1.1: Download"17:00.52 
  or maybe we could just make it say "/mnt/sdcard/Download/.." ?17:01.12 
chrisl henrys: "gendir" differs depending on the type of build you do, we don't know what it will be at configure time - release, debug, etc17:01.15 
tor8 Robin_Watts: or "[ Up one level ]" and the title had the path?17:01.19 
henrys chrisl:as it is now everything but tiff generates to gendir right?17:01.20 
Robin_Watts tor8: That would be nicest.17:01.51 
chrisl henrys: IIRC, tiff is the only other configure script we run, now17:01.54 
henrys chrisl:yeah I was thinking of pushing all those options up to configure17:02.03 
Robin_Watts I'm not sure how to set the title programmatically though.17:02.11 
henrys I suppose that would be a big change.17:02.22 
tor8 Robin_Watts: that feels like a horrible hack though...17:02.32 
Robin_Watts Does it? That feels correct to me.17:02.51 
  (The title saying "MuPDF 1.1: path" and .. being "[Up one level]")17:03.25 
tor8 I mean abusing the title like that. But it's the best idea so far.17:03.46 
henrys chrisl:but it would simplify the makefiles quite a bit.17:04.00 
Robin_Watts wooah. henrys, you want to configure between release and debug builds?17:04.33 
chrisl henrys: well, I like not having to re-configure for the different builds.17:04.41 
Robin_Watts No way, dude.17:04.43 
tor8 Robin_Watts: the bounce back when trying to swipe to flip pages is really annoying!17:05.47 
henrys chrisl:okay fair enough17:06.22 
chrisl Also, not being funny, but the way it used to "work" that stuff was done in both configure and makefiles. We discussed it a couple of years ago, and all agreed to handling it in the makefiles - and we've devoted a fair amount of time to getting all working nicely.17:06.25 
tor8 but I guess that's the android gesture recognizer not being as good as apple's17:06.26 
Robin_Watts tor8: dunno.17:07.11 
  I think Paul took the decision that any 'fling' stops at page boundaries.17:07.25 
  The alternative is to let the fling continue, and then to reset from where it stops.17:07.41 
  That would make swiping easier.17:07.50 
  But it may have issues with how many pages we have loaded at a time or something.17:08.12 
paulgardiner It's the scroller that made that decision really. We could have used OverScroller but it's not in v817:08.55 
  I guess we could fake it or make it conditional17:09.30 
Robin_Watts Well, we could use OverScoller if it's present, and the current one otherwise ?17:09.31 
  The question is, do we make left/right do what up/down do now ?17:10.03 
paulgardiner For chinese text in rows? :-)17:11.44 
chrisl henrys: is there somewhere "central" where we can grab the contributor agreement?17:11.58 
henrys chrisl:oh did we not put that up yet I've ticked it off my todo list17:12.54 
  nothing back from URW BTW...17:13.18 
  yes17:13.20 
paulgardiner If you had zoomed in to lose the margins, then it would move hard right before a page change which would be detrimental17:13.22 
henrys s/yes/yet17:13.25 
Robin_Watts paulgardiner: No. It only moves right if it can fit a whole new column in.17:13.49 
chrisl henrys: I've never even seen the agreement..... I don't know it Robin did the bugzilla hackery for it at some point17:14.04 
paulgardiner oh ok17:14.10 
Robin_Watts chrisl: I did not.17:14.22 
henrys I'll send it to tech17:14.46 
chrisl Cool thanks.17:14.56 
  And I'll update the interested users about the URW thing......17:15.24 
henrys done17:16.16 
chrisl Thanks17:17.53 
Robin_Watts tor8: I have a version working here with the title etc. Will upload an apk in a sec.17:20.49 
chrisl henrys: so, in new(er) libtiff we're using now, the configure script works okay from a different directory, so I think it would be good to change things around to use a "config" directory, or similar.17:23.59 
henrys chrisl:that would make it easier for shared directory builds.17:26.46 
chrisl henrys: I'll put it on my todo list..... I would certainly prefer it to work that way17:27.28 
henrys although I bet there is a simple way to get rid of extra files using git. - remove everything not under source control.17:28.19 
Robin_Watts git clean17:28.26 
  tor8, paulgardiner: http://ghostscript.com/~robin/MuPDF-debug.apk17:29.03 
  Observe the file picker.17:29.12 
chrisl henrys: or with extreme prejudice: git clean -x -f -d17:29.45 
Robin_Watts git alias nuke="git clean -x -f -d" :)17:30.27 
chrisl I prefer not to make something that extreme too easy!17:31.05 
henrys indeed I know I'll eventually lose an added file once I start the git clean habit17:32.56 
  not added in the git sense17:33.37 
  but something I want in the directory.17:33.45 
chrisl My most common one is losing a cut-down test file to git clean - but then, I also lose them to "make clean" since we started obliterating the obj and bin dirs for that.17:34.31 
ray_laptop alexcher: I'm glad you were able to duplicate bug 693496. Cust 532 would like an estimate for when it will be fixed.17:34.41 
chrisl ray_laptop: have you got a sec to talk about something related to the GC problem I'm looking at (Bug 693571)?17:37.22 
ray_laptop chrisl: sure.17:40.17 
chrisl ray_laptop: cool. So, in the gs_ref_memory_t structure we've got the chunk list (cfirst), the current chunk (pcc) in the list and the "active" chunk (cc)17:42.04 
  Now "cc" is "in-line" with the gs_ref_memory_t structure, so we end up copying the contents of the chunk into and out of that and the chunk list17:43.39 
  alloc_close_chunk() and alloc_open_chunk() do that copying.17:44.32 
ray_laptop ok, following so far17:44.47 
chrisl So, what I'm wondering is: do we really need the "cc", can't we just use "pcc" and ditch all the copying?17:45.19 
ray_laptop chrisl: then where will the current chunk be ? Just allocated on it's own ?17:46.07 
chrisl ray_laptop: it already is allocated, and held in the chunk list, what's in cc is a copy17:47.02 
ray_laptop chrisl: OK, right. But how does not copying to 'cc' cure the problem ?17:47.43 
chrisl ray_laptop: the issue in this bug is that we get into garbage collection with a chunk that hasn't been "closed" since the last "free" operation, hence the pointers in the chunk in the chunk list do not match the pointers in the cc structure17:49.35 
  So, the chunk validator tries to validate memory that has actually been freed17:50.39 
  I have a fix for that, but it strikes me as pointless doing the copying back and forth when we could simply use the chunk in the chunk list directly (via the pcc pointer)17:52.21 
ray_laptop chrisl: but the start of a GC calls alloc_close_chunk before it does the GC17:53.22 
  ireclaim.c line 12517:53.50 
  chrisl: so how can we get into garbage collection with a chunk that hasn't been "closed" since the last "free" 17:55.20 
chrisl ray_laptop: we only close the current chunk in the "top" allocator.......17:56.12 
  ray_laptop: the problem is when we do a save: we can use the allocator *after* it has been "saved", and that can leave it in an "unstable" state17:56.29 
ray_laptop chrisl: so you are seeing a 'free' in a chunk that isn't an 'inner_chunk' ?18:05.20 
chrisl ray_laptop: err, is it an inner_chunk? During a save operation, we can free memory using "mem->saved.state", and that leaves us in the unstable state18:07.39 
  ray_laptop: (now that my debugger is talking to me again!), this is happening in alloc_save_state()18:15.12 
  If we're past the first save level, we call save_set_new() passing in the *previous* generation of allocator. That can eventually call drop_redundant_changes() which can free memory in an allocator whose current chunk has already been alloc_close_chunk()'ed18:18.15 
  Hmm, the cluster seems to be throwing a fit again :-(18:21.09 
ray_laptop chrisl: All of the 'save' stuff is something I've never (as far as I can recall) dug into, but I thought that 'changes' were all supposed to be allocated in the chunks after the save, so how can there be a change from an outer chunk being freed by drop_redundant_changes ??18:27.57 
chrisl ray_laptop: changes are allocated after the save - once we've "saved" an allocator, though, we try to get rid of any pointless "changes", and that's where this problem arises.18:30.17 
  ray_laptop: so, if you put a breakpoint in alloc_save_state(), and skip to the first non-global save (the third call, for me).......18:32.10 
  At that point lmem->save_level == 218:33.04 
ray_laptop chrisl: I need to fire up the debugger with the problem file. Just a mo...18:33.31 
  oh, great. It's rebuilding about eveerything :-(18:36.25 
chrisl Okay, that'll give time to go grab a drink - back in a sec18:37.05 
ray_laptop chrisl: OK. It's the 4th bp for me, but I'm there18:38.58 
  That's the first call with global == 018:39.23 
chrisl Right, cool. So it calls alloc_save_space() which closes the current chunk, "saves" the allocator etc....18:40.12 
  And the "saved" allocator is moved into lsave->saved18:40.50 
  Oops, sorry: lsave->state is the "saved" allocator18:41.36 
  So, then, further down, we call save_set_new() passing in the "saved" allocator from lsave->state18:43.38 
ray_laptop chrisl: OK. right18:43.54 
chrisl Then we call save_set_new_changes()18:44.13 
  And in there, we *may* call drop_redundant_changes(), which can free memory in that allocator18:44.46 
ray_laptop chrisl: OK. This time it didn't do the drop_redundant call18:45.28 
chrisl No it doesn't do it every time, but it illustrates that we can end up freeing memory in an allocator that is not expected to be used at that stage.18:46.24 
  ray_laptop: for me, it will call drop_redundant_changes() on the fifteenth call to alloc_save_state()18:47.43 
ray_laptop chrisl: I have a bp in drop_redundant_changes and I get an exception BEFORE it is ever called. But that seems to be because I have -Zu set18:48.39 
chrisl ray_laptop: there is an issue with the memory pointer not being set for one of the printf calls - I have a fix for that, too18:49.27 
ray_laptop the last thing it printed was: [u]GC finalizing stream 0x299ead018:49.32 
  chrisl: OK. I'll turn that off for now18:49.54 
mvrhel_laptop yeah. I have the UI swiping working now in my mupdf windows metro app18:52.31 
  have to step out for bit to get wifes computer at the fedex store. somehow they missed me 3 days in row 18:53.09 
Robin_Watts mvrhel_laptop: Nice.18:55.48 
ray_laptop chrisl: OK, so I see it freeing some changes. A 'real' then a 'string', a 'name', ...18:59.47 
chrisl ray_laptop: so it's freeing in an already "saved" allocator, which is not expected19:00.18 
  hence the problem: the call to alloc_close_chunk() when we start gc only applies to the "top" allocator19:01.06 
ray_laptop chrisl: so this must happen ALL the time. Why only a failure with this file ?19:07.36 
chrisl ray_laptop: Well, not only this file, but with -Z@ - it may well be happening all the time, but if we don't zap the memory, we'll not see a problem19:08.51 
ray_laptop there is a comment in i_free_object about not overwriting contents if something is from an older save level.19:10.26 
chrisl We can't know it's an earlier save level, because we explicitly use the previous allocator instance.....19:11.25 
  Also, the memory being freed must be at the bottom of the chunk, so we have to move the cbot pointer19:11.57 
ray_laptop chrisl: so is the problem in chunk_locate_ptr not returning the correct bool ?19:12.10 
chrisl ray_laptop: no, the problem is after we've freed memory (which uses the mem->cc chunk) we never apply those changes to mem->pcc (the chunk in the chunk list). The gc code only ever uses the chunks in chunk list19:13.39 
ray_laptop chrisl: OK, I see. So it is using (writing to 'cc') for a chunk that has not been 'opened' and doesn't get 'closed' 19:15.22 
chrisl ray_laptop: yes. So my fix is to add an open/close around the drop_redundant_changes() call19:15.58 
ray_laptop chrisl: but different 'changes' might be in different chunks19:17.24 
chrisl ray_laptop: doesn't the allocator handle that possibility?19:18.14 
  ray_laptop: if the memory is not in the current chunk, the allocator should close the current chunk, and open the appropriate chunk19:19.16 
ray_laptop chrisl: I'm looking at i_free_object to see how (or if) it does that, but it isn't obvious. It seems like it should be done by 'chunk_locate_ptr'19:21.28 
chrisl ray_laptop: well, it can't expect the caller to know what chunk a block of memory was allocated in19:22.23 
ray_laptop chrisl: right. OK, so it scans to find the chunk. The while ((cld.cp = cld.memory->clast), !chunk_locate_ptr(ptr, &cld)19:24.55 
  but I don't see where it sets the 'cc' (that it later uses)19:27.33 
chrisl ray_laptop: I think if the memory we're freeing is not in the current chunk, we write the changes straight back to the chunk from the list - no need to open and close19:27.36 
  In fact, most of the time, we don't even change the chunk, we just "tag" the memory as free with pp->o_type = &st_free19:29.09 
ray_laptop chrisl: I see it setting 'cld.cp' (and sometimes it sets that to &imem->cc) 19:29.54 
  but isave.c line 854 just starts using imem->cc (as if the chunk is opened)19:31.03 
chrisl isave.c?19:31.57 
ray_laptop chrisl: sorry, gsalloc.c19:33.18 
chrisl ray_laptop: It does assume the chunk is open, yes. Opening and closing on every operation is a huge performance hit19:34.43 
ray_laptop chrisl: I agree that would be a performance hit, but it seems that after we find the chunk with chunk_locate_ptr we need to open the chunk if it wasn't already open 19:37.33 
  chrisl: we must be missing something, or how could this work ???19:38.14 
chrisl ray_laptop: if you look at the chunk_locate macro, I think it handles the problem you're thinking of19:40.28 
ray_laptop chrisl: is i_free_object, it doesn't use chunk_locate -- it uses chunk_locate_ptr19:41.25 
chrisl ray_laptop: line 90119:41.52 
ray_laptop chrisl: imem->cc is used in line 85419:43.10 
chrisl ray_laptop: yes, and we should be covered by the fact that we're checking the address.19:44.23 
  ray_laptop: generally speaking, the "active" chunk will always be "open"19:45.57 
ray_laptop chrisl: OK, that is only done when the the end of the object matches what's in cc.cbot, so what's in cc should be correct19:46.28 
chrisl ray_laptop: yes, so even if the chunk happens to be "closed" the data in "cc" will be correct19:47.18 
ray_laptop and the o_alone case just de-links a chunk from the list, so it doesn't modify the contents of the 'cc'19:48.12 
chrisl Yep19:48.23 
  ray_laptop: And the very last case, we only mark the header with pp->o_type = &st_free19:50.12 
ray_laptop chrisl: but where does the imem->cc get copied in ? I don't see chunk_locate doing it 19:50.24 
chrisl ray_laptop: copied in for what?19:50.44 
  ray_laptop: I was going to say, I'm a little bemused by line 913/91419:51.55 
ray_laptop imem->cc.int_freed_top gets examined and conditionally modified19:52.32 
  chrisl: right that's the spot19:52.48 
chrisl Okay, so I'm not sure about that, but it's not really relevant for the current bug.....19:53.25 
ray_laptop chrisl: granted (probably, depending on what the int_freed_top is used for)19:53.57 
chrisl ray_laptop: oh, I think it doesn't matter - that's just the address of the highest object on a freelist, I think it's not specific to the current chunk19:54.27 
  Oh, not sure.... :-(19:55.41 
ray_laptop chrisl: it seems to relate to 'trim_obj'19:56.08 
chrisl ray_laptop: Anyway, in the context of this bug, but the cbot and ctop pointers that are important - those are what gc uses to know where to scan19:56.58 
ray_laptop chrisl: or maybe the decision to call consolidate_chunk_free, but anyway, cbot and ctop, OK19:58.02 
  chrisl: so since i_free_object writes directly into the chunk and doesn't really modify cbot or ctop -- just messes with the o_type of the object (ignoring the o_alone case), how is it getting confused ?20:00.56 
chrisl ray_laptop: line 857, it's writes to cbot20:01.34 
ray_laptop right, but we said that was OK didn't "we" because of the ptr comparison ?20:03.22 
chrisl ray_laptop: that means it's the current chunk, yes. But if we don't "close" it before gc, the change doesn't get written back to the chunk list20:04.22 
ray_laptop OK, so closing the chunk after the drop_redundant_changes is what is missing ?20:05.02 
chrisl Yes. But for symmetry, I added an open chunk before drop_redundant_changes(), too20:05.40 
  That leaves everything in a nice stable state, so the gc code doesn't get confused20:06.22 
  ray_laptop: that change cluster tests okay, but I want to run my own test script tomorrow with -Z@, too20:10.03 
ray_laptop chrisl: alloc_open_chunk probably won't do anything because alloc_save_space did alloc_close_chunk then writes mem->pcc = 020:10.32 
chrisl ray_laptop: pcc isn't null when I get to drop_redundant_changes().....20:11.48 
  ray_laptop: the reason being the allocator being saved is assigned before that happens line 40120:13.53 
ray_laptop chrisl: OK, I see20:16.37 
  I still don't know why we didn't see this a LONG time ago. I run with -Z@$? a lot20:17.51 
chrisl It's quite a few circumstances conspiring to get us there, although, I agree, I'm surprised it hasn't appear before20:19.12 
ray_laptop chrisl: are you going to fix that int_freed_top (potential) problem as well ?20:20.01 
chrisl ray_laptop: I can look into it sure - but I think it's benign. I think it will only mean we'll call consolidate_chunk_free() sometimes when it won't help, and won't call it sometimes when it might help20:21.04 
ray_laptop chrisl: which might mean using more memory than needed, but I am pretty sure that GC resets this20:22.02 
chrisl ray_laptop: yes, by "benign" I meant no crashes, and no *huge* memory problems.20:22.49 
  ray_laptop: but what I really wanted your opinion on was the idea of getting rid "cc" and access chunks (more) directly via pcc - so we don't have to worry about keeping the "cc" entry, and the chunk list in sync with the open/close chunk copying20:24.19 
ray_laptop chrisl: I doubt I helped any, but at least you dragged me along enough to help me understand what you found, but I'll still let you fix anything else in save/restore in the future ;-)20:24.50 
chrisl Gee thanks!20:25.09 
ray_laptop chrisl: have you found any reason for the opening/closing chunk and having a copy of the 'current' chunk embedded in the gs_ref_memory ?20:26.37 
  like maybe that copy gets used during the GC or something ?20:27.17 
chrisl ray_laptop: not so far. I thought it was maybe for during initialisation, but that's not the case. My best guess (so far) is that it dates from when pointer accesses were relatively expensive, so the effort of copying was offset by having to use the pointer less often20:28.22 
ray_laptop not important, just curious. It could be something like that (avoiding indirection)20:28.52 
  or localizing memory access to improve likelihood of a cache hit20:29.23 
  but compared to the rest of all of the stuff we do, it seems funky20:29.47 
chrisl I'm not convinced we get a net benefit from it these days, assuming we ever did20:30.16 
  ray_laptop: But I only looked at it briefly, then I wanted to run it past you before I spent any more time on it20:30.56 
ray_laptop I just got the report from the weekly -Z@ run. Once you fix it, you'll probably have to get marcosw to re-run it20:31.31 
chrisl Can do. As I said, I'll run my own script tomorrow, for my own peace of mind20:32.43 
  ray_laptop: anyway, I need to stop now - I'm losing the ability to type. Thanks for going through this with me......20:35.18 
ray_laptop hmm, that's strange. I just got the email about the -Z@ regression run, and it says :results for 2013_01_23_2ae1a17..." but the latest commit it shows was on Jan 18th (the 2ae1a1a7 one)20:37.33 
  chrisl: np. Thanks for being patient as I stumbled along :-)20:37.59 
  methinks marcos should look into that20:38.23 
chrisl Right, goodnight, and god bless......20:40.57 
ray_laptop maybe the cutoff time is before those later commits yesterday.20:41.51 
Leolo_3 I have what might be a silly question : how does one set the output device w/in postscript?20:43.44 
  systemdict /DEVICE /ppmraw def doesn't seem to work20:44.08 
  I suspect one Can't Do That For Obvious Reasons20:44.30 
  I want the equiv of -sDEVICE=ppmraw20:44.43 
ray_laptop Leolo_3: with Ghostscript it is easy. (check doc/Use.htm): (ppmraw) selectdevice20:45.38 
Leolo_3 ha!20:45.54 
  ok, I was looking in 100% the wrong direction :-)20:46.06 
ray_laptop Read the Fine Manual ;-)20:46.09 
  Leolo_3: generally you can't define stuff in systemdict anyway 20:46.45 
Leolo_3 I'm pretty much a postscript newbie. I did a lot of forth way way back in the day, but apart from that, I'm cargo culting20:47.19 
ray_laptop PS is LOTS more fun than forth, (and lots more confusing)20:48.16 
Leolo_3 would something like "devicesnames { dup = selectdevice currentpagedevice /HWResolution get == } forall" be at all feasable?20:48.21 
  forth was helluva cool. but that was 20+ years ago20:48.39 
  oooo... it is, except that x11 doesn't work, so I have to filter out the bad device20:50.09 
ray_laptop Leolo_3: well, you've mispelled devicenames but otherwise that works for _some_ devices.20:50.41 
Leolo_3 yeah20:51.28 
ray_laptop although, why you want to do that, I don't know20:51.39 
Leolo_3 i want to get the all the default resolutions20:52.56 
  so I my prog can then calculate DEVICEWIDTHPOINTS properly20:53.25 
ray_laptop Leolo_3: not GS has PS extensions, like .sort that is handy, too. Try: devicenames dup length array copy { 100 string cvs exch 100 string cvs gt } .sort =20:56.01 
  Leolo_3: but DEVICEWIDTHPOINTS is ALWAYS in 1/72 inch. But if you want to set an exact number of pixels, you can use -gWWWxHHH option on the command line20:56.59 
  Leolo_3: actually on that .sort example, you probably want == 20:58.16 
Leolo_3 -g is also in points, no?20:59.33 
  oh fuck me, no it isn't20:59.49 
  I wanted, -dDEVICEWIDTH, not DEVICEWIDTHPOINTS21:00.03 
  SO MUCH TIME WASTED21:00.07 
ray_laptop Leolo_3: but DEVICEWIDTHPOINTS is the command line option. With PS use: << /PageSize [ width height ] >> setpagedevice21:00.08 
  I would suggest a read through at least Use.htm :-)21:01.52 
Leolo_3 I didn't, but I guess I'm just blind21:03.21 
  ok, this works better ... but still have problems21:04.15 
  ok, -dDEVICEWIDTH=2369 -dDEVICEHEIGHT=1737 -r72x72 produces what I want, but -dDEVICEWIDTH=2369 -dDEVICEHEIGHT=1737 -r100x100 doesn't 21:05.58 
  oh, because of the 2nd conversion step21:06.17 
adamben hey all - anyone awake?22:24.33 
sebras adamben: some of us are still here. is there anything in particular you want to ask about? :)22:57.36 
adamben I thought it was the place to ask about muPDF commercial license22:58.15 
  but maybe Im wrong22:58.17 
sebras adamben: no, you have come to the right place. sorry for the delay.23:27.07 
adamben Alright23:27.26 
  sebras: Are you associated with Artifex?23:28.09 
sebras adamben: I'm not working for Artifex, the company who licenses MuPDF.23:28.16 
adamben ahah23:28.25 
  ok23:28.25 
  I was going to ask you about their pricing23:28.35 
  Im looking to distribute a PDF component for Android and I'd like to license their PDF viewer23:28.49 
sebras adamben: but I recommend that you contact Scott Sackett at sales@artifex.com or at +1 940 482 7985.23:28.52 
  adamben: yes, I understand. I have seen this question come up a few times. :)23:29.13 
adamben great23:29.20 
  sending him an email23:29.23 
sebras adamben: I believe that you can also find contact info for him here, should you loose it: http://www.artifex.com/23:29.42 
  loose -> lose. my fingers write fast, but not correctly.23:30.46 
adamben right23:31.13 
  Just sent him an emai23:31.16 
  *email23:31.18 
sebras adamben: for any techincal questions you might have, feel free to ask here.23:31.22 
adamben I have some technical Q now :)23:31.30 
  or more featuresets wise23:31.35 
sebras might take some time before someone answers though. :)23:31.38 
adamben why?23:31.43 
sebras adamben: some developers are in .uk, some are in the us...23:32.25 
adamben Do you think I'll get a response by tomorrow?23:32.40 
sebras adamben: technical questions rarely go unanswered that long.23:33.21 
adamben Can I PM you?23:33.54 
sebras adamben: sure, no problem.23:34.07 
  adamben: I should emphasisze that I'm not working for artifex though, I'm just a hang-around here.23:35.24 
adamben no problem - sent you a message ;)23:35.38 
 Forward 1 day (to 2013/01/24)>>> 
ghostscript.com
Search: