| | <<<Back 1 day (to 2013/01/03) | 2013/01/04 |
| kens | Oh God, A Cario-produced PDF file with more than 10 levels of nesting :-( | 09:23.46 |
| Robin_Watts | tor8: ping | 12:26.19 |
| tor8 | Robin_Watts: morning | 12:26.39 |
| Robin_Watts | morning. | 12:26.45 |
| | this pdf_obj_mark stuff. | 12:26.53 |
| | zeniko points out that the dict is the largest struct in the union, so I could move the marked flag out of the union without hurting the overall size of pdf_obj | 12:27.48 |
| | My first attempt kept the marked flag just in the array and the dict sections. | 12:28.10 |
| | Do you have a preference? | 12:28.32 |
| | Moving it out would make the code simpler, so I'm leaning towards agreeing with him, I think. | 12:31.10 |
| | oh, hmm. I think he's wrong. It will grow the structure. | 12:32.37 |
| | cos of packing. | 12:32.44 |
| tor8 | Robin_Watts: what's the granularity of malloc returns compared with the size of pdf_obj_s ? | 12:37.05 |
| | pdf_obj_kind can be made a char, in which case the marked can be put there without affecting the size | 12:37.39 |
| | (and let the enum use some mnemonic ascii values to retain some form of debuggability) | 12:38.15 |
| | PDF_BOOL = 'b', | 12:39.16 |
| | PDF_INT = 'i', | 12:39.16 |
| | etc | 12:39.17 |
| Robin_Watts | granulatiry - don't know. | 12:56.02 |
| | Making the kind a char makes sense of course. | 12:56.40 |
| | Using 'b', 'i' etc, is bad, IMHO. | 12:56.49 |
| | When we switch on 'kind', we'd rather have a narrow grouping of values (0...10) rather than (b,f,i,r, etc) | 12:58.00 |
| tor8 | Robin_Watts: we only switch on kind in one place, when doing fz_objcmp which is pretty rare | 13:00.03 |
| | sorry, pdf_objcmp ... still mistyping those functions all the time! | 13:00.22 |
| Robin_Watts | bool=b, int=i, real=f, string=s, array=a, dict=d, indirect=r, name=n, null=... ? | 13:10.22 |
| tor8 | 0 perhaps? | 13:10.44 |
| Robin_Watts | Yeah, that's what I was hoping :) | 13:11.06 |
| | hmm. A cluster test says no. | 13:22.08 |
| sebras | yes, please make kind be something else than an enum! | 13:37.13 |
| | I really hate having to dig through that list of enums while debugging. | 13:37.32 |
| | agh, you're not discussing PDF_TOK_* :( | 13:38.09 |
| malc_ | Robin_Watts: i looks as if my fz_catch doesn't catch a rethrow from cbz_load_page, any hints how to debug? | 14:05.43 |
| Robin_Watts | malc_: Can you catch the fz_throw in a debugger? | 14:09.44 |
| | (Well, fz_rethrow, probably) | 14:10.14 |
| | If you look up the stack from there and it's not ending up where you expect, then I suspect something is messing up the exception stack. | 14:10.52 |
| | I'd be suspicious that you might be returning within an fz_try block, as that's an easy mistake to make. | 14:11.15 |
| malc_ | am not, let me try a few things | 14:12.09 |
| | Robin_Watts: uh, pulling latest mupdf and rebuilding "solves" it | 14:21.10 |
| Robin_Watts | fab. | 14:21.26 |
| | tor8: OK. Updated reviews. Tests all passed. | 14:50.20 |
| sebras | tor8: you have a patch for pdf_token now... | 14:56.54 |
| Robin_Watts | sebras: For pdf_token we DO use switch a lot. | 15:09.28 |
| | What on earth is the cluster doing? | 15:10.07 |
| kens2 | waitiing for log files ? | 15:10.36 |
| sebras | Robin_Watts: yes, I was mixed up kind and pdf_token. | 15:12.20 |
| | Robin_Watts: my patch just typedefs the PDF_TOK_* enum to pdf_token and uses the new type everywhere. this means that gdb can now decode the values into symbolic names which eases debugging considerably. | 15:13.10 |
| Robin_Watts | Ah, nice. | 15:17.10 |
| | kens2: still waiting. | 15:17.23 |
| | marcosw1: ping | 15:17.27 |
| kens2 | yes, that was my next sughgestion | 15:17.37 |
| Robin_Watts | let's try abort and rerun. | 15:18.04 |
| tor8 | Robin_Watts: patches look Go! to me | 15:36.24 |
| | sebras: your patch also looks good. | 15:36.46 |
| sebras | tor8: excellent. | 15:37.58 |
| Robin_Watts | tor8: Thanks. does that include the fax one? | 15:40.15 |
| | I'll send sebras one too. | 15:40.26 |
| tor8 | Robin_Watts: oh, I missed the fax one. it looks hairy. | 15:47.38 |
| Robin_Watts | mmm | 15:47.48 |
| | I think it's correct though. | 15:50.12 |
| | Can you suggest a route around the hairyness? | 15:58.21 |
| sebras | Robin_Watts: you would need to call fflush(stderr) to be sure that the message is printed though..? | 16:03.45 |
| Robin_Watts | sebras: True. | 16:03.58 |
| sebras | but it's debug code so... | 16:04.07 |
| | Robin_Watts: is this a regression from bc3ce65f? | 16:11.58 |
| Robin_Watts | I can't see bc3ce65f | 16:13.21 |
| | I have it. | 16:14.45 |
| | Supposedly zeniko is seeing occasional reports of problems in that function even with the very latest stuff. | 16:15.18 |
| | I think he must get online bug reports when sumatra crashes, cos he says he knows it's crashing, but doesn't have an example file (public or private). | 16:16.02 |
| | There was a mistake in the code that could end up in us reading 1 byte further than we should. | 16:16.32 |
| | and I've fixed that in this version. | 16:16.41 |
| malc_ | tor8: why does cbz code sort zip entries? | 16:35.25 |
| Robin_Watts | malc_: Possibly to ensure that stuff gets displayed in the correct order? | 16:36.10 |
| tor8 | malc_: to get the page order | 16:36.21 |
| | malc_: sorry, I missed your question a few weeks ago, and now I forgot what it was about | 16:36.48 |
| malc_ | Robin_Watts, tor8: doesn't make sense. i have numbered pictures 10 goes before 2 in this case | 16:36.54 |
| | tor8: glfont licence | 16:37.05 |
| Robin_Watts | 001,002,003 then. | 16:37.08 |
| tor8 | malc_: oh right. consider that one public domain. | 16:37.19 |
| | Robin_Watts: malc_: I guess we should be using a "human sort" function | 16:37.48 |
| malc_ | tor8: tack | 16:37.57 |
| tor8 | where numbers in the string get sorted numerically | 16:37.57 |
| | Robin_Watts: windows tip of the day: robocopy.exe | 16:38.27 |
| malc_ | why sort in the first place, the cbz assembler should just put them into container in the proper order to begin with | 16:38.36 |
| | everything else is a bound to fail heuristic | 16:38.45 |
| tor8 | malc_: that is a fair point too | 16:39.15 |
| Robin_Watts | tor8: Interesting. I've used teracopy before. | 16:39.22 |
| malc_ | powershelll | 16:39.32 |
| | minus l | 16:39.37 |
| tor8 | Robin_Watts: robocopy is part of standard windows, though | 16:39.46 |
| | Robin_Watts: quite happy to have discovered it today. makes backing up directories onto external drives a lot easier. | 16:40.07 |
| Robin_Watts | tor8: Fairy nuff. | 16:40.18 |
| | New reviews up. | 16:40.22 |
| tor8 | Robin_Watts: hm. how about a fz_atoi that is NULL-robust instead? | 16:42.37 |
| | I'm sure there are other places with the same issue | 16:42.59 |
| Robin_Watts | I checked, and couldn't see any. | 16:43.14 |
| | fz_strsep -> atoi that is. | 16:43.21 |
| tor8 | Robin_Watts: right. | 16:44.35 |
| | Robin_Watts: also: stop being so productive! I can't ever get anything done when you keep interrupting me with reviews all the time :) | 16:45.02 |
| Robin_Watts | tor8: sorry. | 16:45.15 |
| tor8 | (hammering on the fz_bbox / fz_rect stuff, it's a lot of annoying busywork) | 16:45.32 |
| malc_ | Robin_Watts: make him write his request in full sentenced english, that should slow him down somewhat | 16:45.37 |
| Robin_Watts | I'm going to give up soon. I've decided that this man flu is actually proper flu. | 16:46.17 |
| JakeSays | I have a question regarding simple text layout. its more of a freetype question, but i'm hoping someone in here can answer it. i'm rendering a series of glyphs to a .png, which works well enough, except none of the glyphs with decenders are decending. so my question is, how do i determine what the baseline of a font is? | 16:52.36 |
| Robin_Watts | JakeSays: Are you positioning all the glyph bitmaps you get back from freetype on the same baseline? | 16:53.51 |
| JakeSays | Robin_Watts: well, yes, in that i'm not doing anything special with them | 16:54.24 |
| | which is why none of them are decending | 16:54.33 |
| tor8 | JakeSays: face->glyph->bitmap_top and face->glyph->bitmap_left | 16:54.47 |
| Robin_Watts | I can't speak for freetype itself in that I haven't done much with it, but... generally you should get a bbox for each glyph, and you should offset the position by the appropriate thing. Ah. What tor8 said. | 16:55.14 |
| tor8 | those are the values you need to offset the bitmap to center the glyph on the baseline | 16:55.14 |
| JakeSays | tor8: ah. | 16:55.19 |
| tor8 | JakeSays: and then advance (face->glyph->advance.x / 64.0) units to the next glyph on the line | 16:55.58 |
| JakeSays | tor8: heh. wow thats easy enough! thanks! | 16:56.18 |
| tor8 | JakeSays: the freetype api looks scarier than it is | 16:56.36 |
| malc_ | tor8: pascal roots | 16:57.06 |
| Robin_Watts | Woo Hoo! I've just finished my first run through all the mupdf failing files from customer 395. | 16:57.56 |
| | Memento gives them all a clean bill of health with no SEGVs - except for libopenjpeg ones, which I've punted on for now. | 16:58.34 |
| | On monday I shall look at libopenjpeg 2.0 | 16:58.44 |
| | then I'll try them all through valgrind. | 16:58.56 |
| | And now, I shall go curl up somewhere with a dog to keep me warm. | 16:59.30 |
| tor8 | Robin_Watts: get well! | 17:00.57 |
| JakeSays | tor8: ahh much bettter! | 17:01.51 |
| | tor8: advance.x / 64 isn't a pixel, is it? | 17:03.16 |
| tor8 | advance.x is the advance in fixed point format | 17:07.42 |
| JakeSays | right | 17:07.56 |
| tor8 | so divide by 64 to get it in real pixels | 17:08.09 |
| JakeSays | ok cool | 17:08.18 |
| tor8 | JakeSays: are you rendering with or without hinting turned on? | 17:08.25 |
| JakeSays | tor8: um, no idea. | 17:08.47 |
| tor8 | for the smoothest results I'd recommend rendering with no hinting and use floating point positioning for the glyphs | 17:08.49 |
| JakeSays | whatever the default is | 17:08.52 |
| tor8 | FT_Load_Glyph(face, gid, FT_LOAD_NO_HINTING); | 17:09.11 |
| JakeSays | ah i'm doing FT_LOAD_DEFAULT | 17:09.29 |
| tor8 | to get floating point positioning, calculate your x and y position as floats | 17:10.10 |
| JakeSays | tor8: actually all i'm doing is generating an image of glyphs of an embedded font in a pdf, accuracy isn't a huge issue | 17:10.37 |
| tor8 | then FT_Vector v; v.x = x - floor(x); v.y = y - floor(y); FT_Set_Transform(face, NULL, &v); | 17:10.38 |
| | JakeSays: well in that case I'll stop now :) | 17:10.58 |
| JakeSays | lol | 17:11.03 |
| | i'm just showing the image so a user can assign character values, so i can reconstruct missing character maps | 17:11.30 |
| | the goal is to extract text | 17:11.54 |
| | i was going to do ocr, but ocr confuses l with | | 17:12.30 |
| kens2 | Goodnight all | 17:33.13 |
| mvrhel_laptop | starting to feel almost normal again... | 19:08.21 |
| | Robin_Watts: when is the trip to Kiev? | 19:08.57 |
| ray_work | mvrhel: I thought he had already been there and came back. I know he mentioned Chernobyl -- how close to the reactor they were able to get. | 19:22.43 |
| mvrhel | no idea' | 19:23.47 |
| henrys | mvrhel:he's been there and back pictures on facebook | 19:52.36 |
| mvrhel_laptop | henrys: oh ok. I guess I am just now getting caught back up with things | 19:55.52 |
| Robin_Watts | mvrhel_laptop: Yeah, been to Kiev. | 23:29.00 |
| | Had a great time. Managed to hold the worst effects of the flu off until I got back. | 23:29.25 |
| | Forward 1 day (to 2013/01/05)>>> | |
IRC Logs