| | <<<Back 1 day (to 2013/08/25) | 2013/08/26 |
| kens | chrisl ping | 06:51.37 |
| chrisl | kens: pong | 06:56.25 |
| kens | chrisl what do you think about another release ? I was going to suggest asking at the Tuesday meeting, but IIRC henry said we wouldn't have one this week | 06:56.58 |
| chrisl | Yeh, Henry is away until Wed IIRC..... | 06:57.21 |
| | My inclination is that it sounds like we do need another release, and we should start afresh, rather than build another on 9.08/9.09..... | 06:58.20 |
| kens | I think so too. I would like to do a little more testing/investigation today, I realised I didn't check for initialisationfiles executing gstate, other than gs_dps.ps and I need to | 06:59.04 |
| chrisl | Okay, so when you're ready, let me know, and I'll create a release branch, and ping a mail off to Marcos to start testing. | 06:59.56 |
| kens | Right, hopefully it will be today, if I find any more problems I'm inclined to simply revert all the changes and go back to hte old behaviour | 07:00.29 |
| | I'll get started now. | 07:00.58 |
| chrisl | That sounds fair, at least for this release. | 07:01.08 |
| | BTW, I'll be in and out a bit today - just in case I forget to meddle with my nick.... | 07:01.56 |
| kens | Not a problem. By the way, the PLRM says that you should avoid allocating gstate objects in global VM :-( | 07:02.24 |
| | TaDa. do 'true setglobal gstate' and you get a VM error. | 07:03.10 |
| | sorry invalidaccess | 07:03.22 |
| | I'm doubtful if we can fix this. | 07:04.01 |
| | Though I suppose technically we don't have to, the PLRM says this is expected behaviour | 07:04.33 |
| | I just need to make sure it can't happen during startup | 07:04.47 |
| sebras | http://parall.ax/products/jspdf | 07:09.32 |
| | maybe you should just feed gs through a c-to-js convertor (emscripten?) and be done with it... ;) | 07:10.59 |
| kens | I bet GS would break a C to anything converter | 07:11.28 |
| chrisl | sebras: I messed with gs and emscripten a while back - they didn't play nicely together..... | 07:13.09 |
| kens | chrisl I've finished checking gstate; we always did raise an invalidaccess error when executing gstate in a global VM context, its not my change that caused that. Which means I only have to worry about executing gstate in the startup code, and that seems to be OK now. | 08:06.20 |
| chrisl | kens: that sounds wrong to me, but I suppose if it's not a regression, then..... | 08:08.20 |
| kens | The PLRM is pretty specific that its a bad idea, because the gstate can contain stuff in local VM (current halftone, etc) and if it does then an invalidaccess is the correct error | 08:09.00 |
| chrisl | Fair enough.... | 08:09.40 |
| sebras | chrisl: kens: no, I didn't expect emscripten to be able to convert any major project. anything of that size tends to contain code that is specialized in a way that any automatically converting tool would mess up. | 09:07.04 |
| chrisl | sebras: it didn't take a lot to get the conversion to complete (which impressed me a lot!), but I had neither the time nor the inclination to fathom why it didn't run | 09:09.10 |
| Robin_Watts | sebras, tor7, paulgardiner: Morning all. | 09:11.31 |
| paulgardiner | Hi Robin_Watts | 09:11.50 |
| Robin_Watts | I got my RLEd glyph storage/plotting code working over the weekend. | 09:11.56 |
| | The latest bmpcmp run shows the few diffs I get (all due to a slight change in the blending of edge pixels - just rounding). | 09:12.35 |
| | I need to get the conversion from freetype bitmap -> RLE done directly rather than going via fz_pixmaps to save time. | 09:13.06 |
| | but otherwise the code is up on robin/master for anyone interested in looking at it. | 09:13.23 |
| paulgardiner | Nice. So big space savings. | 09:16.12 |
| | Why does RLE affect edge pixels? | 09:16.41 |
| Robin_Watts | paulgardiner: I hope so. | 09:16.45 |
| | The RLE I use categorises pixels into runs of transparent pixels, runs of solid pixels, and runs of "edge" pixels. | 09:17.18 |
| | The way we do blending of edge pixels involves merging 2 alpha values together. | 09:18.08 |
| | and the rounding works out slightly differently in the new code than the old code. | 09:18.44 |
| paulgardiner | Oh okay. Makes sense | 09:19.37 |
| Robin_Watts | I haven't measured for space savings yet. | 09:20.00 |
| | but I'd hope that it should be worthwhile. | 09:20.21 |
| | I'm also hoping for speed improvements. | 09:20.29 |
| chrisl | kens: so are we ready for a new release branch? | 09:33.15 |
| kens | chrisl I'm as ready as I'll ever be :-( | 09:33.28 |
| | I can't think of anythign else to test | 09:33.40 |
| chrisl | Okay, I'll get that rolling.... | 09:33.56 |
| kens | GHot to start somewhere I guess. Maybe people will test the RC this time.... | 09:34.16 |
| chrisl | Doubt it | 09:34.39 |
| kens | Sadly I'm inclined to agree :-( | 09:34.56 |
| Robin_Watts | tor7: ping | 11:37.49 |
| Hemza | Hello,, i have a question about zathura building in ubuntu 12.4 | 12:41.11 |
| Robin_Watts | Hemza: http://pwmt.org/projects/zathura/ ? | 12:43.49 |
| kens | zathura uses MuPDF ? | 12:47.52 |
| Robin_Watts | apparently it can. | 12:48.00 |
| Hemza | Robin_Watts: Iwant to know how I could install Mupdf as a shared library ( with -fPIC as mentioned in Zarthura's site). I come throught this patch http://bugs.ghostscript.com/show_bug.cgi?id=693009, but i don not know how to apply | 12:48.09 |
| Robin_Watts | Hemza: I think I'm right in saying that we don't offer a shared lib build in the standard makefile. | 12:49.22 |
| | You'd need to discuss it with tor7 (the keeper of the Makefile) to be sure. | 12:50.13 |
| Hemza | Robin_Watts: thabk you | 12:51.31 |
| | tor7: how could ii build Mupdf from source as a shared lib? or it is not possible! | 12:52.30 |
| Robin_Watts | Today is a bank holiday in the UK. | 12:53.30 |
| | tor7 is in sweden - not sure it's a holiday there. | 12:53.44 |
| | if it is, he may not be around. | 12:53.55 |
| Hemza | ok | 12:54.03 |
| | i hope he could reply | 12:54.19 |
| Robin_Watts | He might - just be prepared to wait a bit. | 12:54.35 |
| malc__ | Hemza: just build with "make build=release CC='gcc -fPIC'" voila | 13:00.10 |
| Robin_Watts | malc__: Surely make build=release XCFLAGS="-fPIC" ? | 13:02.09 |
| | and then you'll have to pick which of the libs to link with etc. | 13:02.32 |
| malc__ | Robin_Watts: eh? CFLAGS works just as fine, and no, you don't need to care about libs | 13:07.56 |
| Hemza | Robin_Watts & malc__ : thank you i will try it. | 13:11.08 |
| malc__ | correction, CC works just as fine, not CFLAGS | 13:12.08 |
| sebras | Robin_Watts: when you have some spare time, have a look at my updated commit messages and the patch inspired by malc__'s problem. | 13:13.22 |
| | Robin_Watts: I'm not sure if I'm harassing you too much, but I hope you take this as a gentle reminder. | 13:14.42 |
| atulagrwl | paulgardiner: ping | 13:22.25 |
| paulgardiner | atulagrwl: hi | 13:23.07 |
| atulagrwl | paulgardiner: Can you look at one pdf to see why annotation is not appearing in mupdf (and all other pdf readers)? | 13:24.21 |
| paulgardiner | Sure. It would be good to open a bug and attach it. | 13:25.56 |
| atulagrwl | if you say it is a problem, I will log a bug. I just want to confirm it (quickly) | 13:26.39 |
| | what is the best place to attach a pdf? | 13:26.54 |
| paulgardiner | Anywhere on the web I can download it from. | 13:27.45 |
| atulagrwl | Needless to say I do not known the copyright of the pdf :-) | 13:27.49 |
| paulgardiner | Most likely, it has an annotation without an appearance stream. Other readers may be creating an appearance stream on the fly | 13:28.54 |
| atulagrwl | paulgardiner: annotation is created using mupdf only and other readers can not show the annotation as well | 13:29.40 |
| paulgardiner | Oh I see now | 13:30.17 |
| atulagrwl | I am expecting some xref kind of issue again. (No idea just an hunch) | 13:30.21 |
| paulgardiner | I'd certainly be interested to take a look. | 13:31.20 |
| atulagrwl | paulgardiner: send the link of pdf to you in private chat | 13:35.39 |
| | I tried to create simple test case but it worked. I suspect something wrong in the pdf. | 13:38.02 |
| | paulgardiner: Got the link? | 13:44.08 |
| paulgardiner | Yes | 13:44.33 |
| | The incremental update in the file includes the new annotation, but not an updated page dict that refers to it (or an updated annotations array for the page). | 13:46.20 |
| | How did you create this? | 13:46.28 |
| atulagrwl | opened the file in mupdf (android) and added annotation and saved the file. | 13:47.11 |
| paulgardiner | Oh okay. Worth opening a bug then. | 13:47.44 |
| atulagrwl | paulgardiner: okay | 13:49.36 |
| paulgardiner | Thanks | 13:50.20 |
| atulagrwl | paulgardiner: Can I avoid attaching sample file to bug note as I don't want this file in public? | 13:50.57 |
| Robin_Watts | atulagrwl: We can mark attachments as private. | 13:53.14 |
| paulgardiner | atulagrwl: sure. Just give me a link to the original file without the added annotation. Also instructions as to exactly what to hightlight on which page might be useful in case the problem is specific to those details | 13:53.19 |
| Robin_Watts | hence only people in the company can see them. | 13:53.25 |
| | sebras: Will do. | 13:53.53 |
| | sebras: No problem about hassling me - my crap memory has been well documented. | 13:54.15 |
| sebras | Robin_Watts: ok, let me know if there are more messages I ought to have updated. | 13:54.17 |
| paulgardiner | Robin_Watts: How does that work? Should atulagrwl attach the file and then one of us immediately mark it private? | 13:54.18 |
| Robin_Watts | paulgardiner: Either that, or he mails it to us and we can attach it and mark it private at the same time. | 13:54.41 |
| paulgardiner | Right | 13:54.55 |
| atulagrwl | I tried adding annotation on second page and see the problem. Have not tried doing that anywhere else yet. Adding ink annotation on first page also creates problem. | 13:55.22 |
| atulagrwl | goes for dinner. Will be back in 10 mins | 13:55.43 |
| Robin_Watts | sebras: All look good to me. Will push them now. | 13:58.06 |
| sebras | Robin_Watts: excellent. | 14:01.36 |
| | Robin_Watts: you did notice the new patch as well..? | 14:01.47 |
| Robin_Watts | the link dest one? | 14:01.56 |
| sebras | mm. | 14:02.02 |
| Robin_Watts | yeah, that's fine. Pushed that one too. | 14:02.40 |
| | sebras, paulgardiner: Could one of you nod at "Fix memory leak in new glyph cache code" please? | 14:03.15 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=ba0afefc58ca583142463bd012bdd4b1b447582e | 14:03.34 |
| sebras | reads the patch. | 14:09.52 |
| tor7 | Hemza: Robin_Watts is right in that we don't support building mupdf as a shared library | 14:10.59 |
| paulgardiner | Robin_Watts: looks sensible enough to me | 14:11.01 |
| Robin_Watts | paulgardiner, sebras: Thanks. | 14:11.23 |
| sebras | Robin_Watts: I'm not sure that your patch fixes all probolems though. | 14:11.35 |
| | Robin_Watts: do you fz_keep_font() the font correctly when you insert it? | 14:11.50 |
| Robin_Watts | sebras: What do you think it gets wrong? | 14:11.53 |
| | sebras: Yes, i believe so. | 14:12.01 |
| | Memento gives it a clean bill of health. | 14:12.08 |
| tor7 | Robin_Watts: pong. sorry, was taking a nap when you pinged me earlier. | 14:12.20 |
| Robin_Watts | (In fact, I only noticed the problem when memento showed leaks) | 14:12.24 |
| | tor7: no worries. | 14:12.28 |
| sebras | Robin_Watts: ok, I haven't mamanged to check the code manually, but I'm worried that you might drop the font more than it is kept... | 14:12.35 |
| Robin_Watts | tor7: I was wanting to consult over the optimisation of my RLE glyph code. | 14:12.56 |
| tor7 | Robin_Watts: okay. I looked over the first version of your commit this morning. | 14:13.17 |
| Robin_Watts | sebras: I don't believe I do - that would cause errors that the cluster would pick up, I think. | 14:13.30 |
| | The cluster won't pick up leaks, but it will probably pick up stuff being dropped too often (and hence freeing too early) | 14:13.57 |
| tor7 | and I was wondering why you had a fz_pixmap pointer in the fz_glyph | 14:14.06 |
| Robin_Watts | tor7: The RLE glyph stuff only works for black and white glyphs. | 14:14.27 |
| | For colored glyphs (like type3's can be), we need to use the old pixmap code. | 14:14.45 |
| tor7 | right. for the opengl device we also need to use the old pixmap code. | 14:15.02 |
| | is there a way to know before calling render_glyph whether it will return a colored or b&w glyph? | 14:15.36 |
| Robin_Watts | tor7: not easily. | 14:15.49 |
| tor7 | because I'm guessing you'll want to use the RLE for b&w type3 fonts as well | 14:16.02 |
| Robin_Watts | tor7: indeed, I do. | 14:16.11 |
| tor7 | the ability to do colored type3 fonts is currently independent of the decision that they are cacheable | 14:17.09 |
| | we have the "is-cachable" test in the type3 font code that the interpreter makes use of | 14:17.29 |
| sebras | Robin_Watts: ok, so the font is kept e.g. in fz_new_text() which is then transferred to fz_render_glyph() where it is inserted in the key but not kept. | 14:17.31 |
| tor7 | one way out would be to make all colored glyphs non-cachable :) | 14:17.41 |
| | considering how rare they are... | 14:17.51 |
| Robin_Watts | In fz_render_glyph, we either call fz_render_ft_glyph or fz_render_t3_glyph. | 14:18.07 |
| sebras | Robin_Watts: I'm not sure the latter is ok, and that ought to means that you can free the font from under the feet of the text-object, no..? | 14:18.10 |
| Robin_Watts | fz_render_ft_glyph always goes to a glyph. | 14:18.30 |
| sebras | Robin_Watts: sure, but before you call fz_render_ft_glyph you create the key. | 14:18.58 |
| | Robin_Watts: which is meant to hold a reference to the font. | 14:19.06 |
| Robin_Watts | fz_render_t3_glyph always draws to a pixmap, and we go from that to a glyph, which may be RLEd or a pixmap. | 14:19.10 |
| sebras | Robin_Watts: which is what you attempt to freee. | 14:19.12 |
| Robin_Watts | sebras: Sorry, 2 conversations at once here. | 14:19.19 |
| sebras | Robin_Watts: oh. in the same area too. sorry about that. :) | 14:19.29 |
| Robin_Watts | sebras: The font always goes into the key. | 14:20.04 |
| | and the font is then "kept" if we choose to insert the key. | 14:20.19 |
| | If the key is just used for lookup, then we don't keep it (as the fz_text and hence the font) is guaranteed to be valid for the length of the life of the key. | 14:20.49 |
| | This code is essentially unchanged from before my glyph cache rewrite. | 14:21.09 |
| sebras | Robin_Watts: ah, I didn't see that fz_keep_font(). ok. then I'm all ok with you patch. :) | 14:21.36 |
| Robin_Watts | it was just the cache entry dropping that I rewrote, and cocked up. | 14:21.36 |
| | sebras: Thanks for the sanity check. | 14:21.44 |
| | tor7: Regardless of whether we cache or not, we need to cope with both colored and uncolored glyphs. | 14:22.50 |
| | so it doesn't seem unreasonable to have an fz_glyph have different mechanisms internally for coping with colored/uncolored. | 14:23.21 |
| | Hence in my patch we either have RLE for uncolored, or we drop back to using the existing pixmap code for colored. | 14:23.46 |
| | tor7: You can close bug 694533 if you want now, and reduce your customer bugs to 0 :) | 14:24.53 |
| tor7 | Robin_Watts: ah, thanks for that reminder. | 14:25.39 |
| Robin_Watts | tor7: In my latest patch, I moved all the RLE plotting code into fz_paint. | 14:26.36 |
| tor7 | Robin_Watts: if colored type3 glyphs can use the fallback mechanism we have for uncachable glyphs, they bypass the cache altogether. doing so would mean only needing to worry about b&w glyphs. | 14:26.38 |
| | I'm also not sure that we don't already do that | 14:27.09 |
| Robin_Watts | I *could* make colored glyphs uncacheable, but what would we gain by that? | 14:27.18 |
| tor7 | FZ_DEVFLAG_UNCACHEABLE, drawn directly by the interpreter | 14:27.48 |
| | we'd gain a cleaner API for dealing with glyphs in the cache and everywhere else | 14:27.59 |
| Robin_Watts | Currently colored glyphs are only uncacheable if they don't specify the colors as part of the glyph stream. | 14:28.18 |
| | According to the spec, all glyphs *should* specify the colors they use as part of the stream, but in practise this does not happen in all cases. | 14:28.51 |
| tor7 | but handling colored glyphs as a special case isn't currently that troublesome. I'd have to investigate to find a test file to test that code though. | 14:29.03 |
| Robin_Watts | hence we can end up with glyphs that render differently according to the current colors. | 14:29.23 |
| | I spot those cases and set the UNCACHEABLE flag. | 14:29.37 |
| | but my patch copes with all this just fine, I believe. | 14:30.14 |
| | The reason I pinged you was to talk about the fz_paint_glyph code. | 14:30.36 |
| | I moved the glyph plotting code into fz_paint, along with all the other code that does this kind of stuff. | 14:30.58 |
| tor7 | Robin_Watts: just don't forget that I still want to be able to get a fz_pixmap from fz_render_xxx_glyph (or a similar function) | 14:31.01 |
| Robin_Watts | tor7: For the opengl device, sure. | 14:31.23 |
| tor7 | the opengl device should (once I start using shaders again) render to a bigger size and convert the representation to a signed distance field | 14:32.13 |
| Robin_Watts | I suspect the best way to do that is to have 2 different functions we can call, one that returns a pixmap, one that returns a glyph. | 14:32.24 |
| tor7 | okay, so fz_paint_glyph | 14:32.43 |
| Robin_Watts | and the actual guts of the two functions can largely be shared. In the ft case, we'd either make a pixmap or a glyph from the ft_bitmap as appropriate. | 14:33.19 |
| | OK, fz_paint_glyph. | 14:33.26 |
| tor7 | Robin_Watts: yes (re guts of two functions) | 14:33.50 |
| Robin_Watts | I had various different paths through the core fz_paint_glyph loop (are we using colorbv or not? if we are using it, was colorbv[n-1] == 255?) | 14:34.36 |
| | and I had them all multiplexed into a single inline function that would hopefully expand itself out nicely. | 14:35.12 |
| | You've done a similar thing elsewhere in the same file. | 14:35.47 |
| | In the latest patch, I pulled them all out separately, cos 1) I think the code is more readable that way, and 2) it means I can then do the static inline expansion trick for N=2,4,any. | 14:36.31 |
| | I just wanted to check you were happy with that. | 14:36.55 |
| tor7 | yes, it looks nicer even though the RLE decoding logic is duplicated | 14:36.57 |
| Robin_Watts | Yeah, couldn't see a nice way to get the best of all worlds though. | 14:37.18 |
| tor7 | fz_glyph_from_xxx should be named fz_new_glyph_from_xxx | 14:37.37 |
| Robin_Watts | ok. | 14:38.16 |
| tor7 | all functions that return something that passes ownership needs one of the magic keywords in the name | 14:38.52 |
| Robin_Watts | I'll rename that, then do some tests to see how much memory we save (and see how the times compare). | 14:39.04 |
| tor7 | (they're all listed in docs/naming.txt) | 14:39.05 |
| Robin_Watts | yeah, my bad. | 14:39.12 |
| tor7 | I've missed the same instance a few times myself :) | 14:39.23 |
| | I wonder about the _inline suffix though | 14:40.25 |
| | have we used that naming before? | 14:40.44 |
| Robin_Watts | I'm always happy to get better naming suggestions. | 14:40.58 |
| tor7 | _imp is our standard "this is the private 'implementation' function" suffix | 14:41.20 |
| | but I'm happy to have a better convention than that | 14:41.27 |
| Robin_Watts | _imp would work for me. | 14:41.58 |
| tor7 | fz_paint_glyph_inline to fz_paint_glyph_alpha and you can drop the _inline without naming ocllisions, I believe | 14:42.35 |
| Robin_Watts | yeah. nice one. | 14:47.37 |
| | Did you look at any of my plotting optimisations? | 14:48.09 |
| tor7 | I've looked through the span painting optimisations | 14:56.36 |
| | they look fine. | 14:56.54 |
| | paint_affine caused my brain to melt just thinking about the problem domain :) | 14:57.23 |
| | but having looked at it now, that one's fine too | 14:57.48 |
| | how are the performance measurements of these optimisations? | 14:57.57 |
| Robin_Watts | tor7: they all gave noticable improvements on the raspberry pi. | 14:58.27 |
| tor7 | I saw you added SWAR versions of a few | 14:59.15 |
| Robin_Watts | I did. | 14:59.27 |
| | I wrote various versions of fz_paint_span_with_color and fz_paint_solid_color, including ARM code versions. | 14:59.58 |
| tor7 | and then removed the #ifdef'd ones | 15:00.07 |
| Robin_Watts | Then in a later commit I removed all but the best version. yeah. | 15:00.16 |
| | I was surprised that the ARM versions didn't outperform the C. | 15:00.38 |
| | but if I ever want to try again I can pull them out of git. | 15:00.51 |
| tor7 | compilers getting better, or hardware not behaving as it used to? | 15:00.54 |
| Robin_Watts | For now, better to keep the code clean. | 15:00.57 |
| | tor7: probably a bit of both. | 15:01.02 |
| tor7 | I'm sure hardware designers work hard to make C-generated code run fast :) | 15:01.19 |
| Robin_Watts | so, are you happy for me to push those? | 15:02.12 |
| tor7 | yes, the first 4 are good to go | 15:08.14 |
| Robin_Watts | Thanks. | 15:09.00 |
| tor7 | we should figure out the API to use for writing of images to outputs in both banded and non- | 15:09.09 |
| | banded modes. | 15:09.13 |
| Robin_Watts | tor7: yeah. | 15:09.18 |
| tor7 | it should be easy enough to make the primary image writing always use fz_output | 15:09.35 |
| | and then take it from there. feel free to drop the png banded implementation in my lap. | 15:09.49 |
| Robin_Watts | tor7: Something that occurred to me while debugging the RLE stuff... we should probably disable subpixel positioning for glyphs over a given size. | 15:40.50 |
| tor7 | Robin_Watts: yeah. I'd ideally like for the number of subpixel positions we have to be a function of glyph size | 15:41.53 |
| | so really small text has more subpixel variants, and at large enough sizes there'd be none | 15:42.11 |
| Robin_Watts | yeah, that'd be ideal. | 15:42.16 |
| tor7 | I think it'd be possible with a few tweaks to how we generate the glyph cache key | 15:42.46 |
| Robin_Watts | So, running at 1200 dpi, the first 100 pages of PLRM cause 44712 evictions, totalling 300Meg of discarded data. | 15:44.37 |
| | New RLE code: 13353 evictions, totalling 19.8Meg | 15:44.50 |
| tor7 | max cache size for those tests? | 15:45.34 |
| Robin_Watts | That's with the standard 1Meg cache size | 15:45.56 |
| | In total, to do the first 100 pages of pdf_reference17.pdf with no evictions, we need a cache size of 34.6Meg with the existing code. | 15:48.03 |
| | and 7.4Meg with the RLE stuff. | 15:50.43 |
| | Hmm. At 72dpi, bitmaps win over RLEs in terms of space. | 15:53.45 |
| | 319K vs 590k cache size needed for first 100 pages | 15:56.05 |
| kens | Chrisl interesting factoid. Acrobat cares about the maxPoints in a glyph, if we declare it incorrectly, it won't show glyphs which contain more points | 15:59.53 |
| | Bug 694538 | 16:00.07 |
| | It doesn't seem to care about the number of contours though | 16:00.25 |
| | A N Other rip of our acquaintance also appears to care, GS/FreeType don't | 16:02.06 |
| chrisl | kens: Hrm, that's odd. I can remember why that other rip would care, but I'm surprised that Freetype doesn't, TBH | 16:03.41 |
| kens | Its what seems to be causing the problem. We have two different subsets of a TT font which we combine into oe font. For reasona I haven't yet fathomed, we use the maxPoints fomr the first one. The problem is the first subset only contains 3 glyph, relatively simple.... | 16:04.38 |
| chrisl | Oh, actually, maybe I do remember why Freetype will work - I think it ignores maxpoints and uses the numpoints from each individual glyph | 16:06.37 |
| kens | :-) | 16:06.48 |
| | I'm going to leave it until tomorrow now, I've been chasing this since this morning | 16:07.09 |
| chrisl | I think that other rip you mention allocates a buffer for the points when the font is loaded (based on maxpoints), and (potentially) reuses the same buffer for all the glyphs. | 16:08.31 |
| kens | Yes, I'm not objecting to the fact that it raises an error, just curious that FT doesn't | 16:09.15 |
| chrisl | I'm a little surprised it doesn't at least warn | 16:09.55 |
| kens | Makes sense, the font is supposed to be correct after all. Its pdfwrite making the error | 16:10.20 |
| chrisl | Of course, it's possible Freetype does warn, and something about our integration means the warning gets swallowed | 16:11.37 |
| kens | :-) | 16:11.53 |
| Robin_Watts | tor7: ping | 16:37.26 |
| | Speedwise it seems to be pretty much a wash between RLE or bitmap. | 16:37.43 |
| | (there may be scope for me optimising the n=4 case a bit to use ints/SWAR etc, but...) | 16:38.21 |
| | so I wonder if we should use bitmaps for small glyphs and RLE for large ones? | 16:38.42 |
| | (comparing speeds was done with an infinite cache) | 16:41.10 |
| Sicos | hi | 17:39.28 |
| ghostbot | hi, sicos | 17:39.28 |
| Sicos | does somebody overhere know if it is possible to find words in a pdf document with ghostscript? | 17:39.54 |
| | What I want to do is detect special words and convert them to hyperlinks | 17:40.07 |
| Robin_Watts | Sicos: It is possible. You would have to use the text extraction device. | 17:42.07 |
| | But I question whether gs is the best tool to do this with. | 17:42.18 |
| | I think mupdf would be a better starting point. | 17:42.49 |
| Sicos | well actually i want to use it on html files... at the moment I use wkHtmlToPDF for that. It makes clickable links and workds perfect. But it isn't updated since the last 3 years | 17:43.24 |
| | I tried to rewrite wkhtmltopdf with QT but it seems that the author of wkhtmltopdf hacked the qt libraries to add hyperlink support | 17:43.56 |
| | and I want to keep everything as standard as possible and concluded that it can't be done with QT 5.1 | 17:44.26 |
| | not without hacking QT | 17:44.52 |
| Robin_Watts | If your intent is to look for a process that starts with a pdf file and produces a modified pdf file, then mupdf is a better starting point than gs. | 17:45.19 |
| | To use either gs or mupdf you would presumably have to have a stage that goes from html -> pdf first. | 17:45.49 |
| | What you use for that stage is up to you. | 17:45.59 |
| | although it would seem to be smartest to use a tool that doesn't throw away the hyperlink information present in the html if possible :) | 17:46.29 |
| Sicos | I probably am going to make a hack for qt but I first need to find a lott of time for that | 17:46.42 |
| Robin_Watts | There isn't going to be a 'quick' hack to do it with either gs or mupdf. | 17:47.07 |
| Sicos | and my c++ is a little bit rusty | 17:47.15 |
| Robin_Watts | Sicos: Neither gs oe mupdf use C++. | 17:48.05 |
| | Quick testing suggests that the RLE with 1Meg cache is a noticable win on J12 at 1200dpi, against non RLE with a 4 Meg cache. | 19:48.26 |
| | So RLE is a win for the NoAA case (in some cases a massive win). | 23:02.45 |
| | But it's a loss for the AA case. | 23:03.00 |
| | I'll need to do some profiling to see why. | 23:03.10 |
| | Forward 1 day (to 2013/08/27)>>> | |
IRC Logs