| | <<<Back 1 day (to 2016/01/19) | 20160120 |
| Robin_Watts | tor8: ping | 11:45.32 |
| pasqualm | Hi, I'm trying to download the latest binaries from http://ghostscript.com/download/gsdnld.html and seems that http://downloads.ghostscript.com/public/ is down, it has been down at least for the last two days | 12:17.38 |
| | Anybody can take a look to it? | 12:17.48 |
| tor8 | Robin_Watts: pong. | 12:20.30 |
| Robin_Watts | tor8: Hi. | 12:20.45 |
| | pasqualm: I can reach http://downloads.ghostscript.com/public/ | 12:21.01 |
| | tor8: commits on robin/master to address your concerns. Let me know what you think. | 12:21.18 |
| | pasqualm: what does downloads.ghostscript.com resolve to for you? | 12:21.52 |
| | I get 188.121.46.128 | 12:21.59 |
| tor8 | Robin_Watts: can the character types be moved from bidi.h into bidi-imp.h? | 12:22.47 |
| Robin_Watts | tor8: Looking. | 12:23.03 |
| tor8 | there's a stray comment at the end of bidi.h: /** @} */ | 12:23.18 |
| Robin_Watts | tor8: Yes. | 12:24.03 |
| tor8 | the BIDI_ enums, should they be prefixed FZ_BIDI_? | 12:24.09 |
| Robin_Watts | (They can be moved. I'll do that) | 12:24.14 |
| tor8 | fz_bidi_flags could be moved too, I believe | 12:24.36 |
| Robin_Watts | Dunno. I can do that if you want. | 12:24.40 |
| tor8 | BIDI_BIDI_H? | 12:24.51 |
| | FITZ_BIDI_H | 12:25.05 |
| Robin_Watts | fz_bidi_fragment_text takes flags as an input. | 12:25.08 |
| | hence the flags values are part of the public interface. | 12:25.22 |
| tor8 | ah, the flag argument is an int | 12:25.26 |
| | the @param comment says the flag is just passed on to the callback function | 12:25.48 |
| Robin_Watts | because it's an OR of the flags, so not strictly an enum value. | 12:26.05 |
| tor8 | which runs counter to how it's actually used, so the comment ought to be revised | 12:26.30 |
| | mixed tabs and spaces in the @param section | 12:26.49 |
| Robin_Watts | tor8: That comment is wrong. | 12:27.17 |
| | tor8: In which @param section? | 12:27.55 |
| tor8 | Robin_Watts: all of them | 12:28.17 |
| | and I believe you're using a tab width of 4? it seems so by the vertical alignment of the comments after BDI_S and BDI_WS | 12:29.12 |
| | odd use of /**< */ annotations :) | 12:29.38 |
| | the code that uses ucdn and remaps the bidi classes, etc looks fine | 12:30.22 |
| pasqualm | Robin_Watts: Thanks, I have checked http://downloads.ghostscript.com/ from a mobile connection and it's working, it must be a problem with the network of my company. dns resolves correctly, I will check it with communications. Thanks :) | 12:30.51 |
| Robin_Watts | pasqualm: No worries. | 12:31.04 |
| | tor8: I converted spaces to tabs and then tidied up - I missed some. I always use a tab width of 8. | 12:31.30 |
| | The /**< */ are doxygen things. There because that's what the picsel code I grabbed this from uses. | 12:31.56 |
| | OK, improved commit. | 12:34.01 |
| tor8 | Robin_Watts: in bidi-impl.h there's a comment "The files bidi.rc, and resource.h are distributed together with this file and are included | 12:41.17 |
| | in the above definition of software." | 12:41.17 |
| | and there are duplicated copyright lines | 12:41.58 |
| Robin_Watts | I will remove those lines. | 12:42.11 |
| tor8 | and the File: Bidi.h comment is rather useless | 12:42.13 |
| Robin_Watts | Ok, again, fixed commit. | 12:43.14 |
| tor8 | Robin_Watts: thanks, looking better. | 12:44.51 |
| | let me just pass it through git stripspace and then we can push | 12:45.06 |
| Robin_Watts | tor8: ok, have at it. | 12:45.13 |
| | You go blind to such things after staring at code for too long. | 12:45.30 |
| tor8 | ehem, funny comment "Original copyright notice from uint16_t reference implementation" :) | 12:47.35 |
| | I'll fix | 12:47.39 |
| Robin_Watts | ahem. Picsels code used "Unicode" as a type, and I globally replaced it, then swore a lot and manually changed the comments back. | 12:48.42 |
| tor8 | Robin_Watts: I wonder if uint16_t is the right type to use though... | 12:49.16 |
| Robin_Watts | All Picsels stuff uses 16bit values internally for Unicode. | 12:51.19 |
| tor8 | that's ... firmly stuck in the 90's unicode :) | 12:51.34 |
| Robin_Watts | I think if we were redoing it now, we'd use utf8, but at the time it was being written, using 16bit was the best we could come up with. | 12:51.52 |
| tor8 | I think this code should be using uint32_t (or just plain old ints) | 12:52.08 |
| Robin_Watts | I don't think there is anything that would stop us using larger values now. | 12:52.19 |
| tor8 | the basic algorithms should still work, and ucdn supports >16 bit code points | 12:52.24 |
| Robin_Watts | How big is the biggest unicode now? | 12:53.07 |
| tor8 | 21 bits | 12:53.42 |
| Robin_Watts | We need 8 bits for levels. We need 5 bits for classes. | 12:53.43 |
| | OK, so we can't pack all that into a 32bit int :) | 12:54.19 |
| | Shame. Would have been nice to avoid any mallocs :) | 12:54.44 |
| tor8 | Robin_Watts: avoiding the create_levels malloc? | 12:55.11 |
| Robin_Watts | tor8: Yeah, we currently create class and levels arrays. | 12:56.08 |
| | Possibly we could amalgamate those two. | 12:56.31 |
| malc_ | heh, conincidently comp.arch just finished another round of unicode discussion https://groups.google.com/d/msg/comp.arch/AKD94DVsATw/xRvdtg3NAAAJ | 12:56.52 |
| tor8 | Robin_Watts: or let the caller supply them | 12:57.45 |
| Robin_Watts | To avoid mallocing/freeing for EVERY block, we could pass in an fz_buffer for the code to work in. | 12:59.58 |
| | That way it'd get created at the start of the pass, would grow quickly to the maximum size required, and then would be freed at the end. | 13:00.21 |
| | That can be a future optimisation if profiling shows it's required. | 13:00.52 |
| rayjj | chrisl: thanks for thinking about the performance issue for cust 532. I just replied, but also cc'ed the file in case you want to get involved. | 13:12.56 |
| | (since it involves working with the simulator, you may not ;-) | 13:13.22 |
| chrisl | rayjj: the rest of today, and possibly tomorrow are going to be a bit hectic for me, but I'll take a look at it on Friday, unless you've already made good progress by then | 13:14.41 |
| rayjj | chrisl: OK, np. Since the font cache is working well on the HEAD code, if i confirm (in a bit) the same utilization on their simulator with UFST, I can set that font issues aside | 13:16.01 |
| | chrisl: thanks for mentioning the ICC clist writing, I will check that. | 13:16.35 |
| chrisl | rayjj: Like you, I doubt it is the ICC profiles, but hopefully that's not going to be hard to check | 13:17.33 |
| rayjj | chrisl: anything else that occurs to you, feel free to let me know. Email is preferred since it is easier to locate threads compared to here. | 13:17.34 |
| chrisl | rayjj: Looking at the file, though, there's only Helvetica that's not embedded, and that doesn't seem to be used much. Which would (I would think) preclude the UFST as a significant influence, since it's only used for the "resident" fonts | 13:19.16 |
| rayjj | chrisl: right. Just got the simulator running. Was too sleepy last night after getting it running and helping the kids on h/w (college level statistics required some quick skimming of my daughters book) but I woke up with my brain running so am back at it | 13:19.25 |
| | chrisl: OK, thanks for the info. If any FT oprimizations come to mind (since 9.06 which is their code basis) let me know. TIA | 13:20.27 |
| chrisl | rayjj: I don't *think* they are using Freetype (which I have berated them about), I *think* it's just the UFST or the old Artifex code | 13:21.21 |
| rayjj | chrisl: hmm.. I'll check that, but I thought that 9.06 pretty much defaulted to FT | 13:22.38 |
| chrisl | rayjj: it's still controlled by the build, and the cust 532 makefiles explicitly set FT_BRIDGE=0 | 13:24.40 |
| rayjj | chrisl: does it even use the FAPI interface, then ? | 13:25.51 |
| chrisl | rayjj: for UFST, yes | 13:26.06 |
| rayjj | (I already didn't see FAPI_char being invoked when I expected) | 13:26.15 |
| chrisl | rayjj: Even more strangely, Acrobat pre-flight reports that Helvetica *is* embedded, but Helvetica-Bold is not...... | 13:27.36 |
| | rayjj: FAPI_do_char is probably a better function to check - but you'll probably only see a very small number of calls to it | 13:30.11 |
| rayjj | chrisl: do you know where the non-FT rendering calls will be? I see zchar.c handling TEXT_PROCESS_RENDER but then ??? | 13:32.48 |
| chrisl | rayjj: there wasn't a "central" dispatch point for glyph rendering before. Each font type would have code to generate a path, and then a fill | 13:33.57 |
| rayjj | chrisl: I'm seeing it in ztype2execchar --sound reasonable ? | 13:34.29 |
| chrisl | Yes, these are probably Type1C - so T2 char strings | 13:34.54 |
| rayjj | chrisl: Ok, I see where it is calling gx_add_cached_char. That's probably enough for checking font cache | 13:39.59 |
| | chrisl: as you expected, I see FAPI_char being invoked when the font is Helvetica-Bold (the non-embedded case) | 13:47.33 |
| | chrisl: for the non-FAPI code, is type2execchar where the bulk of the rendering is done (for timing purposes ?) | 13:48.43 |
| chrisl | rayjj: I *think* so, but it's such a long time since I looked at the non-FAPI code. | 13:49.29 |
| rayjj | chrisl: OK, counts look close enough on the simulator, so I think the font_cache is working. 444 calls to gx_add_cached_char and 8827 calls to gx_image_cached_char | 14:04.09 |
| chrisl | rayjj: those sound like plausible numbers..... | 14:04.45 |
| rayjj | yep. And the clist tile cache is also similar 5878 "hits" 1493 writes to put the tiles into the cache for the bands. Since there are only 444 tiles that can be cached, the might be an area for improving | 14:08.50 |
| | but I'll have them gather times for the rendering of the character if I can be sure of what function does that. And I'll profile that raspberry with FT_BRIDGE=0 vs 1 | 14:10.23 |
| chrisl | rayjj: from configure, you can do "--disable-freetype" or edit the Makefile | 14:11.28 |
| rayjj | chrisl: thanks. I was just going to edit the Makefile :-) | 14:12.06 |
| | chrisl: is there anyplace that documents all of the with/without disable/enable ___=no configure options ? | 14:12.59 |
| chrisl | ./configure --help | 14:13.12 |
| rayjj | iirc, that's a flood | 14:13.42 |
| | off to get coffee and get the kids out of bed... | 14:14.10 |
| chrisl | Well, then use: ./configure --help | less ;-) | 14:14.48 |
| tor8 | Robin_Watts: okay, my need for formatting cleanups has been satisfied. results on tor/master. I also changed it to use 32-bit integers for the text arrays. | 14:14.57 |
| | Robin_Watts: I have a test epub with some hebrew mixed with russian, that's got some odd issues | 14:15.22 |
| | I also suspect that we should swap text-align: left/right depending on the paragraph top level direction | 14:15.54 |
| chrisl | disappearing for a couple of hours..... | 14:18.51 |
| malc_ | tor8: curious mix :) | 14:22.19 |
| tor8 | Robin_Watts: http://www.gutenberg.org/ebooks/18291 on page 3, the quotes don't match what firefox and calibre display. but they make a lot more sense in our implementation, which matches the plain-text display so I suspect PG's html markup is wrong somehow | 14:22.21 |
| | <body lang="he" dir="rtl"> the dir="rtl" is the likely culprit | 14:23.12 |
| malc_ | haha.. and it's translation from norwegian, jeg er uhm.. suprised ;) | 14:24.10 |
| tor8 | malc_: yeah, it's an odd one | 14:24.31 |
| | I admit I haven't looked for more than 10 minutes but I couldn't find much in the way of arabic and hebrew public domain texts :/ | 14:24.59 |
| | doesn't help that I can't read either of the languages | 14:25.06 |
| | in epub format, that is | 14:25.16 |
| malc_ | tor8: maimonides writings might be available... he wrote in arabic and i bet threw in a lot of hebrew | 14:26.15 |
| tor8 | Robin_Watts: commits on tor/master | 14:58.22 |
| | Robin_Watts: so, on a 13k page document, the bidi stuff has added ~0.5s to the layout time | 15:13.31 |
| Robin_Watts | tor8: What's that as a percentage? | 15:25.11 |
| tor8 | 3% or so | 15:27.07 |
| Robin_Watts | tor8: Can't argue with any of those commits. good stuff. | 15:27.55 |
| | tor8: I think 3% is an acceptable price. | 15:28.06 |
| tor8 | Robin_Watts: yeah, I'm happy with that. | 15:28.51 |
| Robin_Watts | So, if we can get floaty images in before the release, that'll combine to be a nice boost. | 15:31.40 |
| | tables too, if we're lucky. | 15:31.50 |
| tor8 | Robin_Watts: agreed. | 15:31.52 |
| | Robin_Watts: do we want to squash any of these commits before pushing? | 15:32.55 |
| Robin_Watts | tor8: You could squash your fixups into my last fixup if you want. | 15:33.49 |
| | but I would be tempted to leave the import/refinement as separate commits. | 15:34.05 |
| tor8 | yes, import and cleanup make sense to keep separate | 15:34.20 |
| | in case we've cocked up somewhere :) | 15:34.28 |
| | Robin_Watts: so, squashed commits on tor/master | 15:35.36 |
| Robin_Watts | go for it. | 15:36.12 |
| tor8 | Robin_Watts: ta. | 15:36.26 |
| Robin_Watts | chrisl: Random gs makefile question if I may... | 16:36.33 |
| | AIUI, the idea now is that gs/pcl/xps all build on top of the same graphics lib. Is that correct ? | 16:37.05 |
| chrisl_x250 | Robin_Watts: yes, essentially. We don't create a "library", but we build one set of object files for the graphics lib, and then link them into the various exeuctables | 16:49.26 |
| Robin_Watts | chrisl_x250: Would it be possible to have a separate makefile target, just for that library? | 16:49.54 |
| chrisl_x250 | Robin_Watts: "Possible" yes, "easy", no | 16:50.34 |
| Robin_Watts | Ok. If we had such a target, then we could solve the problems with the msvc solution by using it. | 16:51.07 |
| | We'd have a lib project, and the gs/pcl/xps projects would all depend on it. | 16:51.22 |
| chrisl_x250 | Robin_Watts: I know, I did look at doing it, but it quickly spiralled out of sanity | 16:51.39 |
| Robin_Watts | chrisl: Fair enough. | 16:51.50 |
| chrisl_x250 | Robin_Watts: it is on my list to revisit, though | 16:52.17 |
| Robin_Watts | I see the problem with the stroking bug. | 16:52.58 |
| kens | That was quick | 16:53.09 |
| Robin_Watts | When we do 'accurate curves' we add an extra degenerate line segment onto the end of flattened curves so that the tangents are correct. | 16:53.45 |
| kens | Ah I had considered suggesting that as a solution | 16:54.03 |
| | TO the flat curves being incorrectly angled | 16:54.17 |
| rayjj | degnerates are often problems ;-) | 16:54.20 |
| Robin_Watts | As part of the stroking process, we keep 'notes' on the lines as to whether the segments came from a flattened curve or not. | 16:54.32 |
| | and the 'first' line of a curve is specially treated (cos we don't want to use the 'curve_join' when joining to it). | 16:55.20 |
| | Unfortunately when we add the degenerate line, it means that the 'first' line is now degenerate, so we skip it, and join to the second line. | 16:56.09 |
| | The second line isn't the first, and so we use the curve line to join to it. | 16:56.28 |
| | The fix is to make sure that when we add the degenerate first line, we leave the second line labelled as being the first. | 16:57.01 |
| kens | That doesn't cause any problems with the degenerate first line ? DOn't we have 2 lines labelled first now ? | 16:58.18 |
| Robin_Watts | kens: We do have 2 lines labelled first, yes. | 16:58.34 |
| | But the sole difference that that makes is in the join/underjoin handling. | 16:58.56 |
| kens | Umm, OK< sounds like a good idea to comment it though | 16:59.13 |
| Robin_Watts | and that won't matter. | 16:59.16 |
| | kens: I will do. | 16:59.24 |
| | (assuming the cluster test doesn't show something horrible) | 16:59.40 |
| kens | It sounds like exa\ctly the sort of thing I will trip over in a couple of years and go 'WTF ?' | 16:59.54 |
| mvrhel_laptop | bbiaw. | 18:31.49 |
| Robin_Watts | and the cluster test shows a problem :( | 19:03.06 |
| | Ok, so I have what I believe is a fix for the stroking problems. | 20:19.38 |
| | testing it is going to be a bitch though. | 20:19.46 |
| | Enabling accuratestrokes causes hundreds of diffs. It's hard to see the further diffs caused by the stroking fix in that noise. | 20:20.29 |
| | Forward 1 day (to 2016/01/21)>>> | |
IRC Logs