IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2013/12/11)2013/12/12 
Robin_Watts ray_laptop: Really?00:49.29 
  ray_laptop: I believe their 'raw' output always pads the lines to multiples of 16.00:54.27 
  And your code no longer does that.00:54.33 
  I may have got the padding wrong, but it looks like you have no padding at all.00:54.46 
mvrhel_laptop hmm. looks like for the higher resolution printing with the surface I am going to need to do a bit of banding in the windows 8 app. 06:30.53 
  done for tonight06:30.58 
Giulio hi09:01.33 
ghostbot hola, giulio09:01.33 
Giulio is there someone?09:02.05 
  I've a question about mupdf for Android09:02.23 
  Is there a way to scroll pdf vertically and not horizontally?09:03.28 
oznt Giulio, it's a bug \ missing feature09:34.13 
  already reported it ...09:34.17 
  unfortunately i don't have the time to fix it myself ...09:34.28 
  http://bugs.ghostscript.com/show_bug.cgi?id=691330#c4609:35.14 
Giulio ok, thanks for answer...Did you have an idea on how to implement it? Because I think it's an Android feature not a C++ behavior, right?09:38.11 
oznt Giulio, i think so10:00.54 
  you will have to look in the code of the android gui, nut mupdf it's self10:01.19 
Giulio Yes, ok. thanks :)10:11.23 
sebras Giulio: mupdf is implemented in C, not C++, except som thirdparty libraries.10:12.41 
Giulio yes yes, I know :) my fault10:17.40 
sebras Giulio: btw, if you do end up with a patch for the java code then do send it as an enhancement bug in bugzilla. mupdf do appreciate suggested patched. ;)10:19.59 
  patches.10:20.02 
Giulio Ok, I'll try to do something..10:21.39 
tor8 Robin_Watts, morning.10:34.25 
Robin_Watts tor8: Morning10:34.37 
tor8 the number replaces all old numbers you may have on file10:34.49 
Robin_Watts ok.10:34.56 
tor8 and I may soon be in a mental state fit to receive your ideas on JNI locking and contexts10:35.08 
Robin_Watts tor8: I hope to soon be in a fit state to try to communicate them :)10:35.30 
kens feels fine today10:36.39 
Robin_Watts tor8: So, locking.11:34.42 
  My idea is to introduce some new functions: fz_lock_document(doc, ctx); and fz_unlock_document(doc);11:35.33 
  The first one locks the document, and rebinds ctx to doc.11:36.27 
  The latter one unlocks it.11:36.46 
tor8 right, so a document can be passed between threads and use the locking in the JNI layer to make it all transparent?11:37.24 
Robin_Watts Yes.11:37.33 
  Likewise we will need fz_device_lock and fz_device_unlock.11:37.53 
tor8 what about fz_device, fz_stream and pdf_object and the other objects that have embedded contexts? same deal there?11:38.06 
Robin_Watts pdf_objects have a document inside them, not a context.11:38.39 
  so the same fz_document_lock suffices there.11:38.52 
tor8 so pdf_object will lock the document implicitly?11:39.00 
  or internally11:39.19 
Robin_Watts tor8: I think we'll need a new set of pdf_object function that take ctx as an arg, and do the lock, yes.11:39.38 
tor8 let's wait with pdf_object. I think lock/unlock for documents and contexts makes sense.11:40.20 
  and it makes it explicit that they should be used in one thread at a time11:40.31 
  something else I wonder about here: should we maybe provide some standard locking implementations? depend on pthreads and win32 locks by default?11:41.02 
  or does that wreak havoc with java?11:41.09 
Robin_Watts tor8: I prefer our current 'agnostic' approach.11:41.26 
  we do provide example implementations in the code in docs.11:41.49 
  for pthreads at least.11:42.01 
tor8 okay.11:42.07 
Robin_Watts And we'll provide jni ones too as part of the jni bindings.11:42.34 
  I'll need to extend the locking stuff a bit to cope with the doc locking too, I think.11:43.21 
  I will bash on this a bit and see how it turns out.11:44.37 
tor8 Robin_Watts: anything to make the locking more explicit and easy to get not-wrong gets my approval :)11:46.11 
  I never liked the ctx argument, but everyone bashes my head in about how bad TLS is...11:46.13 
  maybe passing an explicit ctx and not embedding it in fz_document, fz_stream and fz_file is better despite the argument count bloating....11:46.53 
  eh, make one of those fz_device11:47.08 
  otoh, they are not thread safe, so I'm not sure what would be gained, maybe explicit locking is a better solution11:47.46 
Robin_Watts Passing an explicit context everywhere is probably the solution we should have gone with to start with.12:02.33 
  It's a low level ache that avoids larger pain elsewhere :)12:03.12 
  but it still doesn't give us thread safety to file access etc.12:03.29 
tor8 yeah. a bit annoying to change now though, for the majority of calls.12:09.47 
  maybe we should bite the bullet and fix it fon non-device, non-document cases though12:09.47 
Robin_Watts I am tempted to fix it for stream cases, yes.12:10.34 
tor8 just do it :)12:13.30 
Robin_Watts tor8: I had a potential customer ask whether we did progressive load of XPS the other day.12:31.36 
  I'm guessing our .zip file handling uses the central directory at the end of the fle ?12:32.02 
  file12:32.06 
tor8 we read and use the central directory, yes.12:33.55 
  adding a progressive mode shouldn't be all that much work, if required12:34.11 
Robin_Watts ok. I don't think it's a priority for them, but we might want to consider that at some point.12:34.23 
tor8 we basically ignore all of the .rels crap, but there are a few hindrances to progressive loading that may bite us12:34.57 
  like the start part, which is usually (90% of the cases) the last file in the zip12:35.43 
  now, we could use heuristics to just crap all over the document structure and look for fixed names (Documents/1/Pages/%d.fpage) which should work for most files12:36.18 
  but will fail spectacularly when it doesn't12:36.33 
Robin_Watts tor8: If we have control over the fetch, then that needn't be a problem.12:36.36 
  We could offer a tool to 'linearize' XPS.12:36.52 
tor8 if we have control over the fetch, using the central directory shouldn't be an issue :)12:36.55 
  Robin_Watts: yes. that would be a good tool to have.12:37.02 
Robin_Watts i.e. to put the files in order.12:37.04 
tor8 but given the interest level in xps...12:37.28 
Robin_Watts yeah.12:37.33 
tor8 such a tool would need to look at the resources and put them before the pages that use them12:37.55 
  and join the insane interleaved parts crap12:38.07 
  and you'd probably end up with a smaller file :)12:38.21 
Robin_Watts ideally you'd want to use the interleaved stuff so you could send the resource then the usage, then the next resource, then the next usage etc.12:40.28 
tor8 yeah, but I doubt any viewer can actually make use of such files12:40.54 
  given the loophole in the spec where you can't actually rely on it12:41.05 
  and that I've never ever even once seen a discard control part12:41.25 
  and really, if you have resources at random access, parsing the nested xml data in chunks, serially, interleaved with resources... no, that's just brain dead. shame on the people who designed the interleaved parts and decided to use xml.12:42.52 
Robin_Watts shame on the people who designed .... xml12:43.26 
chrisl That's not really fair - XML is fine, it's just not the "silver bullet" solution to every problem folks seem to think it is12:44.15 
Robin_Watts "The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well."12:45.28 
  Philip Wadler12:45.35 
  (Of course, that's from the guy who co authored Orwell, so make of that what you will :) )12:45.57 
  "XML is like violence: if it doesn’t solve your problem, you aren’t using enough of it." (from someone at Microsoft)12:46.26 
  "XML is like violence. Sure, it seems like a quick and easy solution at first, but then it spirals out of control into utter chaos." (Sarkos in reddit)12:46.53 
  But the top quote on this page is great:12:47.13 
  "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." (C.A.R. Hoare)12:47.28 
chrisl I think most of those quotes are confusing XML with the (mis-)use of XML......12:50.20 
Robin_Watts tor8: So, to return to the fz_stream stuff.13:42.45 
  I could just add fz_context arguments to fz_read, fz_seek, fz_meta.13:43.17 
tor8 yes.13:44.04 
  Robin_Watts: for symmetry's sake, do the same with fz_output?13:44.15 
Robin_Watts Either those could assign into stream->ctx and then call the underlying functions unchanged (which would have the advantage of not having to change any of the underlying implementations)13:44.17 
  Or I could pass the ctx on into stream->read, stream->seek etc.13:44.38 
tor8 I would rather fix everything so we limit the use of embedded contexts to devices and documents13:44.42 
  (and I guess pdf_objects for now)13:44.47 
  I would prefer the latter.13:44.58 
Robin_Watts Alternatively, I could have an fz_stream_bind(stream, ctx); function.13:45.17 
  which sets stream->ctx13:45.30 
  That would avoid any changes in the implementation, and just need a scattering of fz_stream_bind calls throughout our code.13:45.52 
tor8 I don't mind implementation changes.13:46.04 
Robin_Watts Performancewise, the latter is probably best.13:46.13 
tor8 I think only fz_read_byte etc will be impacted by any performance concerns13:46.33 
  and those should be inlined anyway13:46.38 
  however, it may make sense (eventually) to add fz_lock_stream for use by fz_document13:47.46 
Robin_Watts Ok, I'll go for the explicit context.13:47.46 
tor8 and then we could (with careful use) make multiple fz_documents on the same fz_stream13:48.01 
  lock/seek/read/unlock13:48.14 
Robin_Watts If we were to do that, it might make more sense to change streams to a 'read from offset' API.13:48.52 
tor8 Robin_Watts: Thanks. I'm sure it will save us pain in the future.13:48.55 
Robin_Watts i.e. combine seek and read.13:49.01 
  no locking required then.13:49.12 
  or rather no locking required from the caller.13:49.22 
  IF we're going to go for the lock/unlock stream thing, then explicit context is the wrong way to go, IMHO.13:50.08 
  as the rebind comes as part of the lock/unlock.13:50.18 
  but lock/unlock stream feels wrong to me at the moment.13:50.32 
tor8 Robin_Watts: yeah, but the question is where to put the offset, at each read_byte call, or just on the underlying object? or introduce a separate fz_buffered_stream type that is thread-local and holds the offset and buffer13:50.36 
Robin_Watts Multiple reading from the same stream is wrong, IMHO.13:50.56 
tor8 it will mean a lot of changes, so I'd prefer to just ignore the read-from-offset api for now13:51.10 
Robin_Watts If we want to do it we should make multiple streams from the same underlying object, I think.13:51.12 
  that way each stream keeps a single buffer, etc.13:51.39 
tor8 but make it so that file descriptor based fz_streams always do seek/read or pread13:51.40 
Robin_Watts right.13:51.46 
tor8 then we could fz_clone_stream and that would have the same underlying data but be readable from other offsets in other threads13:52.15 
Robin_Watts we could engineer it so we have 2 streams both using the same FILE *, and the details of how it does that would be hidden.13:52.26 
  yes.13:52.28 
  Ok, so explicit context it is.13:52.40 
tor8 but the implicit context binding as an API choice is something I sort of regret13:52.49 
  for the small data types like streams and objects that is13:53.09 
  maybe even for the device13:53.16 
Robin_Watts yeah.13:53.43 
  fz_streams and pdf_objects are the only things I can think of.13:54.07 
  fz_streams we are fixing now.13:54.13 
tor8 fz_outputs as well13:54.43 
Robin_Watts and pdf_objects have an fz_document in there we can lock, so I think we've actually dodged the bullet.13:54.51 
  OK, I'll fix fz_outputs too.13:54.57 
tor8 yeah, pdf_objects can lock the document when they need to load an object from file13:55.26 
Robin_Watts Callers will need to lock the document before making a pdf_object call.13:56.01 
  because pdf_object calls don't take ctx args.13:56.15 
tor8 Robin_Watts: my concern is also about objects that don't have an owning document (like when creating new dicts etc)13:56.40 
  or when doing pdfclean type operations where objects move from one document to another13:56.59 
  but we can worry about those later13:57.04 
Robin_Watts hmm. will ponder that.13:57.15 
  tor8: urgh. Moving the ctx out of the streams hits the lexer.14:53.02 
tor8 yeah... it spreads quite far (which is why we decided to pickle it the first time round)14:59.45 
Robin_Watts I'll push it through and commit it on a branch. Then I'm going to try the rebinding version as a comparison.15:01.02 
  pdf_lexbuf's too :(15:01.59 
tor8 Robin_Watts: brb, need to reboot15:02.53 
Robin_Watts mvrhel_laptop: Morning15:45.03 
  We got through security at OGG in about 5 minutes flat.15:45.31 
  Got to the gate with almost 2 hours to spare.15:45.41 
  Then as we went to get on the plane, our boarding cards didn't work.15:45.56 
  "Oh", they said, "You'll have to see an agent".15:46.12 
  Turns out the plane was downsized because of the snow in Dallas, so we had 47 fewer seats.15:46.38 
  They spent an hour reorganising everything, cramming first class passengers into economy, getting people to step off etc, but we did get on in the end (in exit row seats, so can't complain)15:48.07 
  Quite why they had to wait until we boarded before they reorganised rather than doing it while we sat around at the gate (or even at check in) is beyond me, but...15:49.00 
  There was the worlds most obnoxious woman there who was insisting that she be dealt with first. "I booked in January!" she kept yelling.15:50.01 
  There was a pretty obnoxious bloke there who finally snapped at her and told her to be quiet, whereupon she swore at him, and the desk clerks called security.15:51.01 
  When she finally got her exit row seats, and a credit for the difference etc, she didn't say thank you, didn't even draw breath, just demanded vouchers for free food and drink on the plane. Never mind that there were still other people waiting to get seats...15:52.11 
  And then when she got onto the plane, she proceeded to try to bash a huge box of chocolates or something into an overhead locker.15:52.46 
  The locker was already full and the bloke underneath said "careful, there is a laptop in there", and she said "well, if you don't want it broken, you'll have to move it" (bash, bash, bash).15:53.27 
  Amazing, just how many assholes there are in the world.15:54.20 
kens If oly that stupidity could be harnessed for something useful.....15:54.43 
tor5 hm, how do you start a private message session using the webchat interface?16:12.19 
Robin_Watts tor5: May not be possible.16:13.49 
tor5 right. so it only works if someone else starts it?16:14.10 
  neither /msg nor /privmsg seem to do the trick...16:14.24 
Robin_Watts tor5: Click on the users name on the right hand side and you'll get a menu with 2 options. The second option is "query"16:15.13 
  That starts a new tab.16:15.20 
tor5 oh, so that's what query means...16:15.33 
  Robin_Watts: yeah, there seem to be an awful lot of people like that when you travel...16:16.53 
Robin_Watts tor5: In filter-jbig2.c in fz_open_jbig2d in the if (globals) case, do we leak state->ctx ?16:19.06 
tor5 what makes you think that?16:20.50 
Robin_Watts state->ctx = jbig2_ctx_new(....); outside the if.16:21.13 
  Then if (globals) { state->ctx = jbig2_ctx_new(...); }16:21.37 
  so we override the existing state->ctx16:21.44 
tor5 oh... yes, that doesn't look right.16:21.52 
Robin_Watts oh, but maybe the state->ctx has been pickled into the state->gctx by then ?16:22.13 
  But I'd expect there to be a problem on error cleanup in that case.16:22.37 
  If the second jbig2_ctx_new call fails, then state->ctx will be cleaned up both as part of the cleanup for state->gctx and for state->ctx.16:23.08 
tor5 I really have no idea how this api is supposed to work, but it looks problematic16:23.36 
  I'd rather be explicit about the two jbig2_ctx_new calls if that's what is supposed to happen16:23.55 
  and handle the context setup individually for the cases in if/else blocks16:24.59 
Robin_Watts tor5: I'll tweak it here so it's right.16:29.13 
mvrhel_laptop Robin_Watts: good grief. that is a little unusual for someone coming from hawaii. they should be a little more relaxed on the way home16:38.45 
  but then I do have an image of this woman from your description and it is not pretty16:43.03 
Robin_Watts I honestly do not know how the staff put up with her.16:43.45 
  If it had been me, I would have called security much earlier.16:44.01 
mvrhel_laptop Hi Robin_Watts: I just pushed up a bunch of changes related to error trapping, removing warnings, fixing stuff that broke with other commits in the 3rd party structure and font names.19:00.05 
  if you can look this over that would be great19:00.12 
Robin_Watts sure. will look now.19:00.18 
mvrhel_laptop thank you19:00.22 
  I have one more thing I want to fix, then I will finally update the store app19:00.34 
  which is I need to do a bit of banding for the printing case due to the limited memory on the surface19:00.55 
  works fine on my laptop but the surface barfs when I push the resolution19:01.09 
Robin_Watts mvrhel_laptop: There is code in mudraw to do banding if that helps.19:01.28 
mvrhel_laptop Robin_Watts: I will look that over. thank you19:01.39 
  Robin_Watts: I have to run out for lunch.19:06.31 
  bbiaw19:06.33 
Robin_Watts mvrhel_laptop: I can't follow the logic with the thumbnail adding.20:39.27 
  Wierd indentation at around line 830 of MainPage.xaml.cpp20:41.08 
  and 880.20:41.36 
  UpDatePreRenderedPageSizes ? UpDate? surely Update ?20:42.44 
  More wierd indents at 1653ish.20:43.58 
  and 2125ish20:44.24 
  and 2137/8ish20:44.48 
  Broadly it looks OK. I can't claim to have any massive feel for the WinRT stuff, so there are limits to what a quick review will achieve, but it looks plausible.20:47.36 
  I'd like to understand the thumbnail adding logic a bit better though. I feel I am missing some key piece that would make it all make sense...20:47.58 
mvrhel_laptop_ Robin_Watts: just got back20:56.58 
  the thumb stuff is a bit odd and I just realized how I want to rework it20:57.10 
Robin_Watts mvrhel_laptop_: I've been away too.20:57.11 
mvrhel_laptop_ essentially the way that it was before, it was launching a thread for each page to render which was not good20:57.43 
Robin_Watts yeah, I get that it's trying to limit the number of threads that it's launching.20:58.02 
mvrhel_laptop_ the way it is now, it does not launch the next one until the previous one finishes20:58.04 
  but I am going to change this20:58.08 
Robin_Watts OK. I couldn't follow the logic there, but I'll wait for the reworked version.20:58.25 
mvrhel_laptop_ the issue that I had was that the call to do the render was an async call that launched a new thread20:58.34 
  I have since added a synchronous method which would be better here 20:59.23 
mvrhel_laptop since the whole thumb creation stuff is on a separate thread anyway20:59.39 
Robin_Watts ok.20:59.45 
mvrhel_laptop this will end up much clearer to read20:59.53 
  and fix if there are issues20:59.56 
  let me do that and amend this commit21:00.12 
  I was not entirely happy with what I had written there21:00.31 
  but it worked21:00.35 
  aha. Windows 8.1 added a new type RenderTargetBitmap that might help me21:48.13 
  ugh. the stupid sample they have is only in c#21:48.32 
  off to run some errands. bbiaw. Robin_Watts it will probably be this weekend before I get the new patch for you to review22:01.46 
 Forward 1 day (to 2013/12/13)>>> 
ghostscript.com
Search: