| | <<<Back 1 day (to 2013/08/28) | 2013/08/29 |
| Guest29405 | oh when i add the first and last page num is everything work good | 00:00.57 |
| | thanks | 00:00.58 |
| MaDog | hi | 07:02.58 |
| ghostbot | moin moin | 07:02.58 |
| Guest74348 | when i converting a pdf with -sDEVICE=pxlcolor to pcl the characters gone wrong | 07:04.08 |
| kens | In what sense 'gone wrong' ? | 07:04.30 |
| Guest74348 | but when i use -sDEVICE=djet500c or cljet5c all the characters good | 07:04.45 |
| | slide and not alphabet chars appear | 07:07.16 |
| kens | ghostbot : your best bet will be to file a bug report at http://bugs.ghostscript.com, please attach the offending PDF file to the report. | 07:08.07 |
| | Oops sorry I meant Guest74348 | 07:08.16 |
| Guest74348 | later i will becouse this pdf is not allowd outside | 07:09.21 |
| | so i create other pdf where the problem is same | 07:09.40 |
| kens | That's the best idea. | 07:09.54 |
| tor7 | Robin_Watts: ping | 09:44.02 |
| Robin_Watts | pong | 09:44.14 |
| tor7 | somehow I suspect our documentation for fz_matrix is wrong | 09:44.31 |
| | or we've flipped all matrix * vector multiplications | 09:44.45 |
| Robin_Watts | ? | 09:44.55 |
| tor7 | opengl uses column major matrices, and the transform is: transformed_point = matrix * input_point | 09:45.18 |
| | converting our supposedly row-major matrix into column-major (transpose) and uploading to opengl behaves like it has been transposed... | 09:45.46 |
| | it's had me confused for quite some time, but now that I've figured it out, everything works :) | 09:46.29 |
| Robin_Watts | We use: | 09:46.47 |
| | (x y 1)(a b 0) = (ax+cy+e bx+dy+f 1) | 09:47.42 |
| | (c d 0) | 09:47.44 |
| | (e f 1) | 09:47.46 |
| | So we use row major vectors. | 09:48.29 |
| | http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-4-geometry/conventions-again-row-major-vs-column-major-vector/ | 09:50.02 |
| | Having said yesterday that I don't have a problem getting out running, I seem to have knackered my back, so I'll not be going today. | 09:51.44 |
| kens | chrisl ping | 09:55.32 |
| chrisl | kens: pong | 09:56.55 |
| kens | chrisl what version of gcc are you running ? | 09:57.08 |
| chrisl | 4.7.2 | 09:57.28 |
| kens | THat's close. Can | 09:57.36 |
| tkamppeter | chrisl, hi | 09:57.43 |
| kens | Can you try running annots.pdf thourgh ps2write please ? | 09:57.57 |
| | And tehn use GS to view page 1 | 09:58.05 |
| | chrisl this is bug #694544 | 09:58.26 |
| tor7 | Robin_Watts: two wrongs don't make a right... | 09:58.38 |
| | I'm having a bit of a /facepalm moment here | 09:58.51 |
| tkamppeter | chrisl, I switched back to built-in openjpeg, as I did not get it working with the system's library (GS simply built without openjpeg, without reporting any error). | 09:58.53 |
| Robin_Watts | tor7: Matrix Multiplication was invented to create facepalms :) | 09:59.12 |
| tor7 | I need to convert from row-major to column-major (transpose) and then upload as column-major (which means I have to transpose back again).... | 09:59.39 |
| chrisl | tkamppeter: it might fallback to Jasper, or might just disable JPX, I can't remember off the top of my head. | 09:59.47 |
| | kens: any specific version of gs I should try? | 09:59.57 |
| tor7 | so uploading the row-major data just automatically converts it to column major, if I don't touch it. | 10:00.13 |
| | bloody hell... | 10:00.17 |
| kens | chrisl well he's using 9.06 bt I'mmore concerned it might be a gcc problem, in which cas e any version will be fine | 10:00.22 |
| tor7 | Robin_Watts: alright, now everything appears where it should at least, whether I transform manually or let opengl do part of the transforms | 10:00.51 |
| tkamppeter | chrisl, seems that openjpeg is od a rather bad coding quality: https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/711061, especially comment #19. Are the enhancements of the GS developers (which upstream is ignoring/rejecting?) fixing these problems? | 10:00.58 |
| kens | tkamppeter : the 2.0 patches have not yet been submitted upstream I was incorrect in that. The developer is waiting until we adopt them ourselves I believe (at least the ones relating to GS code anyway) | 10:02.17 |
| | I think a lot of the criticisms in comment #19 are irrelvant to its use in Ghostscript | 10:03.12 |
| chrisl | kens, tkamppeter: actually, he's waiting for responses (of any kind!) from the openjpeg devs..... they've gone dark again :-( | 10:03.14 |
| kens | tkamppeter : when it comes to JPEG2000 support we have a choice of JasPer or OpenJPEG. JasPer is terribly badly written, deos not support all features, and is no longer maintained. OpenJPEG may nopt be ideal, but we htink its better than JasPer on all points. | 10:04.54 |
| chrisl | kens: so, what am I looking for in the annots.pdf output? | 10:05.53 |
| kens | look at page 1, if its wrong thewre will be big diagonal lines, and the texxt will be (obviously) misplaced | 10:06.21 |
| chrisl | No, it looks fine here | 10:06.39 |
| | I have a SOlaris 10 VM, I guess I can try it there | 10:07.13 |
| kens | OK so its (probably) not the compiler. I'm out of ideas then and he's using Solaris so I can't run it.I'll tell him to try without shared libraries and see what happens. I'm suspicious he's running this on two different machines and there is some difference in (eg) the fonts which is causing the problem. | 10:07.50 |
| chrisl | tkamppeter: henrys has already suggested we "really" fork openjpeg for our use, since the project seems decidedly moribund now :-( | 10:08.59 |
| kens | is disappointed to hear that | 10:09.13 |
| chrisl | Well, I think Shelly's been waiting ~3 weeks for a reply to a simple question, and not even had an acknowledgement from the dev team | 10:10.17 |
| kens | Great, 2 open source implementations, both dead :-( | 10:10.37 |
| chrisl | I still have the feeling that OPJPG devs had their own requirements, and once those were met, they've backed off. I could wrong though | 10:11.45 |
| tkamppeter | chrisl, so I think, to get solid JPEG2000 support into Linux/free software it would be really the best if Artifex forks libopenjpeg and makes it available as separate free software project. | 10:14.41 |
| kens | Umm, I'm not sure we have the resources to support a 'proper' OpenJPEG library | 10:15.21 |
| chrisl | tkamppeter: the trouble is it's a *lot* of work..... | 10:15.44 |
| | tkamppeter: we might be able to "manage" the project, host the repo etc, but the development load would probably be more that we could handle | 10:17.07 |
| Robin_Watts | wants to talk about forking lcms at the next staff meeting. | 10:24.05 |
| chrisl | Oh god :-( | 10:24.23 |
| Robin_Watts | Has Miles said where we are staying in Chicago? | 10:27.35 |
| chrisl | I don't think so | 10:27.46 |
| Robin_Watts | Chicago O'Hare Airport Sheraton | 10:27.58 |
| chrisl | Oh, when did he send that? | 10:28.09 |
| Robin_Watts | according to his mail of 10 July. | 10:28.10 |
| chrisl | That was like two releases ago, no wonder I've forgotten..... ;-) | 10:28.39 |
| | kens: it's not clear to me whether that guy is complaining that the gcc 4.7.3 build output is wrong, or the 4.6.1 | 10:30.23 |
| kens | I believe the 4.7.3 | 10:30.39 |
| Robin_Watts | 6501 N. Mannheim Rd. · Rosemont, IL 60018 · United States | 10:30.47 |
| kens | but yes I agree | 10:30.51 |
| chrisl | Well, he says himself if he builds with no difference but the compiler he still sees the problem - really points at the compiler..... | 10:31.53 |
| kens | He says he has also systemlibrary diffs, but then talks about changing the path,.I'd rather he used our library code | 10:32.29 |
| chrisl | Yeh, but we always use some system libraries | 10:32.58 |
| kens | Not zlib, libtiff etc | 10:33.09 |
| | door, brb | 10:33.36 |
| chrisl | Not sure, zlib, freetype can be pulled in by X, don't know about libtiff | 10:33.49 |
| kens | Maybe I misunderstood him, I htought he was building GS without using our 3rd party library sources. | 10:34.48 |
| | that is, using system shared libraries. | 10:35.02 |
| chrisl | Possibly, again, that's not entirely clear. | 10:35.17 |
| | If he is, then close the bug unless he can reproduce using our versions | 10:35.43 |
| kens | Well that's why I asked him to do that :-) | 10:35.54 |
| | Well I can't find out who he works for, but he opens a lot of bugs | 10:38.39 |
| | OK he works for CSIS in Denmark | 10:39.38 |
| | Or if its not him its someone awfully like him | 10:39.57 |
| chrisl | Hmm, well, my Solaris VM doesn't have gcc, gmake or a raft of other stuff, so I'm not going any further unless I have to..... | 10:43.08 |
| kens | free user, unsupported platfrom..... | 10:44.37 |
| Robin_Watts | tor7: ok, I'm happy with my tests. The RLE and the subpix stuff is good to go as soon as you're happy with it. | 10:44.45 |
| chrisl | kens: Solaris is a supported platform...... | 10:45.45 |
| kens | It is ? oh | 10:45.56 |
| | just as well you have one then | 10:46.28 |
| chrisl | We have "real" customers using it..... | 10:46.29 |
| tkamppeter | chrisl, kens, seems that openjpeg is still alive, see http://code.google.com/p/openjpeg/source/list, perhaps the developer team changed? | 10:47.24 |
| chrisl | tkamppeter: no *code* changed since March? Not exactly active...... | 10:48.45 |
| kens | w4 changes in last 5 months :-( none of them code, as you say | 10:49.43 |
| paulgardiner | Robin_Watts: thanks for pushing my logo commit... assuming I didn't push it myself and then forget. | 11:05.12 |
| Robin_Watts | I thought you pushed it? :) | 11:05.26 |
| | no, was me I think. | 11:05.46 |
| paulgardiner | I don't think I can have. My local master was in the wrong place | 11:05.53 |
| Robin_Watts | At least the commit mail came back as being from me. | 11:05.53 |
| mvrhel_laptop | Hi Robin_Watts | 11:39.23 |
| Robin_Watts | mvrhel_laptop: Morning | 11:39.45 |
| mvrhel_laptop | no. It is bed time | 11:39.54 |
| | still in Japan | 11:40.00 |
| Robin_Watts | Time is relative, lunchtime doubly so. | 11:40.08 |
| | how's it been going? | 11:40.26 |
| mvrhel_laptop | does the Conexant chip have a part number on it? Similar to any of the ones listed here http://www.conexant.com/Product/MFP/Pages/default.aspx | 11:40.41 |
| | Robin_Watts: it has been going quite well | 11:40.56 |
| Robin_Watts | mvrhel_laptop: I sent a mail this morning. | 11:42.04 |
| | the chip says: DC7350. | 11:42.11 |
| | The board says "Falcon DC7350 EVK" | 11:42.26 |
| mvrhel_laptop | ok. I see | 11:42.34 |
| | all right then. thanks. I may bug you about a few more things later on this. | 11:43.34 |
| | but heading to bed now | 11:43.42 |
| | leaving tomorrow afternoon | 11:43.49 |
| Robin_Watts | ok. have a good one. | 11:43.55 |
| mvrhel_laptop | oh. I do have a fix for the color space polarity by the way | 11:44.22 |
| | I keep meaning to push it to test. but had not had a chance | 11:44.43 |
| Robin_Watts | mvrhel_laptop: Oh, fab. thanks. no hurry. feel free to mail me the patch if that's easier. | 11:45.01 |
| mvrhel_laptop | ok thanks | 11:45.11 |
| | good night | 11:45.23 |
| Robin_Watts | night | 11:45.52 |
| | OOOOh! The sequel to "the passage" is out. | 11:48.18 |
| | kens: No, that code is wrong. | 12:08.48 |
| kens | Robin_Watts: are you sure ? It looks OK to me | 12:09.00 |
| Robin_Watts | + is not a sequence point. | 12:09.05 |
| kens | which + ? | 12:09.13 |
| Robin_Watts | a + b does not guarantee whether a will be evaluated before b. | 12:09.28 |
| kens | That's not the query | 12:09.37 |
| | They are (I believe) commentingont he multyiple use of ++ in asingle statement | 12:09.54 |
| Robin_Watts | That's exactly the query. | 12:09.54 |
| | Indeed. | 12:09.58 |
| | The statement is cmyk = ( A + B + C + (Q/2)) / Q | 12:10.41 |
| | where A B and C all include pmyk++ | 12:10.53 |
| kens | yes | 12:10.59 |
| Robin_Watts | where A B and C all include pcmyk++ | 12:11.01 |
| | and there is no guarantee what order A B and C will be calculated in. | 12:11.14 |
| | hence the pointer derefs/increments can all happen in the wrong order. | 12:11.41 |
| kens | Hmmm. THat's a new one on me | 12:11.52 |
| Robin_Watts | hence far from reading R G and B, we might read B G and R. | 12:12.04 |
| kens | Well, if you agree its wrong, go ahead and fix it. | 12:12.16 |
| Robin_Watts | I will. | 12:12.20 |
| kens | suspects there are a number of similar cases sprinkled through GS | 12:13.34 |
| at_earth | hi | 12:16.19 |
| | i want to use mupdf library | 12:16.37 |
| | and i want to create image from pdf page | 12:16.53 |
| Robin_Watts | at_earth: A man of taste and refinement. | 12:17.01 |
| at_earth | but i am facing a problem | 12:17.23 |
| | using jni | 12:17.33 |
| | hi robin | 12:17.44 |
| | when i use the mupdf from another package its native function can not perform well ?am i mistaken in the code .Or give me some tips how to use native methods of mupdf library outside the packages.plzz | 12:22.27 |
| tor7 | Robin_Watts: considering how often we get these requests ... I think making some "proper" jni bindings to expose the library functions (without being tied to android stuff) ought to be rather high on our list of priorities | 12:23.53 |
| Robin_Watts | tor7: Yes, we ought to do proper jni bindings. | 12:24.27 |
| | It's on my todo list, but I keep getting other things get in the way. | 12:24.39 |
| at_earth | so how do i proceed? | 12:24.58 |
| | any pointers? | 12:25.01 |
| tor7 | Robin_Watts: the opengl driver just got to the point where it's actually relatively usable :) | 12:25.31 |
| | it doesn't do clipping properly, that's the main issue I'll have to grapple with | 12:25.51 |
| sebras | Robin_Watts: tor7: wouldn't a jni binding like this mean making it easier to accidentally do aggregates with mupdf which may not be in accordance with gpl..? | 12:26.43 |
| Robin_Watts | at_earth: Not really. What problem are you having? | 12:26.52 |
| sebras | not that you shouldn't do it of course. but it might we worth thinking bout. | 12:27.08 |
| Robin_Watts | Is it a specific mupdf problem, or just a lack of experience with C or JNI? | 12:27.10 |
| | sebras: I think calling via JNI constitutes linking. | 12:27.44 |
| at_earth | when i use the native metods from outside the package using object of mupdfcore class its does not give proper function | 12:28.07 |
| tor7 | sebras: the kind of bindings I'm thinking of would be even more useless to the usual set of scum, since it won't provide a complete application they can just rip off | 12:28.28 |
| sebras | Robin_Watts: ah, yes. I read "another package" in the original question as "another app". | 12:28.34 |
| tor7 | but it would mean we should be able to (in theory) do the android app completely in java | 12:28.49 |
| sebras | tor7: mmm, and that's nice. | 12:29.09 |
| Robin_Watts | at_earth: well, the problem is presumably that you're calling the C level API wrongly. | 12:29.22 |
| tor7 | Robin_Watts: okay, your RLE patch is just missing one thing and then it's good to go: | 12:29.28 |
| | Robin_Watts: I want access to the old functions somehow, that return fz_pixmap rather than fz_glyph | 12:29.45 |
| | fz_render_xxx_glyph_as_pixmap or something like that | 12:29.58 |
| | and speaking of names, in order to be compliant with our own naming scheme, that probably ought to be fz_new_glyph (instead of fz_render_glyph... ugh) | 12:30.34 |
| at_earth | sir can u give some tips for using native mathods in my android activty? i am less experience guy in jni | 12:30.39 |
| Robin_Watts | at_earth: How about, you make a list of all the MuPDF C API calls you make, with the arguments that get passed and the return values that get sent back. | 12:31.41 |
| | Then I can tell you if you are calling them correctly or not. | 12:32.02 |
| | I am not a JNI expert either, although I have had success with it in the past. | 12:32.46 |
| at_earth | sir i want to call just two or three native methods ?like drawpage() | 12:33.04 |
| sebras | at_earth: when you try to call it, then what happens? what arguments do you provide to the function? where do you get the arguments from..? | 12:33.45 |
| | at_earth: and most importantly what return value do you get. | 12:34.00 |
| Robin_Watts | at_earth: Well, you'll need to call more than that. You need to make a context, open the document, load a page, then bound the page, then make a pixmap, then run the page, etc. | 12:34.12 |
| | You might choose to wrap several of those calls up together within a single JNI call. | 12:34.34 |
| at_earth | the argument is passed are hardcore it return type is void | 12:34.50 |
| sebras | Robin_Watts: do you think the simple example in doc/*.c might be helpful in the context of JNI? | 12:34.50 |
| Robin_Watts | but *I* need to know that C level MuPDF API calls you actually make. | 12:34.52 |
| | sebras: Indeed, and I've pointed at_earth at that before I believe. | 12:35.14 |
| at_earth | yes | 12:36.05 |
| sebras | at_earth: have you read it..? | 12:36.13 |
| at_earth | yes | 12:36.18 |
| Robin_Watts | at_earth: Are you following the same scheme? | 12:36.42 |
| | i.e. are you calling the same API functions in the same order? | 12:36.55 |
| at_earth | but i want to use the functionality of drawpage in my activity | 12:36.56 |
| | the functionality of drawpge is useful for me | 12:37.14 |
| sebras | at_earth: drawpage() is not part of the API exposed in JNI though. | 12:37.28 |
| | at_eart drawpage() is a function inside the mudraw tool which is not included in the android stuff IIRC. | 12:38.01 |
| Robin_Watts | at_earth: docs/example.c shows exactly how to draw a page using the MuPDF C level API. | 12:38.19 |
| at_earth | drawPage() is the native method of MuPdfCore Class | 12:38.21 |
| Robin_Watts | at_earth: MuPDFCore exposes an interface that is JUST enough for our viewer app. | 12:39.01 |
| | You cannot call methods from it in isolation. | 12:39.09 |
| sebras | at_earth: ah, drawPage() is different from drawpage(). :) | 12:39.39 |
| at_earth | yes there are two methods one is user define and other is native | 12:40.15 |
| | in the MuPdfCore class | 12:40.30 |
| | I need the fnctionality in my activity because drawPage() which is native draws pdf page on blank bitmap and i need that bitmap to store in the sd card | 12:42.00 |
| Robin_Watts | at_earth: You are basically asking "how can I change the MuPDF app to allow me to save bitmaps onto the SD card" | 12:43.03 |
| at_earth | no sir | 12:43.25 |
| Robin_Watts | and I'm saying "You can't. The MuPDFCore is designed to run as an interactive viewer. If you want to be able to drive it in a substantially different way, then you need to redo the jni." | 12:44.01 |
| at_earth | i am just asking that can i calls drawpage methods which is native from my activity with the help of mupdfcore class | 12:44.20 |
| Robin_Watts | at_earth: You cannot just pick and choose which MuPDFCore entrypoints you call. | 12:45.33 |
| | You either call all of them in the right order, in the same way that our native app does, or you write your own MuPDFCore equivalent. | 12:46.08 |
| | Essentially to call MuPDF NOT from our viewer app (or something very like it), someone needs to redo the jni bindings. | 12:46.48 |
| | That can be me or paul or tor7 or sebras, or it can be you, it doesn't matter. | 12:47.15 |
| | but I cannot give you a timescale on when me or paul or tor7 or sebras will get around to it. | 12:47.38 |
| at_earth | ok but mupdf is class and class is an anadroid activity its has own functionality i can equivalent the mupdfcore to the my activity | 12:47.48 |
| Robin_Watts | There is an activity, yes. | 12:48.10 |
| | And activities have a set interface, so you can call over that interface. | 12:48.23 |
| at_earth | yes but mupdfcore is class | 12:48.29 |
| Robin_Watts | But MuPDFCore is NOT a public interface. | 12:48.40 |
| | It is a private interface to our own app. | 12:49.03 |
| sebras | at_earth: yes, but the mupdfcore class is written to be used by the mupdf android app. It was never designed to be called by anyone else. | 12:49.04 |
| Robin_Watts | it has all sorts of sharp edges and undocumented dependencies on the order in which its methods can be called. | 12:49.40 |
| | If you happen to call it in the right way, then it'll work for you. | 12:49.55 |
| | If you skip some steps, or change the orders of things, it will fall in a nasty heap. | 12:50.12 |
| at_earth | i have called the drawPage mathod get the image bit the image is blank and when i save tha image from mupdf activity packages it perform well | 12:50.23 |
| Robin_Watts | at_earth: Then (at a guess) you're probably setting the page transform up wrong, or the clipping rectangle or something. | 12:52.01 |
| at_earth | may be but i did not change the drawpage() code i am just passing the hard core parameter in the methods | 12:53.06 |
| | the parameter i get from the debugger from the mupdf activity | 12:53.48 |
| | can i send u my android activty | 12:54.11 |
| Robin_Watts | no. | 12:54.16 |
| | Sorry, but I am not going debugging through someone elses code. | 12:54.34 |
| | I've offered to look at the mupdf api calls you make if you extract me a list of them with arguments etc, but I am not diving into someone elses java code. | 12:55.30 |
| | lunchtime | 12:55.44 |
| at_earth | ok sir | 12:55.48 |
| sebras | at_earth: until mupdf has a public interface (with documentation) that is meant to be used by android apps such as yours you will have to be patient and wait for it. if you can not wait then I think you need to expect to have to test and try how to use the interface yourself a lot. also the interface you are using now may be changed significantly tomorrow, so you need to expect that too. | 12:57.17 |
| at_earth | sure , thanks | 12:57.51 |
| sebras | at_earth: if one of the mupdf devs have spare time then they might help you. | 12:57.53 |
| at_earth | appreciate thanks | 12:58.05 |
| | preparing the list .. may be some quick finds can be pointed out | 12:58.25 |
| sebras | at_earth: if you work for a company then your company could try to negotiate with Artifex (where mupdf devs work) to accelerate the development of the public JNI interface. | 13:01.33 |
| kens | chrisl ping | 13:03.01 |
| chrisl | kens: pong | 13:04.38 |
| kens | bug 694544 | 13:04.59 |
| | are you in a position to try gcc 4.7.3 ? | 13:05.29 |
| chrisl | I probably could on Linux, Solaris a different ball game at the moment | 13:06.06 |
| kens | Solaris I'm not worried about, but a bug like that in the Linux version would be a problem I think. I haven' looked at the ascii85encode filter code, butits hard to see how it could cause this problem. | 13:06.54 |
| chrisl | I'll kick off a gcc build once I remember all the parameters I need to set...... | 13:07.44 |
| kens | THe ascii85encode is in ssfilter2.c, I'm just looking at it quickly now | 13:08.01 |
| | There's a horrible nested ?: construction that looks prone to failure. | 13:09.21 |
| | Can't see anything else likely. | 13:11.42 |
| chrisl | kens: gcc 4.7.3 is building now - fingers crossed..... | 13:14.15 |
| kens | OK thanks chrisl | 13:14.21 |
| kens | wonders if everyone has suddenly come back from holiday at the same time | 13:14.40 |
| chrisl | Does rather feel like that :-( | 13:14.56 |
| Robin_Watts | tor7: fz_render_glyph is not really part of the API, hence I don't feel it needs to be fz_new_render_glyph | 13:41.25 |
| | how about fz_render_glyph_pixmap as a name for the function you want? | 13:41.48 |
| chrisl | kens: I don't see any issues with gcc 4.7.3 on Linux | 13:47.26 |
| kens | chrisl OK thanks, I will close the Solaris one as 'worksforme' then, until a customer wants to use gcc 4.7.3 on SOlaris. Myabe the reporter will raise a bug vs gcc. | 13:48.11 |
| tor7 | Robin_Watts: yeah, that name's good | 13:48.28 |
| Robin_Watts | tor7: How would you feel about getting an fz_glyph back? | 13:48.56 |
| | but just knowing that RLE wouldn't be used, and it was in glyph->pixmap ? | 13:49.18 |
| | The alternative is to have to clone lots of code, I think. | 13:49.46 |
| kens | Ah, I see the PDFA/2 report is from osmeone working for "specialists in automatic Classification of unstructured data and enterprise-wide Archiving (Unified Archiving)." Look like freeloaders to me. | 13:50.13 |
| | chrisl which compiler do you normally use on Solaris ? | 13:53.26 |
| tor7 | Robin_Watts: I could work around that (send no-rle flag down) | 13:54.02 |
| chrisl | On SPARC it's gcc, but the Solaris x86 VM I have was a one off install, and it just has the sun cc on it. I don't think I even built gs on it, in the end | 13:54.17 |
| | kens: ^^ | 13:54.21 |
| kens | OK thanks, just want to put it in the bug thread | 13:54.33 |
| tor7 | or the fz_render_glyph_pixmap call could call that, free the glyph and return the pixmap | 13:54.38 |
| Robin_Watts | tor7: yeah, it's not pretty though. thinking about it. | 13:54.47 |
| kens | I guess I'll skip it | 13:54.48 |
| Robin_Watts | tor7: yeah, I'd really rather avoid making a glyph just to free it. | 13:54.59 |
| tkamppeter | chrisl, first bug report (regression against 9.07) on GS 9.10rc1: https://bugs.launchpad.net/bugs/1218350 | 13:55.53 |
| | chrisl, please contact the user if you need more info. | 13:56.31 |
| kens | At least someone tested it. | 13:56.36 |
| tor7 | Robin_Watts: if the glyph could hold non-rle data that'd work too | 13:56.43 |
| | but I guess you need the fz_pixmap for the color cases anyway | 13:56.53 |
| Robin_Watts | tor7: yeah. | 13:56.58 |
| chrisl | tkamppeter: I think the answer is in the error message | 13:57.00 |
| | kens: could you read that report please? | 13:57.12 |
| Robin_Watts | tor7: Ah, I need a glyph in order to be able to able to put things in the glyph cache. | 13:57.21 |
| kens | tkamppeter : the error message does say 'Set UseCIEColor for UseDeviceIndependentColor to work properly', the user *does* need to set -dUseCIEColor in that version of GS. THe odler version silently ignored it and produced incorrect output | 13:57.41 |
| | chrisl ^^ | 13:57.51 |
| chrisl | Thanks | 13:57.59 |
| Robin_Watts | Hence if you want to reuse our cache, I need to use glyphs at least internally. | 13:58.01 |
| tor7 | Robin_Watts: I'm going to be caching these results myself, so there's strictly no need to cache them :) | 13:58.07 |
| Robin_Watts | so I'll code it that way. | 13:58.07 |
| | tor7: oh. rats :) | 13:58.22 |
| | bang goes that excuse then. | 13:58.29 |
| tor7 | I have to copy the pixmaps into a big "atlas" of glyphs that I use as a texture to draw the text | 13:58.44 |
| Robin_Watts | so you want an fz_render_glyph that doesn't do caching ? | 13:59.21 |
| | so you want an fz_render_glyph_pixmap that doesn't do caching ? | 13:59.31 |
| tor7 | but you know what, if I can just get the fz_render_glyph to (a) always return a pixmap, and (b) optionally set it to don't cache, that'd be fine | 13:59.47 |
| | I can deal with having a wrapping fz_glyph struct for either case | 14:00.49 |
| Robin_Watts | tor7: I am tempted to clone the code, into a new file, so that builds without OpenGL support drop the extra code. | 14:01.27 |
| tor7 | currently I call fz_render_ft_glyph / t3_glyph directly in the opengl code | 14:02.00 |
| Robin_Watts | presumably you're having a new draw device, rather than a draw device with if (opengl) etc in it? | 14:02.01 |
| tor7 | can't remember why I bypass fz_render_glyph | 14:02.14 |
| | Robin_Watts: it's a completely new device | 14:02.29 |
| Robin_Watts | right. I'm talking about cloning draw-glyph.c to be draw-glyph-pixmap.c | 14:02.36 |
| tor7 | it still uses the draw device to render type3 glyphs though | 14:02.45 |
| | Robin_Watts: separate the caching from the rendering, in both cases? | 14:03.10 |
| Robin_Watts | tor7: draw-glyph-pixmap.c would have no caching stuff in it. | 14:03.32 |
| tor7 | draw-glyph-pixmap.c draw-glyph-rle.c and draw-glyph-cache.c | 14:03.33 |
| henrys | tor7:shelly was saying the xps fixes are in your local tree, are you going to move them to the master branch? | 14:04.13 |
| Robin_Watts | I'll have to think about if I can extract caching from rendering nicely. | 14:04.28 |
| chrisl | tkamppeter: I have replied on launchpad | 14:05.07 |
| Robin_Watts | The subpix quantisation happens before the caching. and it would still have to happen in the render only case. | 14:05.28 |
| tor7 | Robin_Watts: yes. | 14:09.12 |
| | henrys: I will, just want to test them first. what's the magic command to cluster test ghostpdl xps changes again? it's been a while.... | 14:09.43 |
| Robin_Watts | tor7: git cluster xps | 14:10.53 |
| henrys | shelly has cluster access and should have done it. | 14:10.58 |
| Robin_Watts | or: clusterpush.pl xps | 14:11.01 |
| henrys | he usually does anyway. | 14:11.28 |
| tor7 | henrys: if he has commit access, he could just pull and push the commits himself? | 14:11.46 |
| henrys | tor7:yes, I assumed they were in your tree waiting for your review. I don't have all the details of how this evolved. | 14:12.24 |
| | if so you're happy with him say please commit to main and goto henry for bounty stuff. | 14:13.18 |
| tor7 | henrys: he attached patches to bugzilla, I reviewed (fixed up) and committed to a git branch | 14:13.22 |
| kens | henrys, shelly was saying there are a bunch of OpenJPEG related patches which need an (possibly your) OK to commit | 14:14.33 |
| henrys | tor7:okay so comment on the bug he should review your changes and commit to master. | 14:14.44 |
| | kens:yes thank you, that's on my list too. | 14:15.04 |
| kens | Thanks henrys, I promised shelly I'd ping you about it | 14:15.19 |
| henrys | tor7:I don't want to pay folks until it goes to master. | 14:15.57 |
| kens | tries to remember what he was doing in pdf_ops.ps this morning.... | 14:16.27 |
| henrys | kens:crying ;-) | 14:16.42 |
| tor7 | henrys: okay. how many bounties are you paying out for these fixes? | 14:17.01 |
| Robin_Watts | tor7: There are "interesting" locking issues with type3 glyphs normally. | 14:18.17 |
| henrys | it looked like 3 p4 (1500) to me but I might change my mind when I see them all go into master at once. tor7, reasonable? | 14:18.47 |
| tor7 | henrys: they're all simple one liner fixes; go ahead and look over them yourself to judge the amount of work. | 14:19.27 |
| Robin_Watts | When we call fz_render_glyph we take the glyphcache lock. We then check for the presence of the glyph we need within the cache. If it's there we unlock and return. If not, we have to render it. But we can't render with the lock taken as the type3 content stream may call other font methods. | 14:19.32 |
| tor7 | Robin_Watts: yeah, I've seen the lock dancing in there... it's tricky. | 14:19.59 |
| Robin_Watts | so we have to drop the lock, render the glyph, then retake the lock - this opens up the possibility of someone else having rendered the same glyph in the meantime. So we have to check for that. | 14:20.11 |
| | You'll need to be doing the same dance in your own code. | 14:20.24 |
| henrys | tor7:then it sounds more like 1 P4, I haven't looked at the code just the problem descriptions. | 14:21.04 |
| | Robin_Watts:are we committing openjpeg stuff to mupdf and not to gs? I was reading the logs. | 14:30.03 |
| Robin_Watts | henrys: You mean zenikos fixes that went in yesterday? | 14:30.34 |
| henrys | yes | 14:30.51 |
| Robin_Watts | Those were all changes within mupdf. | 14:30.59 |
| henrys | okay, were that raised the problems checked against gs. | 14:31.31 |
| | ? | 14:31.32 |
| | were the files that raised... | 14:31.47 |
| Robin_Watts | I don't know. | 14:32.06 |
| henrys | okay I'll look | 14:32.17 |
| | thanks | 14:32.22 |
| Robin_Watts | sorry, I should have thought to ask. | 14:32.36 |
| | tor7: ping | 14:56.28 |
| | Commit to add pixmap glyph stuff on robin/master | 14:56.44 |
| | currently it's all in the same files - we can split them out in future if we want. | 14:57.05 |
| | It strikes me that when you do caching of glyphs in the opengl, you will want to do the subpixel adjustment stuff before you check for caching. | 14:57.38 |
| | which means that maybe I should spin the subpixel adjustment stuff out as separate functions? | 14:58.00 |
| tkamppeter | kens, thanks. | 14:58.39 |
| kens | tkamppeter : no problem, it really is nice to see people testing | 14:58.51 |
| tkamppeter | kens, chrisl, does this mean that I have to add -dUseCIEColor to all Ghostscript calls with the "pdfwrite" device? Do I also need the same for other devices, like for example "ps2write"? | 15:03.24 |
| kens | tkamppeter : only if you set -dColorConversionStrategy=/UseDeviceIndependentCOlor or a PDFSETTINGS which uses that parameter | 15:04.05 |
| chrisl | tkamppeter: UseCIEColor should definitely *not* be used in the general case | 15:04.46 |
| | <sigh> to build gnu binutils, you need gnu ar available, but ar is part of binutils..... :-( | 15:05.41 |
| kens | Ah, open package using icnluded crowbar | 15:06.19 |
| tkamppeter | chrisl, thanks. | 15:06.41 |
| chrisl | tkamppeter: np | 15:06.57 |
| tkamppeter | kens, chrisl in the pstopdf filter I use BOTH -dPDFSETTINGS=/printer and -dColorConversionStrategy=/LeaveColorUnchanged. Do I need -dUseCIEColor then? | 15:25.11 |
| kens | Yes | 15:25.18 |
| | Err no, sorry, I meisread that | 15:25.32 |
| | With LeaveCOlorUnchanged you should be OK | 15:25.44 |
| tkamppeter | kens, yes, the pstopdf filter keeps working for me. | 15:29.03 |
| kens | OK that's fine then Tillm,you might want to put a comment in just so you know | 15:32.02 |
| Robin_Watts | tor7: ping | 15:34.05 |
| tor7 | Robin_Watts: pong. | 15:35.13 |
| Robin_Watts | tor7: robin/master has a couple of commits on for your consideration. | 15:35.27 |
| | The first adds the pixmap functions. | 15:35.32 |
| | The second exposes the subpixel adjustments. | 15:35.43 |
| | Also, the banding commit on there now uses fz_output *'s etc. | 15:36.06 |
| | I haven't added PNG output yet, but that could come in a later commit. | 15:36.18 |
| tor7 | Robin_Watts: I'll take a look after dinner. | 15:37.31 |
| Robin_Watts | np. | 15:37.36 |
| | thanks. | 15:37.43 |
| tor7 | just one quickie I spotted, fz_new_output_with_filename ... open is one of the magic words so fz_open_output would be fine there | 15:37.57 |
| Robin_Watts | tor7: we have fz_new_output_with_file and fz_new_output_with_buffer | 15:38.29 |
| tor7 | I'd prefer if you split the fz_output stuff from the banding commit into a separate commit | 15:38.31 |
| Robin_Watts | I thought with_filename was more in keeping. | 15:38.48 |
| tor7 | Robin_Watts: right. hm. don't we have open_buffer_with_memory etc? or is that new_buffer_with? | 15:39.00 |
| Robin_Watts | The fz_putc changes ? | 15:39.12 |
| tor7 | ehm, s/buffer/stream/ | 15:39.13 |
| | yeah. and the function we were just discussing the name of. | 15:39.34 |
| Robin_Watts | fz_open_compressed_buffer | 15:39.47 |
| | fz_open_image_decomp_stream | 15:39.51 |
| | Those return fz_streams. | 15:40.00 |
| | other that fz_open_document and fz_open_document_with_stream, I think fz_open_... always return fz_streams. | 15:40.38 |
| | fz_outputs are always made by fz_new_output_.... | 15:41.18 |
| paulgardiner | Robin_Watts, tor7: little commit on paul/master - making the pdf device produce more efficient appearance streams for text | 15:49.22 |
| Robin_Watts | paulgardiner: Will look in a mo. | 15:49.38 |
| | paulgardiner: That assumes the font is an ft_face | 15:55.29 |
| paulgardiner | Aagh! | 15:56.03 |
| Robin_Watts | I suspect you need an if (font->ft_face) ... in there with the old code. | 15:56.09 |
| paulgardiner | Yeah, that would be safer | 15:56.21 |
| Robin_Watts | Also, could you use TD to be even more efficient? | 15:56.55 |
| | sorry, TJ. | 15:57.36 |
| | Rather than doing: <0123>Tj 10 0 Td <4567>Tj 10 0 Td <8901AB> Tj etc | 15:58.57 |
| | you could do: [<0123>10<4567>10<8901AB>] TJ | 15:59.22 |
| | That does rely on delta.y being 0, but it will be most of the time. | 15:59.45 |
| paulgardiner | Might do that as a separate optimisation | 16:00.19 |
| Robin_Watts | paulgardiner: Sure. | 16:03.09 |
| paulgardiner | Robin_Watts: I've pushed a fix for font not being ft_face. If okay, I'll merge the two together | 16:08.06 |
| Robin_Watts | no, that's no good. | 16:09.21 |
| | fonts can either be handled by freetype or as Type3's. | 16:09.39 |
| | oh, wait... maybe it is OK. | 16:10.28 |
| paulgardiner | Does that matter. | 16:10.30 |
| Robin_Watts | In the font->ft_face == NULL case, will you just do the old style absolute positioning of each char ? | 16:11.00 |
| paulgardiner | Yeah | 16:11.10 |
| sebblonline | hi everybody, hope my question is not misplaced here or to general. Does anybody know about current memory leaks in muPDF? I have serious problems with that. | 16:11.20 |
| paulgardiner | j = i+1, so just one is output | 16:11.23 |
| Robin_Watts | right. That's fine then. | 16:11.34 |
| paulgardiner | Ta | 16:11.37 |
| kens | Robin_Watts : tor7 question from sebblonline above ^^ | 16:16.26 |
| Robin_Watts | sebblonline: Hi | 16:17.14 |
| | As far as we know, it doesn't leak. | 16:17.25 |
| sebblonline | Robin_Watts: hi | 16:17.59 |
| Robin_Watts | Specifically, we have a special lib, called Memento, that tracks memory usage and watches for overruns/underruns/leaks etc. | 16:18.02 |
| sebblonline | ah ok. | 16:18.14 |
| Robin_Watts | I occasionally do a memento build of MuPDF, and run it, and it should give a clean bill of health. | 16:18.30 |
| | That's not to say that we don't sometimes go wrong, but as far as I know, there are no known outstanding leaks. | 16:18.57 |
| | What platform are you working on? | 16:19.02 |
| sebblonline | win7 | 16:19.10 |
| | 32bit | 16:19.12 |
| Robin_Watts | same as me. | 16:19.15 |
| | So, in MSVC, in the dropdown where you can choose between Debug/Release etc, you can also pick Memento. | 16:19.48 |
| sebblonline | i open documents, create several images with fz_pixmap... und afterwards close everything (hopefully) correctly. | 16:19.49 |
| | yeah, I have seen it, but ignored it up to now ;) | 16:20.12 |
| | I will try that | 16:20.23 |
| Robin_Watts | sebblonline: ok, give Memento a whirl and see what happens. | 16:20.26 |
| | Are you writing a console app, or a windows app ? | 16:20.42 |
| sebblonline | windows App. I render the images to Qt QImages | 16:21.17 |
| Robin_Watts | Memento outputs to stderr, so for a console app you'll see the results. For a windows app, you may need to tweak stuff. | 16:21.18 |
| | Ah, it looks like memento messages should appear in the debugger output window now too. | 16:22.14 |
| sebblonline | but stderr should work to when using visual studio? | 16:22.21 |
| Robin_Watts | You will see the output in Visual Studio, but not thanks to stderr. | 16:22.47 |
| | It would be FAR too sensible for MS to arrange that stderr should be displayed in a debugger. That'd be madness. | 16:23.06 |
| | Far better to let it all trickle off into a bitbucket somewhere. | 16:23.17 |
| kens | You wnat stderr ?WHat are you, some kind of pinkko commie Linux user ? | 16:24.40 |
| sebras | kens: time for a cup of coffee? ;) | 16:26.05 |
| Robin_Watts | sebras: No, he doesn't need *more* caffiene :) | 16:26.30 |
| kens | Packing up time :-) | 16:26.33 |
| sebras | kens: mmm, I realized. :) | 16:26.40 |
| | Robin_Watts: would be fun so what gets written with more caffeine though. | 16:27.10 |
| | s/so/to see/ | 16:27.17 |
| sebblonline | ok, cant see stderr of memento build :( | 16:28.15 |
| kens | my typing doesn't get any better, I cna tell you that.... | 16:28.17 |
| Robin_Watts | sebblonline: Let me do a check here. | 16:29.12 |
| ray_laptop | Robin_Watts: I think on the debugger arguments line you can specify 2> stderr.log -- I used to do this. I can't try right now since I am in the middle of making changes and can't build this second | 16:29.27 |
| Robin_Watts | ray_laptop: Right, but you can't then read that as the program runs :( | 16:30.20 |
| kens | I thnk you need &2> or something | 16:30.22 |
| Robin_Watts | sebblonline: It's working for me. | 16:30.28 |
| ray_laptop | Robin_Watts: I set up (in an msysgit shell) tail -f stderr.log | 16:30.54 |
| | works like a champ | 16:31.07 |
| | I had the same issue with cust 532's app and stderr | 16:31.25 |
| Robin_Watts | sebblonline: So, this is an app of your own? | 16:31.29 |
| kens | agrees with Robin_Watts the debugger shold do this for you | 16:32.00 |
| Robin_Watts | ray_laptop: I didn't realise that redirection worked as part of the debugger setup. Good if it does, but why don't they do it by default? | 16:32.19 |
| ray_laptop | the shell script (I think is works in cmd.exe as well) for combining stderr on to stdout is 2>&1 | 16:32.32 |
| | but I don't know if that works or not. | 16:32.54 |
| | Robin_Watts: I don't know why it isn't the default, since it is the default when running console apps under cmd.exe | 16:33.53 |
| | (both stderr and stdout are both shown on the console window) | 16:34.26 |
| sebblonline | i have own apps, but I also experiment with the example mupdf win32 app included in the lib | 16:34.48 |
| | tried 2>&1, but i cant see anything in output | 16:37.09 |
| Robin_Watts | sebblonline: If Memento doesn't find any leaks, it doesn't print anything. | 16:37.53 |
| | try breakpointing Memento_breakpoint and Memento_inited | 16:38.06 |
| | Then run it. | 16:38.11 |
| kens | sebblonline : just to aska dumb question. you are using up to date checkout of MuPDF ? | 16:38.33 |
| sebblonline | no sorry, version 1.2 | 16:38.52 |
| Robin_Watts | ah. 1.2 doesn't go to the debugger. | 16:39.19 |
| sebblonline | I will try 1.3 tomorrow - have to go now | 16:39.25 |
| | ah, ok thanks! | 16:39.29 |
| | then it could not work :) | 16:39.45 |
| | thanks a lot for all that info | 16:39.54 |
| | cya | 16:40.35 |
| ray_laptop | Robin_Watts: BTW, I just tried the 2> stderr.log and it works. | 16:53.19 |
| Robin_Watts | ray_laptop: Thanks. | 16:53.30 |
| | I think the warnings stuff is broken at the moment. | 16:54.16 |
| ray_laptop | Robin_Watts: 2>&1 seems to work as well (to combine stderr on to stdout) | 17:00.47 |
| Robin_Watts | ray_laptop: Does that work for windows apps as well as console ones? | 17:33.24 |
| | gswin32.exe as well as gswin32c.exe for example ? | 17:33.40 |
| | hmm gswin32.exe is a bad example. | 17:34.41 |
| | mupdf.exe as well as mudraw.exe | 17:34.49 |
| | tor7: banding and output changes split out. | 17:40.38 |
| | actually, I'm working on the banding stuff again now. | 18:03.21 |
| | tor7: Bugger. | 18:33.16 |
| | For PNGs, I can have multiple IDAT chunks, but the contents of all the IDAT chunks have to be one zlib stream. | 18:33.54 |
| | so I need persistent data across the band writing calls. | 18:34.06 |
| tor7 | Robin_Watts: oh... well then scratch what I said about PNG being simple | 18:58.08 |
| Robin_Watts | I'll have a crack at it tomorrow. Can't face zlib now :) | 18:58.35 |
| | so all the commits on there are ready to go except the banding one. | 18:58.48 |
| | but don't feel you have to look now. | 18:59.02 |
| zeniko | Robin_Watts: henrys: There are still some openjpeg fixes waiting on zeniko/openjpeg for your review and for inclusion into thirdparty/openjpeg (and through shelly into ghostpdl) | 19:05.00 |
| Robin_Watts | zeniko: Hi. I mentioned those 2 bugs to henrys. | 19:05.45 |
| zeniko | henrys: Also, the patches in bugs 694111 and 694121 haven't been merged into ghostpdl yet. | 19:05.59 |
| | Robin_Watts: The two bugs are jbig2dec issues | 19:06.24 |
| Robin_Watts | right. | 19:06.34 |
| | I think you should have commit access to ghostpdl now, right? | 19:06.48 |
| | or would you prefer to steer clear of that? | 19:07.04 |
| zeniko | I'd prefer not risking to muck up ghostpdl given the current state of your release cycle | 19:07.38 |
| Robin_Watts | fair enough. | 19:07.47 |
| | openjpeg and jbig2dec both fall in henrys lap I think now, so he needs to look at those commits and get them in. | 19:08.27 |
| | I'm sure he'll read the logs later, or failing that I'll prod him about it. | 19:08.41 |
| zeniko | even though thirdparty/openjpeg only applies to MuPDF? | 19:09.23 |
| | anyway, the fixes are on the zeniko_fixes branch (currently 7 patches) | 19:09.44 |
| Robin_Watts | We use openjpeg in gs too. | 19:09.55 |
| | so any fixes should go to both, AIUI. | 19:10.07 |
| zeniko | will thirdparty/openjpeg be synchronized with ghostpdl's, once shelly's done integrating (same as jbig2dec)? | 19:10.32 |
| Robin_Watts | zeniko: We'd like the two to be in sync. The mechanics of how that is done is unclear at the moment. | 19:11.17 |
| | mupdf uses openjpeg 2, I'm not sure if gs has moved to 2 yet, but when it does it will probably make sense to sync them up. | 19:11.48 |
| zeniko | it hasn't yet (see bug 694311) | 19:12.11 |
| | would that be the time to suggest to use a submodule inside ghostpdl instead of going the other way around as with jbig2dec? | 19:12.38 |
| sebras | http://www.engadget.com/2013/08/29/samsung-concept-printer-ifa-2013/ I wonder if mupdf will ever support this. | 19:55.13 |
| Robin_Watts | zeniko: For the logs. I don't think we'd succeed in trying to get submodules into gs. | 22:58.25 |
| | Forward 1 day (to 2013/08/30)>>> | |
IRC Logs