| | <<<Back 1 day (to 2015/05/05) | 20150506 |
| norbertj | hi guys, just for the logs: I indeed have modified the ghostpdl build to be multi-pdl.. Just took the ls-build make + some stuff from xps-build. So I now have an ghostpdl.exe/icon on my desktop with default -sDEVICE=display on which I can drop any file (pcl, pxl, xps ps, pdf). If you want I can send you the git-diff for this. | 06:14.37 |
| chrisl | norbertj: thanks for the confirmation. The problem is that the current l-s build is not what we'd call "production reliable" for Postscript and PDF. So we're (gradually moving towards) rejigging builds and APIs to make l-s more reliable and more flexible. | 07:03.58 |
| Robin_Watts | chrisl: Interested in: https://tour.markknopfler.com/ ? | 10:31.26 |
| chrisl | Robin_Watts: Been thinking about it - when/where were you considering? | 10:33.10 |
| Robin_Watts | chrisl: Well, by choice it would have been the albert hall, or brum, but the albert hall looks like 230 quid a ticket. | 10:34.26 |
| | The O2 is possible, but it's a real pain in the ass to get to. | 10:34.44 |
| chrisl | The problem with brum is that I have a tournament on the Sunday..... | 10:35.15 |
| Robin_Watts | Ah. | 10:35.30 |
| | I haven't checked with the boss either, so I'm not sure what dates I'm available for. | 10:35.45 |
| chrisl | If we did Birmingham, would you drive (from your place, obviously)? | 10:36.29 |
| Robin_Watts | chrisl: Probably, yes. | 10:37.45 |
| chrisl | If I could drive to your place, leave my car there, and share your car to brum and back, I could then head home that night. That would leave me shattered, but able to play on the Sunday | 10:39.19 |
| Robin_Watts | ok, I'm free on 22nd and 23rd. | 10:39.25 |
| | Sounds like the O2 might be easier for you though. | 10:39.41 |
| chrisl | Possibly, not sure..... | 10:40.35 |
| | It would depend on what time the concert would finish | 10:41.30 |
| Robin_Watts | The albert hall says: 19:30, and then it says: support at 7:30, main artist at 8:40. Show end 10:40 | 10:43.26 |
| norbusan | Hi everyone, I am back with some questions about CJK fonts and CID fonts. Ok to ask?? | 10:43.52 |
| Robin_Watts | Assuming it's the same timings at the O2, that's a 6pm start, so show over by 9:10 ? | 10:43.57 |
| | norbusan: On irc, always ask your question, don't ask to ask :) | 10:44.30 |
| | Otherwise you'll be waiting for ages for a reply, what with timezones etc. Do be prepared to hang around for answers though. | 10:44.55 |
| norbusan | Ok: We have set up all kind of CID fonts in OTF (OTTO) format and TTF format to work with CJK languages. | 10:45.01 |
| chrisl | Robin_Watts: I'd be surprised if the show finished by just after 9 - could be wrong, though. TBH, I'd be okay with either venue | 10:45.16 |
| norbusan | For Japanese (and eventuelly trad. Chinese) we would like to get vertical typesetting working. | 10:45.19 |
| | Now, it seems that for Japanese, when using OTF CID fonts the vertical typesetting does not work at all, while for TTF CID fonts it does work without problems. | 10:45.55 |
| Robin_Watts | chrisl: Well, brum would be considerably easier for me. | 10:45.56 |
| norbusan | The example we use is the article9.ps in the ghostscript distribution example directory. | 10:46.15 |
| | I have tested that with current git checkout (from 2 weeks or so ago). | 10:46.42 |
| | Anything known about this? | 10:46.50 |
| chrisl | norbusan: it's almost certainly because they way we load the OTF fonts means they don't include the vertical metrics, whilst the TTF fonts do | 10:47.38 |
| | Robin_Watts: I'm okay with brum | 10:47.55 |
| norbusan | Ahh, the thing about not loading the full font, thus not seeing all tables, thus also not being able to do auto-composition, right? | 10:48.17 |
| chrisl | Hmm, sort of, yes | 10:48.45 |
| norbusan | That also means that this is a long term project - not something one can fix from our side with some trickery. | 10:49.22 |
| chrisl | You could look at adding (IIRC) a Metrics2 dictionary to the font in Postscript, but you'd still have the problem of getting the correct metrics to include | 10:50.32 |
| norbusan | Ok. Thanks for the info. I just wanted to confirm. | 10:51.37 |
| | In case there is anything *we* (Japanese side - although I am not Japanese ;-) can do. please let me know. | 10:51.37 |
| chrisl | norbusan: have you checked when you load the fonts for vertical writing that the font is actually being loaded as a vertical font? | 10:52.20 |
| norbusan | How would one check this? | 10:52.38 |
| chrisl | The font dictionary should contain a WMode key, and the value should be '1' | 10:53.30 |
| norbusan | ok ... trying to test this ... | 10:54.53 |
| chrisl | note that WMode may be ignored if there aren't vertical metrics available... | 10:55.07 |
| norbusan | If you can give me a small code piece to check for that I would be happy ... | 10:55.50 |
| chrisl | To check for what? | 10:56.09 |
| | The WMode? | 10:56.22 |
| norbusan | What is the name of the font dictionary? | 10:57.29 |
| chrisl | Erm, I don't understand the question.... | 10:58.25 |
| norbusan | Ok, how can I check for the content of the dictionary of the font? I know how to print all keys/vals of a dictionary, but don't know how to apply this to the used font. | 10:59.01 |
| | ahh | 10:59.22 |
| | got it | 10:59.24 |
| | There is \WMode 1 | 10:59.34 |
| | with forward slash | 10:59.37 |
| chrisl | Right, so if you're not getting vertical writing, then it must be because there are not vertical metrics :-( | 11:00.04 |
| norbusan | \FontMatrix [1.0 0.0 0.0 1.0 0.0 0.0] | 11:00.37 |
| | \OrigFont -dict- | 11:00.37 |
| | \PrefEnc null | 11:00.37 |
| | \FontInfo -dict- | 11:00.37 |
| | \FMapType 9 | 11:00.37 |
| | \FDepVector [-dict-] | 11:00.38 |
| | \CMap -dict- | 11:00.38 |
| | \Encoding [0] | 11:00.39 |
| | \PathLoad (/home/norbert/gs/share/ghostscript/9.18/Resource/Font/Ryumin-Light-V) | 11:00.39 |
| | \FontName (Ryumin-Light-V) | 11:00.40 |
| | \FID -fontID- | 11:00.40 |
| | \WMode 1 | 11:00.41 |
| | \FontType 0 | 11:00.41 |
| chrisl | OKay, try this: http://pastebin.com/MU7YZiQW | 11:02.49 |
| | oops, there's a mistake in that.... | 11:04.44 |
| | Corrected: http://pastebin.com/wkYiMFwk | 11:05.04 |
| norbusan | Didn't do it on currentfont but /Ryumin-Light-V findfont ... then I got http://pastebin.com/x4Gn3fCN | 11:07.42 |
| chrisl | Yes, so no vertical metrics, hence no vertical writing | 11:08.59 |
| norbusan | ok. | 11:09.09 |
| chrisl | TBH, I'm not even sure that loading the OTF "properly" would fix that - Postscript metrics aren't the same as TTF metrics, so the tables might not be present, or might not be relevant | 11:10.09 |
| norbusan | Hmm, but it works for TTF metrics, and Ghostscript is a PostScript interpreter, ... so I would expect the other way round. | 11:11.07 |
| chrisl | But the *Postcript* metrics are not available in the *Postscript* font. | 11:11.55 |
| norbusan | Ah naruhodo ... (indeed...) | 11:12.22 |
| chrisl | We handle TTF in a "special" way - as we have to, since TTF isn't directly supported in Postscript (as mentioned before) | 11:13.13 |
| norbusan | I trust you completely in all these matters. I just try to get the most out for the CJK users for now, and see what is working and what is not supported for now. | 11:13.57 |
| | It is already fine if we *know* it, because I can document it and warn. | 11:14.08 |
| chrisl | So what we have here (as far as Ghostscript's font handling is concerned) is a CFF font without vertical metrics | 11:14.26 |
| | norbusan: the problem is that you are using substitutes for Postscript fonts - this stuff all works correctly if you use real Postscript CIDFonts | 11:15.27 |
| norbusan | stupid question: how do you find the horizontal metrices in case they are burried somewhere in the otf file? I guess there is no pre-defined *order* how the tables are arranged in the otf file. So it might happen that the horizontal metrices are also far down? No? | 11:15.40 |
| | chrisl: Might be, but what Japanese companies *ship* are these .otf fonts with embedded PostScript. There is no way for *us* around this. | 11:16.20 |
| | Should I contact Ken Lunde to kick the Japanese manufacturer? | 11:16.44 |
| chrisl | If they are shipping OTF fonts for use with a Postscript interpreter, they are doing the wrong thing | 11:17.22 |
| | As to your other question: The default horizontal metrics are implicit in the charstrings | 11:17.44 |
| norbusan | I guess they are not shipping the fonts for postscript interpreters, but for applicatins like Adobe InDesign etc. | 11:17.50 |
| | And they can work properly as far as I remember (never use any of these products, always TeX) | 11:18.23 |
| chrisl | Products like Indesign often position glyphs individually rather than rely on the internal metrics of the fonts | 11:19.00 |
| norbusan | Yes, probably. I am not sure either, but guess that dvipdfmx does take the vertical metrics into account, though. | 11:20.05 |
| chrisl | norbusan: and I'm not saying that it would be impossible for GS to handle it. But there is no spec for how a Postscript interpreter reads TTF or OTF fonts, or how it should use the results to substitute for a different font type, so...... | 11:21.33 |
| norbusan | Indeed. Don't get me wrong - it is great how much is actually supported, and we are grateful for that and all your work!!! | 11:23.02 |
| chrisl | Our OTF support is limited, and when I get time, I plan to improve it - but time is rather short just at the moment | 11:24.33 |
| norbusan | Fully understood! | 11:24.48 |
| | Thanks again! | 11:25.16 |
| chrisl | NP. sorry the news wasn't better (again!) | 11:25.31 |
| norbusan | No prob at all! Have a nice day, I am already at my evening whiskey (Japanese one, quite good!). | 11:33.42 |
| | Thanks again. | 11:33.51 |
| tor8 | Robin_Watts: argh! turns out whitespace *is* significant in CSS :/ | 13:12.47 |
| | had to rejig big chunks of the css parser to deal with that hairy issue | 13:13.01 |
| Robin_Watts | tor8: really? got an example ? | 13:13.14 |
| tor8 | ".foo.bar {}" is *not* the same as ".foo .bar {}" | 13:13.15 |
| Robin_Watts | oh, right, yes. | 13:13.24 |
| tor8 | first is parsed as *.foo.bar, the second as *.foo *.bar | 13:13.28 |
| | typical w3c crap :) | 13:13.47 |
| | patch on tor/master for review, but ideally sebras should rerun his batch of test files with this commit | 13:14.03 |
| | sebras: you around? | 13:14.08 |
| | he had assembled a big pile of (fairly garbage) epub files that we bashed our way through yesterday | 13:14.27 |
| Robin_Watts | tor8: will look after lunch. | 13:16.32 |
| kens | More clueless Indians.... | 13:53.57 |
| Robin_Watts | kens: They absolutely should be getting a support contract. | 13:57.56 |
| kens | http://en.wikipedia.org/wiki/GhostscriptI believe so as well, which is why I didn't really answer any of their questions | 13:58.14 |
| | I must stop pressing CTRL_I in Miranda when I mean shift-I | 13:58.35 |
| henrys | kens: that ati customer isn't using a valid email for miles needs to be miles.jones | 14:08.33 |
| chrisl | henrys: the shorter address *used* to work.... | 14:09.25 |
| henrys | chrisl: I don't see an alias in gmail admin | 14:09.59 |
| | chrisl: long time ago it was just miles | 14:10.25 |
| chrisl | henrys: I did say "used to...." | 14:11.19 |
| henrys | and I made my usual mistake of saying a name on IRC but I don't think we'll worry about this one. | 14:12.23 |
| chrisl | I'll not offer to edit the logs - I always seem to break it..... | 14:13.41 |
| henrys | 2 or 3 times a year we set up the artifex booth at a public show with all the customer names boldly on display so I'm not sure this policy makes a lot of sense. Talking about a customers specific problem would be inappropriate | 14:18.20 |
| chrisl | henrys: I thought a few (maybe previous) customer names were classified - hence easier to just avoid mentioning any than try to remember specific ones to avoid | 14:20.21 |
| kens | henrys, that would explai why Miles didn't get the email :-) | 14:22.45 |
| henrys | chrisl: right that's true but it's been years since we've had a customer with that status... | 14:22.47 |
| chrisl | 532? | 14:23.06 |
| henrys | kens: right I was going to say forward it on or I will... | 14:23.06 |
| kens | Well, I answered the questoin, and they seemed happy. Its probably better if they contact support for support queries anyway :-) | 14:23.39 |
| henrys | chrisl: pretty sure we've got a logo for them at the booth. | 14:23.47 |
| chrisl | I wasn't sure.... | 14:24.23 |
| henrys | maybe I should create an alias for miles at artifex dot com who knows how much business is going in the bit bucket due to that. | 14:28.01 |
| kens | I'd have expected they'd get a bounce | 14:28.22 |
| chrisl | kens: gmail seems adept at confounding expectations....... | 14:28.52 |
| kens | Yeah, silently bouncing stuff back to gs-devel... | 14:29.14 |
| chrisl | It's possible that it dropped into the admin mailbox | 14:29.58 |
| henrys | I sent a test but didn't get a bounce, we'll see if he gets it but I don't see how he would unless I'm missing something in the bowels of gmail admin. | 14:34.44 |
| kens | Did someone add a new test file 'Bug694293.pdf' to the tests run by the cluster ? | 15:14.53 |
| | Actually I guess not. Looks like its always been broken, its just slightly differently broken in my new code. | 15:16.07 |
| ManDay | There is a pdf which I parse with Ghostscript to modify the cropbox and before the conversion it is 8.2 megabyte, afterwards its 11 megabytes. I'd rather have it decrease it sinze. Does GS permit for any parameter which affects the size? I don't care about the few pictures in the document at all, they can all disappear for all I want | 16:46.14 |
| | the text of the pdf would probably be 2 megabytes. and there are only two pictures. it really shouldn't be 8 nor 11 megabytes | 16:46.53 |
| Robin_Watts | ManDay: You're breaking the PDFs down into graphical operators, and then reassembling them into completely new PDFs. | 16:51.11 |
| | A change in size is not surprising. | 16:51.19 |
| | Honestly, if all you want to do is to change the cropbox, then you're using the wrong tool. | 16:52.38 |
| ManDay | Robin_Watts: Hrm. | 17:00.45 |
| | Robin_Watts: yet, I think 9 of those 12 megs go into one graphic - let me upload the particular page | 17:01.26 |
| Robin_Watts | It's like moving a car from one garage to a bigger one by disassembling the car and reassembling it in a different place. | 17:01.39 |
| ManDay | the graphic, as it appears, is a plot and it's a vectorgraphic, with millions of components | 17:01.48 |
| | quite awful. | 17:01.53 |
| | have a look: | 17:01.55 |
| Robin_Watts | I have other stuff to do, sorry. | 17:02.40 |
| ManDay | Robin_Watts: If you can suggest a different tool... ? | 17:02.45 |
| Robin_Watts | i'd write something using mupdf. | 17:02.58 |
| henrys | ManDay:http://podofo.sourceforge.net/tools.html | 17:13.37 |
| Robin_Watts | tor8: I forgot those reviews. The ones I understand are fine. The ones I don't entirely understand seem plausible. | 17:24.29 |
| dyfrgi | I've been having trouble with a postscript getting cropped by ps2pdf. It has pages of variable size and the large ones wind up only showing the lower left part. They're rendered correctly by gv, though. I'm not sure where to dig to try to fix it. | 17:37.10 |
| | I pretty much always have this problem with files generated by dot -Tps2. I'm not sure if it's just those files or if it's a general pdfwrite issue, though. | 17:37.49 |
| ManDay | why does Robin_Watts say "all I want to do", though? I was actually told that changing the cropbox is more than Ghostscript should do with PDF - since PDF is only to be reprdouced as intended! | 17:52.25 |
| | henrys: thanks I'll have a look at that | 17:53.41 |
| Robin_Watts | dyfrgi: ps2pdf calls gs, and feeds in the postscript. | 17:55.16 |
| ManDay | henrys: I think podofo will not have a tool to set the cropbox on a per-page basis | 17:55.27 |
| Robin_Watts | gs converts the page marking operations into a pdf file using the current page size for each page. | 17:56.08 |
| | What you need to do is to tell gs the size of the pages you want to use. | 17:57.15 |
| | That may be tricky to do using ps2pdf. | 17:57.32 |
| | You might do better calling gs directly. | 17:57.40 |
| | but even then having the page sizes change for each page will be troublesome. | 17:57.55 |
| dyfrgi | Robin_Watts: Why would it come out wrong with pdfwrite and work fine in gv though? | 18:05.32 |
| | Before each beginpage, there's a %%PageBoundingBox comment and also a /PageSize pdfmark | 18:10.31 |
| | Man the page size is represented in like 4 ways | 18:11.26 |
| | %%PageBoundingBox, /PageSize, boxprim clip, and /CropyBox pdfmark | 18:11.51 |
| | I guess some of those set the size of page to render to and some set how to clip things within that page, and it's represented twice since one is for PS and the other is for PDF distillers (e.g. Adobe, pdfwrite) | 18:12.38 |
| | so perhaps just the pdfmark parts are messed up in some way and that's why gv works while ps2pdf does not. | 18:12.58 |
| Robin_Watts | dyfrgi: The %%PageBoundingBox things are comments. GV may pick them up. | 18:19.58 |
| | The guy who would know is kens, and he's gone for the day. | 18:20.14 |
| | Come back in about 16 hours? :) | 18:20.21 |
| dyfrgi | I can probably do 19 hours, think that'd work? | 18:21.45 |
| Robin_Watts | dyfrgi: yeah. he's here from 9-5 UK time, generally. | 18:22.00 |
| dyfrgi | Cool, thanks. I'll ask tomorrow morning then. | 18:22.21 |
| Robin_Watts | dyfrgi: We have a new gsview coming out. It would be good to get that tested with your file. | 18:23.11 |
| dyfrgi | Sure, I can test that, or provide a file. | 18:24.20 |
| Robin_Watts | gsview.com has downloads for the beta. | 18:24.37 |
| | Forward 1 day (to 2015/05/07)>>> | |
IRC Logs