| | <<<Back 1 day (to 2016/10/22) | 20161023 |
| sebras | tor8 (for the logs): the commit for docs/naming.txt and the two first epub ones LGTM. | 06:01.42 |
| Robin_Watts | sebras: 3 bugs came in yesterday. | 09:33.23 |
| | 2 of which are to do with ligature stuff in the stext device. | 09:33.36 |
| sebras | Robin_Watts: aw, carp. some of that is in code I touched. :-/ | 09:35.17 |
| | Robin_Watts: I'm not sure what we can and should be doing for cahracters widths when not preserving ligatures. | 09:40.55 |
| Robin_Watts | sebras: split the width 50/50 between the two chars? | 09:41.28 |
| sebras | so bug 697236 really is two bugs. one being the extra space being inserted (by whom?), and the second one being the charcter width. | 09:41.35 |
| | Robin_Watts: or 1/3rd if it is ffi. | 09:42.02 |
| | perhaps. | 09:42.04 |
| Robin_Watts | Or (possibly even better), measure f and i, and split the fi width in the correct ratios. | 09:42.12 |
| | We want it to be as clone to being correct as possible, so that dragging selections looks natural. | 09:42.35 |
| sebras | can the pdf control characters width and by doing so _want_ to get negative space between characters? | 09:42.54 |
| | if so measurements of the characters do not make sense. | 09:43.10 |
| | Robin_Watts: oh.. and in all the back and forth about the STEXT bitfields I apparently set the default flags both for fz_device and fz_stext_device. but fz_device interprets these as ignoring images and shades I believe. | 09:46.01 |
| Robin_Watts | sebras: pdf can control the characters advance. | 09:52.02 |
| sebras | Robin_Watts: so, then it is not a simple matter of asking freetype. | 09:52.24 |
| Robin_Watts | hence if they wrote stuff backwards, you could get negative advance. | 09:52.37 |
| sebras | right. | 09:52.42 |
| | then I'd opt for doing 1/3rd | 09:52.50 |
| Robin_Watts | Well, for "ffi", say... | 09:53.25 |
| | imagine freetype says 40 for f and 20 for i. | 09:53.41 |
| | and the file says to use an advance of 130. | 09:54.15 |
| | then you could do 1/3 and hence use 43 43 43 | 09:54.47 |
| | or you could do 50 50 30 | 09:54.58 |
| | I suspect the latter would be better. | 09:55.12 |
| sebras | why wouldn't I do 40/(40+40+20)*130 40/(40+40+20)*130 20/(40+40+20)*130 ? | 09:56.00 |
| Robin_Watts | sebras: Yes. | 09:56.13 |
| | (which is almost 50 50 30, I think) | 09:56.24 |
| sebras | 52 52 26. :) | 09:56.30 |
| Robin_Watts | ok :) | 09:56.37 |
| sebras | but it got me thinking you were doing something else. :) | 09:56.45 |
| Robin_Watts | When writing backwards, (i.e. when advance is -130), then presumably we still output 'f' 'f' 'i'. | 09:57.12 |
| sebras | we do. | 09:57.28 |
| | so it'd be 40/(40+40+20)*(-130)... | 09:57.47 |
| Robin_Watts | so we'd need to do 'f' and advance 52, then 'f' and advance 52, then 'i', and advance -130. | 09:58.02 |
| sebras | it depends on who ligatures work. | 09:58.19 |
| | are they bidi? | 09:58.23 |
| | i.e. can they be? | 09:58.28 |
| Robin_Watts | I do not believe so. | 09:59.06 |
| sebras | Robin_Watts: do you know where I can see the general category for each unicode code point? | 10:25.00 |
| Robin_Watts | http://unicode.org/ ? or in the ucdn tables? | 10:26.13 |
| sebras | it is in the ucdn tables, but I'd need to write a program to look something up. | 10:26.33 |
| | http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt I'm interpreting the 3rd field as the general category there. | 10:26.57 |
| | seems to fit with A-Z at least. | 10:27.03 |
| Robin_Watts | bug 697234 seems to be down to t3 fonts being much slower than before. | 10:28.40 |
| sebras | ok.. so there is Lt "Letter titlecase" which might have been useful to distinguish ligatures. | 10:29.01 |
| | but the ligature ff 0xFB00 is categorized Ll which means "Letter lowercase". | 10:29.27 |
| | hrm... | 10:29.34 |
| Robin_Watts | Not sure about that. | 10:30.17 |
| | Lt looks to be stuff like "char + marking line" rather than just "char + char" | 10:30.46 |
| | I have a family this this weekend, so must run... | 10:31.04 |
| sebras | ok. | 10:31.11 |
| Robin_Watts | The big slowdown one looks like a font cache problem. | 11:51.25 |
| | 2nd and 7th char are supposed to be the same, but we don't find it in the cache. | 11:52.11 |
| sebras | Robin_Watts: hm... | 12:39.57 |
| | Robin_Watts: I think I see a mistake in fz_add_stext_char() | 12:40.15 |
| | Robin_Watts: when we preserve whitespace, or as it was from the beginning expand whitespace, we call fz_add_stext_char_imp() with ' ' to add a space. | 12:41.06 |
| | that seems fine to me, but we never return! | 12:41.13 |
| | doesn't that imply that we'll add a space and then the character. | 12:41.23 |
| | was this really what we wanted?! | 12:41.30 |
| | it seems to me like we should return, or simply set c = ' ' and continue; | 12:43.14 |
| | Robin_Watts: there's a proposed patch series on sebras/master | 13:48.45 |
| | Robin_Watts: it ought to fix the two stext bugs. | 13:48.55 |
| | Robin_Watts: I'd like for tor8 to rereview the first one too since it was he who wanted me to rename to PRESERVE before. | 13:49.23 |
| | it clusters and I hope I got everything right this time. | 13:49.46 |
| | Forward 1 day (to 2016/10/24)>>> | |
Log of #ghostscript at irc.freenode.net.