| | <<<Back 1 day (to 2013/03/01) | 2013/03/02 |
| oars | yeah, it does | 00:00.14 |
| sebras | oars: if there is a problem with the rendering then I would expect it to mess up the _entire_ window, but from the looks of it only the pdf-part is really affected. | 00:00.42 |
| | not the grey background. | 00:00.56 |
| oars | yeah, now that you mention it that seems odd. | 00:01.29 |
| | the application as a while seems less responsive too | 00:01.58 |
| | modifying the window size, or changing the zoom level takes a notisable amount of time | 00:02.20 |
| malc_ | oars: probably a bug in your X driver | 00:02.37 |
| sebras | oars: what window manager are you using? | 00:02.39 |
| oars | xmonad | 00:02.43 |
| | I would blame it on it, but it's the only application that has given me problem | 00:02.57 |
| malc_ | oars: you just don't use too many application that use ximage the way mupdf does | 00:03.22 |
| | +s | 00:03.27 |
| | oars: what graphics card/driver do you use? | 00:03.50 |
| oars | AMD Radeon HD 6770M with 1 GB GDDR5 | 00:05.27 |
| malc_ | with radeonhd or catalyst? | 00:05.46 |
| oars | I believe it's the catalyst ones | 00:06.14 |
| malc_ | in any case, i'd try and rule out this. either by using xnest or switching to alternative driver | 00:06.27 |
| robin_watts_mac | malc_: The lack of clipping is bad. We'll have to look into that. | 00:06.43 |
| oars | ok, I'll take a look to see what xnest is, never heard of it | 00:07.29 |
| malc_ | robin_watts_mac: yes it is, basically makes tiling a tradeof it wasnt meant to be (space for (alot of)time) | 00:07.33 |
| | oars: Xnest :1; DISPLAY=:1 xmonad | 00:07.56 |
| oars | oh, it's just a new X session in a window, that's meta | 00:09.19 |
| | hmmm, so I need to figure out how to open a terminal inside the new session as hte window manager captures the keybindings | 00:09.53 |
| malc_ | DISPLAY=:1 xterm | 00:10.05 |
| oars | oh, cool, so yeah | 00:11.26 |
| | mupdf works just fine inside xnest | 00:11.33 |
| sebras | oars: regardless of resizing..? | 00:11.47 |
| malc_ | echo | mail -s 'you suck' catalyst@amd.com | 00:12.54 |
| oars | sebras: oh, there it goes | 00:13.20 |
| | so it did show some trashing, but much less | 00:13.27 |
| | took a little juggling of the zoom levels and window size for it to show | 00:13.43 |
| sebras | oars: in the nested or non-nested mupdf if you bring up the search with '/' and enter a looong string. this this string look ok? | 00:14.29 |
| | oars: as far as I see from the code we really repaint the entire pdf-part of the window at a time, so I can't really see that mupdf would be at fault. | 00:15.08 |
| oars | sebras: it does show correctly | 00:16.58 |
| | http://i.imgur.com/Jtd0X52.png | 00:16.59 |
| sebras | oars: ok so the only thing that I can come to think of is that the type or order of X events that an app receives under xmonad might be different than under most other wms. | 00:19.41 |
| | oars: bug given the code in apps/x11_main.c::winblit() I can't figure out how on earth this could happen. | 00:20.30 |
| | oars: it's getting a bit late over here, but I'll try to reproduce your problem in xmonad locally. | 00:21.08 |
| malc_ | oars: you can also try to run compiz | 00:21.13 |
| | and see whether the problem persists with, basicaly, double buffered desktop | 00:21.42 |
| oars | sebras: sounds good, thanks for the help. If I come up with anything or find a solution I'll show my had back here again | 00:21.47 |
| sebras | oars: I'll be here again tomorrow. | 00:21.55 |
| oars | malc_: I'll give that a shot | 00:21.58 |
| | sebras: sounds good, where are you located? just wondering since you say it's late now | 00:22.22 |
| sebras | oars: .se :) | 00:22.43 |
| | oars: it's not _that_ late, but I've been working a bit too much lately,. | 00:23.01 |
| oars | sebras: everyone deserves some rest, I'm in Canada so it's only 5:30 over here | 00:23.18 |
| malc_ | 17:30 you mean | 00:23.30 |
| oars | yeah, that :P | 00:23.39 |
| malc_ | cause it is 04:23 here | 00:23.40 |
| | and i'm defintely nowhere close canada | 00:23.48 |
| sebras | oars: see you tomorrow then. | 00:24.15 |
| oars | lol | 00:24.17 |
| | sebras: night | 00:24.23 |
| | thanks again | 00:24.24 |
| sebras | np. | 00:24.26 |
| oars | thanks to you too malc_ | 00:24.31 |
| malc_ | not at all | 00:24.56 |
| mvrhel_laptop | cool. I have text search working asynchronously in the winRT mupdf viewer. | 04:48.34 |
| | at least conceptually. | 04:48.42 |
| | need to fill in a few deatils | 04:48.47 |
| | on that note, done for the night | 04:49.03 |
| _ingsoc | Is there a way to make the selected text go into a different clipboard? | 09:09.55 |
| sebras | _ingsoc: if you are on linux... no I don't think so. | 09:41.00 |
| | _ingsoc: not without recompiling at least. | 09:41.08 |
| _ingsoc | Hmm. I've using the git repository at the moment. Would it be a complicated tweak? | 09:41.28 |
| sebras | _ingsoc: let me have a look. :) | 09:41.45 |
| _ingsoc | I don't mind using two clipboards, because I merge them (using this: http://superuser.com/questions/68170/how-can-i-merge-the-gnome-clipboard-and-the-x-selection). | 09:42.23 |
| | But then when I copy some text out of mupdf, I select it just fine, but then I highlight some text to search in my browser that I want to replace with the text from mupdf, and I end up copying what I just selected in the browser, so it gets a little complicated. | 09:43.33 |
| | If I can get mupdf to use the other clipboard, it would work fine. | 09:43.50 |
| sebras | _ingsoc: ah. but then you basically only want to use the clipboard, not the primary. | 09:50.51 |
| | _ingsoc: i.e. whenever you just highlight something in a gnome app, then you don't want that to end up in the primary, and you also don't want the primary to be pasted. | 09:51.29 |
| _ingsoc | sebras: Hmm. How do I do fix that? | 09:51.49 |
| sebras | _ingsoc: basically you want a windows-like interface where highlighting text doesn't mean clipping at all... | 09:51.54 |
| _ingsoc | sebras: I'm a bit noob. Sorry. :/ | 09:51.56 |
| sebras | copying. | 09:51.58 |
| _ingsoc | sebras: Yes. | 09:52.02 |
| | sebras: I do want that, but I want to copy from mupdf. | 09:52.52 |
| sebras | yes, I know. :) | 09:53.01 |
| _ingsoc | But how? | 09:53.17 |
| sebras | so basically if mupdf only copied to the correct buffer when you wouldn't need autocutsel. | 09:53.28 |
| | (for this purpose at least). | 09:53.35 |
| | I'm not sure, yet. I'm trying to figure out the X11-functions still. | 09:53.59 |
| _ingsoc | sebras: Yes, that's right. I'm using the autocutsel option now as a workaround, but it's causing the select-copy issue elsewhere. | 09:54.47 |
| sebras | _ingsoc: I expected this to be a simple change from XA_PRIMARY to XA_SECONDARY. | 09:57.01 |
| | _ingsoc: but apparently I need to do some more reading. :) | 09:57.14 |
| _ingsoc | sebras: Hmmm. What file is it in? | 09:57.46 |
| sebras | _ingsoc: apps/x11_main.c | 09:58.03 |
| | in the function windocopy() | 09:58.16 |
| _ingsoc | Would it be related to XA_CLIPBOARD? | 10:02.17 |
| sebras | _ingsoc: yes. | 10:02.37 |
| | _ingsoc: still haven't convinced it to work locally though. | 10:02.57 |
| _ingsoc | Ah, that was my next question. :P | 10:03.09 |
| sebras | _ingsoc: got it. | 10:04.50 |
| _ingsoc | sebras: Nice. :D What did you do? | 10:06.12 |
| sebras | _ingsoc: http://pastebin.com/RdzNXYzS | 10:07.33 |
| | _ingsoc: my mistake was to expect that xmu was implicitly included when asking for x11 in the makefile. :) | 10:08.05 |
| | _ingsoc: now you should be able to paste using ctrl-v in the other app. | 10:08.24 |
| | and highlighting ought not to add anything to the clipboard if you disable autocutsel. | 10:08.59 |
| _ingsoc | Hmm, alright, let me go through this. I'm a bit slow when it comes to diff. :P | 10:10.14 |
| | Okay, I think I follow what you've done. Is there any way to apply this patch if I want to keep on tracking the git version? | 10:12.10 |
| sebras | _ingsoc: oh. let me know if I can help you ought. | 10:12.12 |
| | ought -> out. | 10:12.28 |
| | well, you can have a local branch that you rebase on top of origin/master. | 10:12.58 |
| | that's probably what I would do myself. | 10:13.12 |
| _ingsoc | How do I set up a local brach? | 10:13.23 |
| | branch* | 10:13.27 |
| | Sorry about the newbie questions. :) | 10:15.14 |
| sebras | so today you do git pull and then make | 10:17.22 |
| | what you could do (instead of creating a local branch and rebasing this on top of origin/master) is of course to simply apply the patch by cat /tmp/clipboard-patch.diff | patch -p1 before make. | 10:18.04 |
| _ingsoc | Yup, I do: git pull ; git submodule init ; git submodule update. | 10:18.08 |
| sebras | the next time, beforce you do git pull though, you need to remove the patch by git reset --hard HEAD. | 10:18.52 |
| _ingsoc | So what would clipboard-path.diff look like? | 10:19.32 |
| | patch* | 10:19.37 |
| sebras | _ingsoc: that's the patch over at pastebin.com | 10:20.42 |
| | _ingsoc: if you want I can teach you a bit about git branching, but I'll do that privately so as not to pollute #ghostscript too much. | 10:21.09 |
| _ingsoc | sebras: That's really nice. Thank you. :D I'd appreciate it. | 10:21.33 |
| sebras | tor8: what is your intent with regards to XA_PRIMARY/XA_CLIPBOARD()..? | 10:56.52 |
| | tor8: I guess since mupdf has not proper Copy-action then we really ought to stay with XA_PRIMARY by default. how about adding a commmand-line option for using XA_CLIPBOARD() instead? | 10:57.47 |
| Wrzlprmft | Hello. I am failing to find, how to set keys of encoders, as documented here: http://ghostscript.com/doc/current/Language.htm (I am using the command line interface) | 13:24.51 |
| henrys | Wrzlprmft: probably best to report a bug at bugs.ghostscript.com - with a description of what you are trying to do, your code and how you are running ghostscript (command line) | 14:36.41 |
| Wrzlprmft | Really? So far I have not encountered any bug, but only failed to find syntax documentation | 14:38.50 |
| henrys | Wrzlprmft: I was imagining you had a significant code fragment that needed to be examined. | 14:42.16 |
| | Wrzlprmft: specifics? | 14:44.19 |
| Wrzlprmft | All I want to do is to set the »Predictor« parameter for the »PNGPredictorEncode« filter for PDFs, but I fail to find, how. | 14:44.30 |
| | (minimal example: gs -sDEVICE=pdfwrite -dAutoFilterColorImages=false -dColorImageFilter=/PNGPredictorEncode -sOutputFile=x.pdf y.pdf) | 14:46.11 |
| henrys | best to wait around for the pdfwrite guru kens, if you come back monday at this time he'll be here or post your question on gs stackoverflow | 14:53.46 |
| | I don't see anything particularly wrong with what you are doing ⦠I know that doesn't get a lot of testing so it might be broken. | 14:55.20 |
| Wrzlprmft | just to clarify: In the above example nothing fails. I just want to set the Predictor option, but all I have come up with so far, either does nothing or produces a syntax error | 14:56.40 |
| henrys | I am not following: you use your command line, have a program with a PNG stream and it does what is expected or it's a bug. We really need something concrete to look at or we can't help. | 15:04.50 |
| | sorry have a program that is supposed to produce a PNG stream in the output pdf with the predictor. | 15:06.08 |
| Wrzlprmft | hmm, since I also fail to see the source of the misunderstanding, let me rephrase the question: How do I set the »Predictor« parameter for the »PNGPredictorEncode« filter for PDF output? | 15:14.15 |
| henrys | oh now I see | 15:15.41 |
| | I don't see a way to set that from the command line in the documentation for pdfwrite, You can certainly write a postscript program to implement a png filter with a specific predictor but it isn't clear how to push that through the command line. -c does allow executing arbitrary postscript on the command line but I'm not sure if that will help. kens or alexcher might be able to help or stack overflow. | 15:24.18 |
| | sorry I couldn't be of more help | 15:24.43 |
| Wrzlprmft | ok, thank you anyway | 15:25.58 |
| | Forward 1 day (to 2013/03/03)>>> | |
IRC Logs
