I know I've come into this discussion very late - and the topic has moved on.
That said - I've had a lot of success in the interim with converting open type and true type fonts to type 1 using trans type pro by font labs and then repairing font tables using font doctor. I've only dealt with English fonts - but they work in postscript fine. Happy to provide further info if needed Thanks Martin --------------- Martin Edge --------------- On 20/01/2012, at 7:51 PM, Chris Bowditch <[email protected]> wrote: > On 20/01/2012 01:59, Craig Ringer wrote: > > Hi Craig, > >> On 19/01/12 19:54, Chris Bowditch wrote: >>> That's true of FOP trunk, but we have developed advanced font support >>> for Postscript in a branch named TTFinPostscript, which we've >>> successfully used to generate Chinese and Thai output. If you checkout >>> and compile the branch you can use the feature too. Although I believe >>> there are a few bugs which are fixed by a (as yet unapplied) patch in >>> Bugzilla. So if you run into a bug using the branch you will need to >>> apply the patch. >>> >> Ooh, that's promising. I'll check it out. >> >> (On a side note, I wonder if fop'll move to git at any point? >> Bugzilla-patch -> svn branch isn't the most fun workflow for >> non-committer contributors). > I know there's a lot of folks in favour of GIT. There's been a lot of > discussion on infra@ about moving Apache projects to GIT. Personally I don't > understand why GIT helps with applying patches. It's easy to switch your SVN > sandbox to the branch or create a new checkout from the branch. Applying the > patch is just a question of right clicking on the patch file and choosing > "Apply Patch" then running through the file list and clicking save if there > are no conflicts. There shouldn't be any conflicts, Mehdi prepared the patch > against the TTFinPS branch. > > To me GIT seems overly complicated for the day to day tasks of developing > against a handful of branches. > > Thanks, > > Chris > >> >>>> I'm working on implementing font subset merging in fop-pdf-image, or at >>>> least font re-embedding, but it's quite complicated to do and will take >>>> time, esp as I have to get this project out the door and working ASAP so >>>> I can't put too much time into that right now. I seem to be hitting >>>> another limitation whenever I find a workaround for one, though. >>> We've discussed this before. Mehdi sent Jeremias a patch offlist to >>> partially resolve this, but its only for fonts within the same input >>> PDF. If you have lots of smaller PDFs then the fonts won't be >>> de-duplicated. If you do get round to developing a more advanced >>> de-duplication then we'd love to see a patch :-) If you need Mehdi's >>> patch then feel free to yell and I'm sure Mehdi will happily post it >>> here. >> I'd love a copy, yeah. I'm not sure how much it'll help, as font merging >> across PDFs requires more information to be shared between image plugin >> invocations than is currently possible and requires image plugins to be >> notified just before the trailer and resource dict are written out, too. >> >> The biggest problem will be the logic of actually merging subsets, >> though. I'm finding it astonishingly hard to find good information on >> how fonts are actually subset for PDF - the PDF ref doesn't say much at >> all about how the actual embedded font file is altered for subsetting. >> >> -- >> Craig Ringer >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
