| | <<<Back 1 day (to 2018/01/14) | 20180115 |
| aiena2 | I am using gs to scale down a pdf page. It works but I want to scale down the contents of a page but still keep the page itself A4 can I do that? | 05:10.55 |
| | I am using http://paste.opensuse.org/56a7d379 params in my python code | 05:14.20 |
| kens | alena2 as before, Ghostscript doesn't simply 'modify' a PDF file, it produces a new one. The appearance should be the same, but the actual description of the page will not be. Elements can be dropped or altered. | 07:57.22 |
| | You can certainly alter the scaliong (and position) of the content while retaining the media size, but you will have to do some PostScript programming. | 07:57.51 |
| aiena2 | kens: I am sorry I meant produce a new one | 10:35.28 |
| | oh | 10:35.57 |
| kens | Not a problem, I just like to emphasise this point, because people are sometimes surprised when their PDF file changes | 10:36.06 |
| aiena2 | kens: yes. Well I dont expect to not have suprises for the simple reason that each implementation is different | 12:15.03 |
| | But Ghostscript overall does such a good job I am very pleased with it | 12:15.23 |
| kens | That's fair enough, as long as you understand what's going on behind the scenes, then you shouldn't get any unpleasant shocks | 12:15.46 |
| deekej | hello chrisl, we received a report about Standard Symbol PS having some different (wrong) charmaps for OTF version, compared to Type1 version | 13:17.06 |
| | I have reported this to (URW)++ already, so I hope they'll fix it, and send you the patch soon :) | 13:17.32 |
| | if you're interested in the details, they are here: https://bugzilla.redhat.com/show_bug.cgi?id=1534206 | 13:17.50 |
| chrisl | deekej: Type 1 fonts don't have a charmap | 13:18.26 |
| deekej | chrisl: ah, OK. In that case I don't know what's the problem described there... :-/ | 13:19.22 |
| | chrisl: maybe the reporter used wrong wording? | 13:19.40 |
| kens | Possibly, he's complaining the OTF fonts have broken char maps | 13:20.06 |
| chrisl | deekej: probably - the results he's posting don't look right | 13:20.23 |
| kens | I suspect he doesn't understand what he's doing | 13:20.28 |
| | Huh, he's posted a C program using FreeType | 13:20.54 |
| | I don't see how that program can work with a Type 1 font | 13:21.45 |
| | Maybe FT invents a charmap for a type 1 | 13:22.13 |
| chrisl | I think it does, yes. | 13:22.27 |
| | TBH, the only way to know for sure is to render the glyph from the two fonts and eyeball the results. | 13:23.15 |
| kens | It 'looks like' he's complaining the glyph index is different ? But that's not a bug. | 13:23.42 |
| chrisl | Well, the glyph index returned for the OTF font is 0, which *should* be the notdef | 13:24.15 |
| kens | Ah I see, I was looking at the wrong table | 13:24.35 |
| | It shouldn't be 0 true | 13:24.52 |
| kens | leaves it alone I have enough problems | 13:25.17 |
| chrisl | Well, maybe..... it's quite possible, based on what's presented there, that the Type 1 will render a .notdef from the index of 65 | 13:25.29 |
| | Hence why I say you really need to actually render the requested glyphs, and look at the results | 13:26.01 |
| kens | Well he appears to be feeding it 0x61 and assuming that's an 'alpha', which sounds wrong | 13:26.17 |
| chrisl | In the Adobe map? | 13:27.04 |
| kens | Dunno just looking at Standard Encoding | 13:27.29 |
| | 0x61 should be /a in StandardEncoding | 13:27.55 |
| chrisl | The unicode code is correct for alpha | 13:28.02 |
| kens | Yeah it is | 13:28.09 |
| chrisl | I think that's right for a symbol font | 13:28.23 |
| kens | I don't see a alpha in StandardEncoding | 13:28.28 |
| | But goodness knows what the default Encoding for the Symbol font is | 13:28.52 |
| chrisl | Custom | 13:29.14 |
| kens | It could be /a I suppose | 13:29.18 |
| | Looking at the Symbol Adobe font it looka likely | 13:29.31 |
| chrisl | dup 97 /alpha put | 13:29.43 |
| kens | That'll be it then | 13:29.52 |
| | Anyway, back to type 0 fonts with type 3 descendants. | 13:30.22 |
| chrisl | And the Type 1 does contain a "real" glyph for /alpha | 13:30.45 |
| kens | It might depend on what FT is using for the CMAP | 13:31.35 |
| | The TT tables (if present) or generating one from the CFF dictionaries | 13:31.55 |
| chrisl | It should be using the TT tables | 13:32.08 |
| kens | Suggests the CMAP subtable is incorrect then, or possibly it doesn't have a 3,1 table | 13:32.28 |
| | Or should that be 3,0 I can never remember | 13:32.42 |
| chrisl | We can wait and see what URW++ say | 13:34.28 |
| kens | :-) | 13:34.58 |
| chrisl | Mind you, I am dubious about the "Adobe" cmap, since freetype reports it thus: "2: synthetic, platform 7, encoding 2 language 0" | 13:35.14 |
| | synthetic?? | 13:35.18 |
| kens | That's the OTF ? | 13:35.36 |
| chrisl | Yeh] | 13:35.40 |
| kens | Odd. | 13:35.44 |
| chrisl | With the Type 1, it lists a 3,1 and 7,1 cmap, both labelled as "synthetic" which makes sense | 13:36.12 |
| kens | Yes that seems reasonable | 13:36.22 |
| | Does hte OTF actually have a CMAP ? | 13:36.29 |
| chrisl | Yes, two: 0,3 and 3,1 | 13:36.49 |
| kens | So Apple and Unicode, should eb OK then | 13:37.11 |
| chrisl | M$ don't list 7,2 in the OTF spec..... | 13:37.59 |
| deekej | sorry guys, I just got completely lost... :D Should I tell something more to (URW)++ from what you have discussed here? :) | 13:43.34 |
| chrisl | deekej: No, just leave it with URW++ - the reporter clearly doesn't know much about the different font types, *but* there is definitely something not right, and there should be enough for URW++ to go on | 13:45.11 |
| deekej | chrisl: OK, thanks :) | 13:46.24 |
| RobinWatts | Can someone text me StevePhillips mobile number please? | 23:05.45 |
| | someone smart would gave remembered to bring it with them, but I'm travelling by myself. | 23:06.28 |
| | sebras, chrisl: ^ | 23:08.08 |
| | ray_laptop:^ | 23:08.37 |
| | Forward 1 day (to 2018/01/16)>>> | |
Log of #ghostscript at irc.freenode.net.