We have open issues due to missing or buggy platform fonts for the standard 14 set. Continuing to use platform fonts will not solve this problem.
We should try to find some good open source fonts, if they are not good enough then we can look at other options, but we should at least try. -- John On 4 Mar 2014, at 12:38, Maruan Sahyoun <[email protected]> wrote: > John, > > I don’t understand why we do have to ship fonts. We didn’t ship fonts until > now but were dependent on platform fonts through AWT. So the situation won’t > change. > > For legal reasons we won’t be able to use the fonts Adobe uses and I doubt > that there are open source fonts which provide the same results. (rendering > quality, number of glyphs ….) so I think a mechanism to use platform fonts > and letting users register new ones similar to our current font aliases is a > better and more reliable option. > > BR > Maruan Sahyoun > > Am 04.03.2014 um 21:28 schrieb John Hewson <[email protected]>: > >> Maruan >> >>> what I was having in mind is something similar to Apache FOP’s auto detect >>> feature for fonts. >> >> Yeah, this looks good, we could use this for finding missing embedded fonts. >> >>> For inclusion these are some additional candidates >>> >>> https://fedorahosted.org/liberation-fonts/ (SIL licensed >>> http://scripts.sil.org/cms/scripts/page.php?item_id=OFL-FAQ_web&_sc=1#68092c0f) >>> http://dejavu-fonts.org/ (http://dejavu-fonts.org/wiki/License) >>> Croscore fonts >>> https://fedoraproject.org/wiki/I18N/Liberation_vs_Croscore_fonts >> >> Great, I’ll take a look. >> >>> I’d think if we can avoid bundling a set of fonts but use OS fonts and/or >>> allow people to use their own will help us in the long run as if the >>> quality is not inline with the ones used by Adobe Reader there will be >>> additional questions/issues/bug reports we are not able to resolve. >> >> We still need to ship a set of standard 14 fonts to solve the problems with >> platforms which don’t >> have these fonts or have poor quality substitutes. The ideal solution is to >> bundle our own high >> quality fonts and not depend on proprietary, platform-specific fonts. If we >> can’t do this for some >> reason (e.g. quality), then we can reluctantly make use of platform fonts. >> >> -- John >> >> On 4 Mar 2014, at 11:45, Maruan Sahyoun <[email protected]> wrote: >> >>> Hi John, >>> >>> what I was having in mind is something similar to Apache FOP’s auto detect >>> feature for fonts. >>> >>> doc: https://xmlgraphics.apache.org/fop/1.1/fonts.html >>> code: >>> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/ >>> >>> Fo inclusion these are some additional candidates >>> >>> https://fedorahosted.org/liberation-fonts/ (SIL licensed >>> http://scripts.sil.org/cms/scripts/page.php?item_id=OFL-FAQ_web&_sc=1#68092c0f) >>> http://dejavu-fonts.org/ (http://dejavu-fonts.org/wiki/License) >>> Croscore fonts >>> https://fedoraproject.org/wiki/I18N/Liberation_vs_Croscore_fonts >>> >>> >>> I’d think if we can avoid bundling a set of fonts but use OS fonts and/or >>> allow people to use their own will help us in the long run as if the >>> quality is not inline with the ones used by Adobe Reader there will be >>> additional questions/issues/bug reports we are not able to resolve. >>> >>> BR >>> >>> Maruan Sahyoun >>> >>> Am 04.03.2014 um 19:34 schrieb John Hewson <[email protected]>: >>> >>>> Hi Maruan >>>> >>>> Java provides access to platform fonts via AWT and does not reveal the >>>> paths to the fonts >>>> which it finds, so it is not practical to use platform fonts without using >>>> AWT. There have also >>>> been a number of problems with some unix platforms which lack some of the >>>> standard 14 >>>> fonts or which ship with poor quality substitutes. Ideally, PDFBox should >>>> produce the same >>>> result irrespective of which platform it is running on, much like Adobe >>>> Reader (excluding any >>>> missing embedded fonts, of course). >>>> >>>> I’ve had poor experiences in the past with the Nimbus family of fonts from >>>> URW++ but there >>>> are numerous factors (kerning, hinting, metrics, TTF vs Type 1) which may >>>> have changed since >>>> then. We should check out how well these fonts compare with the standard >>>> 14 used by Adobe, >>>> in particular whether or not the metrics actually match (I know that it is >>>> claimed that they do). >>>> >>>> -- John >>>> >>>> On 4 Mar 2014, at 05:48, Maruan Sahyoun <[email protected]> wrote: >>>> >>>>> Hi John, >>>>> >>>>> what about just using the platform fonts? If not then Latex uses the >>>>> URW++ fonts which were made available under the >>>>> http://www.latex-project.org/lppl license. (same fonts are used by >>>>> Ghostscript). Could check if the license is fine with ours. >>>>> >>>>> BR >>>>> Maruan Sahyoun >>>>> >>>>> Am 03.03.2014 um 21:20 schrieb John Hewson <[email protected]>: >>>>> >>>>>> Hi All >>>>>> >>>>>> I wanted to bring PDFBOX-1959 to the attention of the mailing list. >>>>>> PDFBox is ready to leave AWT font rendering behind as the JDKs rendering >>>>>> has proven to be buggy and we now have our own renderers for all font >>>>>> types in 2.0.0. >>>>>> >>>>>> Before we can do this we need to ship a set of standard 14 fonts with >>>>>> PDFBox as currently the system fonts are being used via AWT. We also >>>>>> need to provide a mechanism for the user to supply their own external >>>>>> fonts for cases where embedded fonts are missing. >>>>>> >>>>>> The main question is, what fonts should we ship? Some of the "free" >>>>>> fonts I've seen render very poorly, any suggestions? Furthermore, are >>>>>> there fonts under more restrictive licenses which we could ship? Apache >>>>>> does allow for such files to be part of a project under certain >>>>>> conditions. >>>>>> >>>>>> Also: Adobe has some font packs, e.g. Japanese, which we could point >>>>>> users towards. >>>>>> >>>>>> Cheers >>>>>> >>>>>> -- John >>>>> >>>> >>> >> >
