| | <<<Back 1 day (to 2016/04/03) | 20160404 |
| jnoetzel | Hi, i have a problem with ghostscript 9.07. I'm using pdfmarks to define metadata for a pdf file but ghostscript sets the last input filename as title. Any ideas? | 06:49.30 |
| kens | You'll have to be clearer about the problem, you should also use a more recent version | 06:49.56 |
| jnoetzel | recent version: is the problem already known or fixed? I set the title as "[ /Title (My Title) /DOCINFO pdfmark" in a ps file. Small test case: gs -sDEVICE=true -dBATCH=true -dNOPAUSE=true -sOutputFile=test.pdf -f pdfmark.ps -f input.pdf | 06:57.50 |
| | not -sDEVICE=true, -sDEVICE=pdfwrite is correct | 06:58.48 |
| kens | So you are expecting to alter teh metadata in an *existing* PDF file by sending a PostScript pdfmark ? And you are sending the pdfmark before you process the PDF file ? | 06:58.49 |
| | If you want to know if there is a bug and its fixed, you can search our Bugzilla, apart from anythign else its more reliable than relying on developer's memories. | 07:00.28 |
| jnoetzel | in a bigger usecase, i try to stich a handful of pdfs and add a table of content and metadata with pdfmark. In the testcase it works when i change the order of the files. thanks. i will try it. | 07:02.57 |
| sebras | tor8 (for the logs): the commit on tor/master LGTM, please apply it. :) | 07:03.04 |
| kens | I am doubtful yuour command line can work. You have put '-f pdfmark.ps -f' whch means that you are directing the interpreter to treat the 'test.ps as PostScript which will certainly fail with an error | 07:03.31 |
| | The -f switch is for introducing PostScript directly on the command line, not for executing PostScript files | 07:04.08 |
| | You are executing the PostScript *before* you execute the PDF file, that's not going to work. The PDF interpreter sends the Metadata from teh PDF file along when it is read. Ths means that the Title you constructed with the PostScript is immediately overwritten by the Title read from the PDF file. | 07:05.24 |
| jnoetzel | And the other metadata, as such as /Author is present in the output file, because the inputfiles have not such a metadata? | 07:07.35 |
| kens | If its not present in the PDF file then it doesn't get sent along, no | 07:07.55 |
| jnoetzel | thanks, this answer helps me a lot. | 07:14.07 |
| ferter | hi everyone! | 16:26.30 |
| | i've got a question to You, considering mupdf. | 16:26.51 |
| | when i use mupdf to parse documents, does it have some kind of a cache, where it stores data that has just been parsed? or anything like this? the reason for me to ask is because i'm having memory leaks and i'm wondering is it because i'm not aware of certain mupdf features. like a cache i need to take care about somehow | 16:30.20 |
| | kind of an odd question i know | 16:31.04 |
| | but basically i want to know is it a right direction for me to look at or no. and yes, i've used profilers, - this is how o know that problem is somewhat around parsing | 16:32.36 |
| tor8 | ferter: hi. | 16:35.03 |
| | ferter: how are you detecting the leaks? | 16:35.18 |
| | if you have found a true leak, please open a bug report at bugs.ghostscript.com and attach the file and command line you use. | 16:35.48 |
| | there are several caches in mupdf; but everything should be cleaned up at exit. | 16:36.39 |
| | a PDF file has objects which are lazily loaded; so you will see memory use increase slightly as you run through a PDF file until all the objects have been loaded. | 16:37.39 |
| | Robin_Watts: RobinWattsLenovo: okay, I've got a few fixes on tor/master | 16:38.14 |
| | one is a reworking of the cluster mapping detection (a simplification, which makes it more robust in the face of quirky glyph reordering as seen in indic languages) | 16:38.37 |
| | it also bypasses the need to type pun the glyph_pos array | 16:39.04 |
| RobinWattsLenovo | ferter: It's almost certainly the 'store', used to hold decoded images etc. | 16:39.06 |
| tor8 | RobinWattsLenovo: and I've also got a code path that bypasses harfbuzz in the cases we talked about | 16:39.28 |
| RobinWattsLenovo | The value in the fz_new_context call defines the maximum size of the store. | 16:39.48 |
| | tor8: Will have a look in a bit. | 16:39.57 |
| | Is it evolved from my changes ? | 16:40.33 |
| tor8 | Robin_Watts: I reuse the existing hb_buf buffers, I just bypass the hb_shape step | 16:41.02 |
| RobinWattsLenovo | tor8: OK. | 16:41.12 |
| tor8 | so no need to malloc/free per string walker | 16:41.18 |
| | but yes, it's the same approach but with care taken to make sure the cluster mapping etc all works | 16:42.43 |
| RobinWattsLenovo | ok. | 16:44.10 |
| | Did you see the threading stuff ? | 16:44.17 |
| tor8 | I saw something happened; I have not looked at the commits. | 16:45.52 |
| | the style context should not be shared, IMO | 16:47.16 |
| | it has style settings for layout, which should not be shared. just like the aa settings. | 16:47.36 |
| RobinWattsLenovo | The only thing in the style context is the user_css. | 16:50.19 |
| | The user_css only affects the layout phase. | 16:50.34 |
| | That doesn't happen in the "per-thread" rendering stuff. | 16:51.03 |
| | Thus it makes no sense to have separate versions. | 16:51.18 |
| | With the AA stuff you can justifiably have different render settings (say for thumbnails). | 16:51.47 |
| tor8 | I have no strong sense of what's correct there | 16:52.08 |
| | so I'll go with what you think is best | 16:52.14 |
| | gah. with ligatures, the text extraction is having a hissy fit and inserting spaces willy nilly :( | 16:52.33 |
| RobinWattsLenovo | I don't think the measure_text change is correct. | 16:52.48 |
| | measure_string, sorry. | 16:52.59 |
| tor8 | measure_string measures the pen advance | 16:53.05 |
| | x_offset and y_offset are for positioning accents etc | 16:53.28 |
| RobinWattsLenovo | in the "Simplify harffbuzz glyphs cluster mapping" | 16:53.31 |
| | Right, so the 'max' measurement needs to be done on the advance + offset value. | 16:53.51 |
| tor8 | no, not the offset. it's intended to measure the pen advance... | 16:54.12 |
| RobinWattsLenovo | Ah, ok. I've changed my mind. | 16:55.25 |
| | Yes, your new way is right. | 16:55.34 |
| | It might mean that highlight boxes generated for selections are wrong, but that'll be a small change. | 16:55.54 |
| tor8 | that should be relatively minor; and depends on how highlight boxes are generated for selections | 16:56.36 |
| | I'm not sure this even comes into play for selections; that stuff happens on text extracted with the text-device | 16:57.37 |
| | which is currently having issues with ligatures :( | 16:57.43 |
| | I'd like to solve that problem too, but I think we should really start thinking about doing that release and not fiddling too much anymore | 16:58.07 |
| | I've got performance back to within 50% of pre-harfbuzz for the cases where we don't need harfbuzz shaping | 16:58.29 |
| RobinWattsLenovo | The penultimate commit can have the Memento_startLeaking and Memento_stopLeaking calls simplified a bit, but otherwise it's great. | 17:04.40 |
| | And all the rest look fine to me. | 17:05.04 |
| tor8 | I've got performance back to within 50% of pre-harfbuzz for the cases where we don't need harfbuzz shaping | 17:05.20 |
| | gah, up-arrow+enter in the wrong window :) | 17:05.38 |
| | RobinWattsLenovo: thanks. | 17:05.41 |
| RobinWattsLenovo | I think that seems like a reasonable tradeoff. | 17:05.55 |
| RobinWattsLenovo | goes for food. bbiab. | 17:07.04 |
| rayjj | RobinWattsLenovo: for when you get back, I've a couple of questions/comments on the MT mudraw changes | 17:12.11 |
| mvrhel_laptop | rayjj: how did your visit here go? Sorry I was not here | 17:13.39 |
| rayjj | mvrhel_laptop: it was great. Weather was good -- raining Sunday evening when driving up from the airport, but not horrible. The next morning was clear. The visit to the school was great, and Eric has that as is first choice | 17:18.55 |
| | mvrhel_laptop: we sort of cut it close Tue AM getting to the airport and actually had to cut the security line (we had TSApre on the way up, but not on the way back) | 17:20.12 |
| | the security line at 10:15 am was one of the longest I've seen in a while. Not even OC or LAX have been that bad (OC only gets bad for the 7am flights out) | 17:21.50 |
| mvrhel_laptop | rayjj: oh. yes. Stephanie said the rain on Sunday was crazy. Probably before you got there. I went to a college night at Ethan's middle school a couple weeks ago and DigiPen did a presentation. Ethan had done summer camps there for the last 4 years so I was familiar with it but it was neat to hear about the degrees they offer | 17:22.14 |
| | rayjj: yes. Seattle is having security line issues | 17:22.43 |
| | we are leaving tomorrow for a mini-vacation to California and are planning to get there early | 17:23.01 |
| | unfortunately Alden has a fever right now, so not sure this is all going to work | 17:23.19 |
| rayjj | TSApre would have been fine -- only about 15 people, but there were at least 150 in the non-pre | 17:23.30 |
| | mvrhel_laptop: oh, that's a bummer. I hope she gets over it in time. | 17:24.03 |
| | there was a virus going around Austen's school and it had most of the kids with a fever for 4-5 days (Thur-Mon for Austen) | 17:24.53 |
| | mvrhel_laptop: the program/degree that Eric is interested in is the "RTIS" | 17:25.52 |
| mvrhel_laptop | ah. good to know. She caught this on Saturday | 17:25.58 |
| | rayjj: that would be the one that I would like too | 17:26.31 |
| | sounds like a great program | 17:27.17 |
| rayjj | mvrhel_laptop: he shadowed a sophomore and went to two classes: CS 280 Data Structures and CS 250 Computer Graphics II | 17:27.31 |
| mvrhel_laptop | nice | 17:27.42 |
| rayjj | mvrhel_laptop: I joined them for lunch in the cafeteria. I've haven't seen such a nerd fest in a while | 17:28.42 |
| | Eric would fit right in :-) | 17:28.57 |
| | your son might be to normal looking ;-) | 17:29.35 |
| mvrhel_laptop | ha! | 17:29.54 |
| rayjj | but if he messed up his hair and (by then) didn't shave and put on funky wrinkled clothes, he might be able to pass ;-) | 17:30.56 |
| RobinWattsLenovo | rayjj: back | 17:58.05 |
| mvrhel_laptop | taking daughter to dr. be back in a while | 18:00.58 |
| rayjj | RobinWattsLenovo: I think you need to put the INIT_SEMAPHORE() invocations *before* the INIT_THREAD() because if the threads start, they will attempt to WAIT on the .start and .start could still be NULL | 18:07.05 |
| RobinWattsLenovo | rayjj: oops, yes. | 18:07.19 |
| rayjj | (at least the .start semaphore) | 18:07.29 |
| RobinWattsLenovo | Other than that, does it work for you? | 18:07.38 |
| rayjj | well, I find the "style" hideous, particularly the LARGE #if ... #elif ... #else ... #endif blocks. Any possiblility of moving those to separate files (one for each platform) ? | 18:09.15 |
| | to me, the separate line for "{" and "}" are bad enough, since my windows isn't tall enough to see the entire #if block | 18:10.15 |
| | or, at least indent and comment the start of various # sections. Sending a suggestion via email. | 18:11.16 |
| RobinWattsLenovo | rayjj: Nope, definitely not splitting them out per-platform. | 18:12.00 |
| rayjj | seems to me that other tools might want threads as well, so if they do, you have to put them in every usage ? | 18:12.59 |
| RobinWattsLenovo | rayjj: *IF* the other tools need them, then we'll add them. | 18:14.07 |
| rayjj | email with a suggestion for indentation of the # sections sent | 18:14.28 |
| | RobinWattsLenovo: add as in duplicate, or re-invent the wheel, or then split them out ? | 18:15.10 |
| RobinWattsLenovo | Add as in split them out then. | 18:15.46 |
| | The indentation won't work like that, as we only indent with tabs. | 18:16.05 |
| | Separate lines for { } are what we do everywhere. | 18:16.34 |
| rayjj | RobinWattsLenovo: I know that is the mupdf style, not expecting that to change | 18:18.49 |
| | RobinWattsLenovo: I have a 'pre-load' that I usually use when looking at mupdf files so that it re-formats more compactly | 18:20.03 |
| RobinWattsLenovo | I'll give Tor another chance to comment. I'm not sure he's reviewed it properly yet. | 18:20.26 |
| rayjj | RobinWattsLenovo: OK. The INIT_SEMAPHORE was the only non-style issue. Another "style" issue is having "magic numbers" for MUDRAW_THREADS, but with only 2, it isn't too bad | 18:21.42 |
| RobinWattsLenovo | I could #define MUDRAW_THREADS_WINDOWS or MUDRAW_THREADS_PTHREADS but I'm not sure that's nicer. | 18:22.28 |
| | I could have INIT_MUTEX/FIN_MUTEX/TAKE_MUTEX/DROP_MUTEX. | 18:22.52 |
| | Then common up the mutex_lock/unlock/init_locks/fin_locks sections. | 18:23.22 |
| rayjj | RobinWattsLenovo: no, not really, it's the REALLY LARGE blocks for each that is the readability gotcha | 18:23.31 |
| RobinWattsLenovo | Which would keep the windows or pthreads specifics to within a page. | 18:23.34 |
| | yeah, using extra macros would keep the platform specifics small. | 18:24.13 |
| | There would still be a difference between threaded or not, but even that would be smaller. | 18:24.33 |
| | Let me try for another version and see what you think. | 18:24.42 |
| rayjj | RobinWattsLenovo: that, or #if ... #else for each function | 18:24.43 |
| | RobinWattsLenovo: OK. | 18:24.59 |
| RobinWattsLenovo | rayjj: New version pushed. | 18:33.59 |
| | jogux: Hope today went OK. | 18:34.11 |
| rayjj | RobinWattsLenovo: ok, having a look.... | 18:34.12 |
| jogux | RobinWattsLenovo: thanks. Today was fine, just vigil (taking body into church), funeral proper is tomorrow. Fun drive down though, torrential rain to the point the motorway was a (shallow) lake with no visible markings, followed by hail. Of course not one of the HGV drivers backed off even the slightest bit below 60mph. | 18:38.34 |
| RobinWattsLenovo | jogux: I spent 7 hours in a car today being driven on polish A roads. | 18:44.31 |
| jogux | RobinWattsLenovo: That sounds not entirely fun? | 18:44.54 |
| RobinWattsLenovo | I thought *I* drove fast, but these guys are utter nutters. | 18:45.07 |
| rayjj | bbiab | 18:45.20 |
| RobinWattsLenovo | rayjj: A couple of versions there to look at. | 18:45.32 |
| | s/couple of/couple more/ | 18:45.45 |
| | Tailgate, Pull out, accelerate, hammer past, pull in just in time, slam on brakes before rear ending the car in front. | 18:46.20 |
| | rayjj: The main thing is that it should be enough to let you get timings. | 18:46.59 |
| jogux | RobinWattsLenovo: :-) | 18:47.10 |
| RobinWattsLenovo | Actually, I've taken the executive decision that I prefer my latest version. New version online. | 18:51.29 |
| | rayjj: 'Final' version online now. Happier with it. | 19:25.56 |
| Fennec-kun | Hey guys, I want to try MuJS but all attempts to compile it into something useful breaks down on me. Can someone supply me with a static library fit for Windows? | 23:52.57 |
| | Forward 1 day (to 2016/04/05)>>> | |
IRC Logs