| | <<<Back 1 day (to 2016/02/24) | 20160225 |
| mvrhel_laptop | tor8: for the logs. wow that was quite a rework of the pdfcreate file..... | 00:34.55 |
| | tor8: it all looks good to me. the pdfcreate stuff is vastly simplified | 01:29.34 |
| | I probably spent a little too much time working on that.... | 01:29.54 |
| tor8 | kens: you around? | 10:34.35 |
| kens | yes | 10:34.43 |
| | Was just refactoring a program | 10:34.54 |
| tor8 | when embedding fonts in pdfwrite; how do you select the FontFile3 subtype? | 10:35.15 |
| kens | Oh and my internets seem flaky today, if I fall off hang around and I'll be back | 10:35.15 |
| | Hmm let me go look at that | 10:35.32 |
| tor8 | whether to create a Type1C, CIDFontType0C or OpenType | 10:35.36 |
| | I'm wondering if there's an easy way to check that from freetype | 10:35.50 |
| kens | Pretty sure we always create a Type1C | 10:35.52 |
| | We have code to create type1C fotns | 10:36.04 |
| tor8 | mutool create just embeds the incoming file; so I think we'll need to preserve the right type as well | 10:36.16 |
| kens | I doubt I can help there. | 10:36.49 |
| tor8 | kens: alright, thanks for clarifying what pdfwrite does anyway :) | 10:37.27 |
| | back to digging through the freetype docs... | 10:37.34 |
| kens | I'm not certain yet, nothing is that easy with ths code..... | 10:37.43 |
| | OK we never produce OpenType, type 1 is converted to Type1C, I'm not at all sure what we do for CIDFont with a type 0, I thnk we already know that from teh PostScript interpreter so we just emit it | 10:39.53 |
| | If you've got an example CIDFontType0C I can check what we do, it might be ugly | 10:40.43 |
| | OK yes we get the font type passed in from the front end, if its a 'ft_CID_encrypted;' then we emit it as a CIDFontType0C | 10:42.19 |
| tor8 | kens: right, so you either preserve the info or recreate a Type1C | 10:43.05 |
| kens | Yeah we make a new font but preserving the type | 10:43.34 |
| | For type 1 we convert to type1C | 10:43.52 |
| | FOr type 2 its already a Type1C | 10:44.04 |
| | A TrueType CID is handled differently. Presumably as TrueType | 10:44.26 |
| | Does that all make sense ? | 10:45.14 |
| tor8 | kens: yes, it makes perfect sense. | 10:45.28 |
| | not much help, but it makes sense :) | 10:45.37 |
| kens | I'm relieved, I'm not feeling like I'm being sensible at the moment | 10:45.55 |
| tor8 | I was hoping you'd have some tricks up your sleeve, but you cheat by writing the CFF data :) | 10:45.56 |
| kens | :-) | 10:46.02 |
| | Robin_Watts : did you expect all those pkmraw diffs with your change for pbmraw ? IIRC pkmraw is a 1 bit device so maybe that's expected ? | 11:36.37 |
| Robin_Watts | kens: I did. | 11:39.35 |
| kens | OK NP then | 11:39.42 |
| Robin_Watts | I discussed this at length with rayjj last night. I would have been happy with a change that affected only pbmraw, but ray agitated for a change that would affect all halftoned devices. | 11:40.20 |
| kens | I did read hte logs, but it didn't have much context for me | 11:40.42 |
| | Can you spare me some time to tell me where I'm being stupid Robin ? | 11:41.41 |
| Robin_Watts | No, no. I'm Stupid Robin. You're Stupid Ken. | 11:41.59 |
| kens | lknows that :-( | 11:42.14 |
| Robin_Watts | Sure. | 11:42.24 |
| kens | Probably better to do ths on artifex | 11:42.29 |
| | as its a customer | 11:42.32 |
| tor8 | Robin_Watts: ahem. mutool draw -Fpdf without a -o segfaults... | 13:06.50 |
| | Robin_Watts: mvrhel_laptop: the md5 checksumming for duplicate resources is very slow... mutool draw -Fpdf takes a very very long time when CJK fonts are used | 14:47.33 |
| | 97% of the time is spent creating md5 checksums | 14:47.47 |
| | we should probably hold a digest in the fz_font and fz_image resources for quicker access | 14:48.08 |
| | rather than recomputing the font checksum for each fill_text call | 14:49.00 |
| mvrhel_laptop | tor8: yes that would make sense | 16:20.04 |
| | Forward 1 day (to 2016/02/26)>>> | |
IRC Logs