| | <<<Back 1 day (to 2014/02/16) | 2014/02/17 |
| Raymond_ | Hello | 10:31.16 |
| chrisl | Hi | 10:31.25 |
| Raymond_ | void fz_write_jpg(fz_context *ctx, fz_pixmap *pixmap,int n, int depth, char *filename, int quality){ struct jpeg_compress_struct cinfo; struct jpeg_error_mgr jerr; /* More stuff */ FILE * outfile;/* target file */ int row_stride;/* physical row width in image buffer */ JSAMPROW row_pointer[1]; cinfo.err = jpeg_std_error(&jerr); jpeg_create_compress(&cinfo); if ((outfile = fopen(filename, "wb")) == NULL) { | 10:31.41 |
| Robin_Watts | raymond: Don't do large pastes here. Use pastebin, please. | 10:32.13 |
| Raymond_ | I want save a fz_pixmap object to jpeg, but it's not work... | 10:32.15 |
| | Ok | 10:32.53 |
| | May i ask a question about mupdf? | 10:34.00 |
| Robin_Watts | sure. | 10:34.24 |
| Raymond_ | : ) | 10:34.51 |
| | I 'm trying to save a fz_pixmap object as jpeg file | 10:35.14 |
| | but the result image is not same in pdf.. | 10:36.22 |
| | this is my code http://pastebin.com/g24ek81J | 10:37.52 |
| | very simple | 10:38.04 |
| Robin_Watts | row_stride is wrong. | 10:38.55 |
| | Oh, no, sorry. Presumably you always call with n = 8 ? | 10:39.27 |
| | depth = 8 I mean. | 10:39.37 |
| Raymond_ | n=3 | 10:39.39 |
| | depth=8 | 10:39.44 |
| Robin_Watts | For an rgb image, generally n = 4. | 10:39.58 |
| | because it's rgbargbargba etc. | 10:40.07 |
| | so you'll need to cope with that. | 10:41.03 |
| Raymond_ | what's "image->n" means? | 10:41.28 |
| Robin_Watts | pixmap->n is the number of components. | 10:41.41 |
| | what value are you seeing for pixmap->n ? | 10:41.52 |
| Raymond_ | 3 | 10:41.59 |
| Robin_Watts | oh, ok. Let me think | 10:42.18 |
| | Well, that's very odd. | 10:43.33 |
| | If you look at fz_write_png, that calls fz_output_png_band, and that expects n to be 1,2 or 4. | 10:43.58 |
| | 1 = alpha only, 2 = grey_alpha, 4 = rgb + alpha. | 10:44.14 |
| | Raymond: Does calling fz_write_png get you a valid png ? | 10:46.44 |
| Raymond_ | yes | 10:47.00 |
| Robin_Watts | Then pixmap->n cannot be 3. | 10:47.13 |
| Raymond_ | ok , i debug it now | 10:47.30 |
| sebras | Robin_Watts: can n == 3 if the input is a .png? | 10:48.53 |
| | Robin_Watts: or if the pixmap has been manually created? | 10:49.11 |
| Robin_Watts | How can the input be a png? | 10:49.12 |
| sebras | Robin_Watts: don't we support opening .png files? I though we did. | 10:49.33 |
| Robin_Watts | sebras: They will have n=4 I believe. | 10:49.50 |
| | because the alpha has got to go somewhere. | 10:50.03 |
| sebras | Robin_Watts: it ought to be there, it was just an thought that there might be some strange case where we forget to add alpha. | 10:50.40 |
| Robin_Watts | sebras: everything boils down to fz_new_pixmap_with_data | 10:51.35 |
| | and that takes a colorspace pointer. | 10:51.40 |
| | If the colorspace pointer is null, n=1 | 10:51.46 |
| Raymond_ | yes, pixman->n =4 | 10:51.47 |
| Robin_Watts | otherwise it's colorspace->n+1 | 10:51.55 |
| Raymond_ | and image->n=3 | 10:51.56 |
| Robin_Watts | Raymond_: So there is your problem. | 10:52.00 |
| Raymond_ | Yes | 10:52.28 |
| | Thank you very much | 10:52.41 |
| Robin_Watts | np. | 10:52.59 |
| tkamppeter | Can someone have a look at bug 692626, comment #9, this seems to be spam. I got notifications on 16 bugs in less than a minute, all with this spam message of a Jackie Rosen. | 12:48.40 |
| Robin_Watts | oh, great, bugzilla spam. | 12:49.02 |
| jhabjan | reported bug #692175 - I had a similar problem when I start using GS API in .NET .... so to share my thoughts I posted the solution... | 13:35.25 |
| chrisl | jhabjan: thanks. I suspect, in the absence of further information, we'll probably consider it closed (I'm a little surprised it was still open!) | 13:37.38 |
| jhabjan | n/p | 13:38.12 |
| Robin_Watts | tor8: Is it acceptable to do stroking operations within a BT/ET pair for the purposes of underlining/strikeout/overlining etc? | 14:04.17 |
| tor8 | Robin_Watts: page 197 of pdfref17 | 14:08.55 |
| Robin_Watts | Figure 4.1 ? | 14:09.10 |
| tor8 | Text object, allowed operators: graphics state, color, text state, text showing, text positioning and marked content. | 14:09.19 |
| | so no, you should not be doing any path drawing inside BT/ET | 14:09.33 |
| Robin_Watts | yeah. IME that table is compete and utter bollocks. | 14:09.39 |
| chrisl | What would be the point of BT/ET if you can throw random graphics operations in there, too? | 14:10.06 |
| Robin_Watts | My first PDF parser attempted to enforce that diagram. | 14:10.21 |
| | and nothing rendered. | 14:10.26 |
| tor8 | Robin_Watts: yeah, I don't know any spec that actually follows it... but if we're generating PDF we should, IMO. | 14:10.48 |
| Robin_Watts | ok. | 14:11.00 |
| tor8 | be generous in what you accept, conservative in what you emit, etc etc | 14:11.02 |
| | Robin_Watts: well, I think the only real places where you can go wrong according to that figure, is mixing state setting inside a path construction (which I wasn't even aware was a problem) | 14:12.13 |
| | and BT/ET which is clearly marked as an object | 14:12.33 |
| | Robin_Watts: so, I'm updating the opengl device to the new shading prepare/process api split | 14:17.46 |
| | Robin_Watts: and I'm noticing a fair amount of extra copying that has to happen | 14:18.05 |
| Robin_Watts | Really? There is half as much for the existing stuff. | 14:18.56 |
| tor8 | 1) copy source mesh data to fz_vertex, 2) convert color from fz_vertex to temp buffer, 3) copy temp buffer back into same vertex | 14:19.51 |
| | fz_convert_color cannot have the same pointer for source and destination, so the fz_prepare_vertex call always has to work with an internal scratch buffer | 14:20.29 |
| Robin_Watts | oh, because the colour convert can't happen in place, right. | 14:20.39 |
| tor8 | I'm thinking if it wouldn't be better to have two pointer arguments | 14:20.41 |
| | all of the prepare calls look to be preceded by a memcpy to make the struct | 14:21.15 |
| Robin_Watts | sounds reasonable to me. | 14:21.35 |
| tor8 | so maybe prepare_vertex should take the color argument as an in parameter, and create the final fz_vertex instead | 14:21.40 |
| | Robin_Watts: okay, I'll bash on it a bit then | 14:23.03 |
| henrys | good morning, holiday today - president's day | 14:49.18 |
| tor8 | Robin_Watts: a question about process_mesh_type2, if you've got a moment | 15:03.13 |
| | Robin_Watts: nvm that, but there are a handful of commits on tor/master for review | 15:22.21 |
| paulgardiner | Robin_Watts: I've added the conversion busy indicator and cancel button to the ghostdocs demo and pushed to my ghost-docs branch. | 15:24.58 |
| Robin_Watts | tor8: sorry, was at lunch, back now. | 15:25.49 |
| | paulgardiner: ah, thanks. I'll pull that in a bit. | 15:25.59 |
| | tor8: In the const commit, you've changed fz_rect_min/max | 15:28.43 |
| tor8 | Robin_Watts: oh yeah, that should probably be split out in a separate commit. | 15:29.04 |
| | that (void*) cast is a no-op; no idea why it was there | 15:29.23 |
| Robin_Watts | Sometimes you cast via a (void *) to eliminate alignment warnings. | 15:29.42 |
| tor8 | just saw it while scanning the file for the transform_point_xy function | 15:29.55 |
| | hm. that's a new one for me. then again, I don't force cast pointers all that much :) | 15:30.24 |
| Robin_Watts | Can we avoid the casting away of const in the fz_eval_function ? | 15:30.27 |
| tor8 | Robin_Watts: we could if we rewrite the if-cases | 15:30.42 |
| | Robin_Watts: in fact, I think I'll do that | 15:31.03 |
| Robin_Watts | ok. | 15:31.07 |
| tor8 | Robin_Watts: where did you get the alignment cast warnings? | 15:33.01 |
| Robin_Watts | I didn't get any (recently). I'm just saying that's why casts go via (void *) generally. | 15:33.40 |
| | The typical case is where you have a char * that you want to cast to an int *. | 15:34.09 |
| tor8 | Robin_Watts: well, fz_rect is pretty much guaranteed to be aligned already, so I think in this case they shouldn't be necessary | 15:34.15 |
| Robin_Watts | possibly. I just wonder why they were in there. | 15:34.31 |
| | probably me being overly cautious. | 15:34.36 |
| tor8 | Robin_Watts: right. in that case I can see why. but then you're actually relying on the CPU being able to do unaligned loads/stores | 15:34.38 |
| | (which I believe pretty much all current CPUs can) | 15:34.56 |
| Robin_Watts | tor8: No, sometimes you can manually have aligned the address, (or know it's safe via other routes) and the compiler still whinges. | 15:35.29 |
| tor8 | Robin_Watts: right. | 15:35.53 |
| | but the warning is legit; so I can't say I agree with your policy of blindly casting things through void ;) | 15:36.19 |
| Robin_Watts | In fz_paint_annulus, you now call: fz_prepare_color(painter, &t0, &c0); | 15:36.23 |
| | then fz_prepare_color(painter, &t1, &c0); | 15:36.35 |
| | I wonder if it's worth having a 'copy_prepared_color' method? | 15:36.59 |
| | so we can avoid transforming c0 twice. | 15:37.14 |
| | and just copy t0 to t1 ? | 15:37.19 |
| henrys | chrisl: ordered the thinkpad w540 seems to have good linux support. | 15:37.32 |
| tor8 | Robin_Watts: it might, but we're no worse off than before though :) | 15:37.41 |
| Robin_Watts | certainly. | 15:37.47 |
| tor8 | the problem is knowing just how much to copy | 15:38.05 |
| Robin_Watts | fz_prepare_copy calls ->prepare | 15:38.20 |
| tor8 | since a prepared vertex may use an arbitrary number of colors in the fz_vertex | 15:38.22 |
| Robin_Watts | fz_copy_prepared would call ->copy | 15:38.30 |
| tor8 | Robin_Watts: even more boilerplate functions to add :) | 15:39.26 |
| Robin_Watts | Yes. | 15:39.30 |
| tor8 | there are more places where we prepare the same color twice though, so it may be worthwhile | 15:40.01 |
| Robin_Watts | but the commits look good. | 15:40.11 |
| tor8 | Robin_Watts: I have pushed a revised set (with the const cast of fz_eval_function removed) | 15:40.36 |
| Robin_Watts | Looks nice. | 15:44.04 |
| | in fz_eval_function the fakein init looks funky. | 15:44.50 |
| | We should really just memset(fakein + sizeof(float)*(func->m-inlen), 0, sizeof(float)*(func->m-inlen)) | 15:45.47 |
| | (Your commit doesn't make it any worse, just there is an opportunity to be better) | 15:46.20 |
| chrisl | henrys: I have a T530 for my own use, and it runs Debian just fine. Check you have the latest BIOS update, though, there was a bug in some of the Thinkpad bios last year which interacts badly with suspend/restore under Linux | 15:49.31 |
| tor8 | Robin_Watts: yeah. it looks bad. lemme bash on it. | 15:49.49 |
| henrys | chrisl: I still have the macpro workstation but apple has lost their appeal for me. | 15:52.04 |
| chrisl | henrys: Apple lost their appeal for me some time ago....... | 15:53.18 |
| henrys | it sticks longer when you have all your shit parked on one of their systems. | 15:54.17 |
| tor8 | Robin_Watts: take a look on tor/master for tweaked fz_eval_function | 15:56.14 |
| henrys | chrisl: are you dual booting or just linux? | 15:56.45 |
| chrisl | henrys: On my own Thinkpad I just have Linux. For the two work ones, I dual boot with Windows 7 | 15:57.31 |
| Robin_Watts | tor8: looks ok. | 15:57.56 |
| tor8 | Robin_Watts: thanks. | 15:58.34 |
| Gigs- | is the last comment on this bug spam http://bugs.ghostscript.com/show_bug.cgi?id=693004 | 16:10.16 |
| | it's pretty sad if they've actually made spam bots to log into bugzillas now | 16:10.33 |
| henrys | Gigs: yes several bugs have been changed with that. | 16:11.27 |
| Gigs- | good to know, for a minute there I really wondered how someone managed to use gs on a porn chat room | 16:13.36 |
| | but I guess since I'm using it in real time on the web it seemed more plausible | 16:14.04 |
| Robin_Watts | "Check out the beziers on her" etc. | 16:15.13 |
| Gigs- | Nice nurbs | 16:17.30 |
| rayphone | I forgot to let every one know that I won't be around SMS or call of you need me.. | 18:04.09 |
| henrys | rayphone: it's a holiday | 18:07.36 |
| mvrhel_laptop | henrys: what is with all the bug changes from jackie.rosen .... | 19:52.36 |
| Robin_Watts | mvrhel_laptop: spam :( | 19:52.52 |
| mvrhel_laptop | crap | 19:52.55 |
| henrys | mvrhel_laptop: spam I guess marcosw will look at i. | 19:52.56 |
| | s/i./it. | 19:53.04 |
| Robin_Watts | mvrhel_laptop: New version of GhostDocs.apk in my home dir. | 19:53.05 |
| mvrhel_laptop | Robin_Watts: ok. will try it out later today | 19:53.14 |
| | hoping to go skiing today | 19:53.20 |
| | road has been closed though due to too much snow | 19:53.29 |
| | it is about time | 19:53.31 |
| Robin_Watts | 2 main changes. Firstly, it gets justification right (turned out to be surprisingly easy) | 19:53.32 |
| | Secondly, it puts up a spinny 'eggtimer' thing while the conversion is happening. | 19:53.56 |
| mvrhel_laptop | Robin_Watts: ok. Oh I do have one file that has sideways text in a figure that gets screwed up | 19:54.01 |
| Robin_Watts | mvrhel_laptop: Does it look right in the app? | 19:54.17 |
| mvrhel_laptop | I will check that later today too | 19:54.28 |
| Robin_Watts | I'm now working on trying to get underlines to appear. That's being harder than you would expect :) | 19:54.43 |
| mvrhel_laptop | Robin_Watts: but things are looking much better for sure | 19:54.44 |
| | great work | 19:54.54 |
| Robin_Watts | Paul is going to tweak the app a bit so that the proper name appears at the top rather than "MuTMPxxxx" | 19:55.11 |
| | Forward 1 day (to 2014/02/18)>>> | |
IRC Logs