Log of #mupdf at irc.freenode.net.

Search:
 <<<Back 1 day (to 2018/07/24)20180725 
palashah_ Hi19:36.58 
mubot Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line.19:36.58 
palashah_ I am facing a problem when compiling mupdf on OSX 10.13.6. It throws me this error -19:38.47 
  ld: warning: option -s is obsolete and being ignored19:38.53 
  Undefined symbols for architecture x86_64:19:38.53 
  "_glutLeaveMainLoop", referenced from:19:38.53 
  _do_main in gl-main.o19:38.55 
  ld: symbol(s) not found for architecture x86_6419:38.57 
  clang: error: linker command failed with exit code 1 (use -v to see invocation)19:38.59 
  any help ?19:39.01 
  grateful if someone could reply19:40.17 
  also, if I try copy-paste text in mupdf(installed using homebrew), it outputs a .tiff file. Is that normal behaviour?19:41.11 
raliste Hi guys, I've a question regarding the three rules of context22:02.06 
  ". No simultaneous calls to MuPDF in different threads are allowed to use the same document." this refers to the same fz_document instance or to the document on disk itself?22:02.25 
  I'm testing a server-side renderer for PDF pages, currently, for each page I create a doc and a ctx, then I get the PNG data with `fz_new_buffer_from_pixmap_as_png`. It works most of the times, but when called concurrently, it crashes with big images22:04.03 
  my theory is that it does refers to the underlying document as you might use just one fd for it? with bigger images takes more time to generate display lists, so the fact that is working with smaller images is just random luck?22:09.48 
  as we need to support dynamic rendering, ie. different pages and scales, what would be the best approach? (as we can't preload display lists - or can you scale display lists later on?)22:15.09 
  maybe just duplicate the document for each rendering task?22:15.23 
  just tried duplicating the documents, still crashes, no clue why, all three concurrent renders use different documents and contexts, even the stacktrace shows different pointers to different instances22:42.42 
  the only current solution is adding a mutex to fz_new_pixmap_from_page22:45.47 
  but still doesn't make sense why would it crash for different documents :(22:49.05 
 Forward 1 day (to 2018/07/26)>>> 
ghostscript.com #ghostscript
Search: