Re: permissiveness in FreeType for CFF fonts

[Chris Liddell]

On 21/03/2023 22:00, Claudiu Milea wrote:

Hi,

We encountered a few (potentially not fully compliant with the 
specification) CFF fonts (i.e. CIDFontType0) that have enough 
information to be rendered, but FreeType throws an exception due to not 
having both the `head` and the `cmap` tables.


"CFF" fonts don't have such tables. OpenType fonts with CFF outlines do.

A CFF interpreter shouldn't be reliant on information from them.

Chris

Re: Handling of OTTO/CFF CIDFonts

[Chris Liddell]

On 13/12/2021 17:44, Alexei Podtelezhnikov wrote:
> On Mon, Dec 13, 2021 at 12:17 PM Chris Liddell
>  wrote:
>> In the case of a font with CFF outlines, the "glyph index" should still
> be mapped through the CFF Charset.
> 
> The native CFF charset as well as the sfnt cmap's are supposed to be
> listed in FT_Face->charmapS. Do you want to activate the native one
> instead of the default Unicode?

Ah, I will look into that. Thanks.

Chris

Handling of OTTO/CFF CIDFonts

[Chris Liddell]

Hello Werner and all,

We've encountered a problem with our use of Freetype in mupdf.

We have a PDF with an embedded OTTO/CFF font that is used as a CIDFont
in the PDF.

Now, the way CIDFonts work in PDF is that the character code is mapped
through the PDF CMap, to get a "glyph index".

In the case of a font with TrueType outlines, that is the GID of the
glyph, so the TTF/OTTO cmap tables are ignored.

In the case of a font with CFF outlines, the "glyph index" should still
be mapped through the CFF Charset.

The problem we've is that, for a CFF CIDFont that comes from an OTTO
font, Freetype does not build the inverted Charset lookup that would be
used when we render glyphs.

This is all centred around:

cff_font_load() (with the "pure_cff" parameter)
cff_charset_load() (with the "invert" parameter)

and

cff_slot_load()


Basically, it looks like we need a way to tell freetype to still treat
the CFF fibt as a CIDFont, even if it started life as an OTTO. Now I
believe, in theory, the Charset and cmap table mappings are supposed to
be the same, but that is not always the case, so we can't rely on that
assumption.

So, firstly: Are we missing something obvious (or less obvious) that
would allow us to solve the problem?

Secondly, if not, do you have any suggestions/preferences about how to
solve it? We were thinking of something like an
"FT_PARAM_TAG_IGNORE_OTTO_FEATURES" parameter flag or similar, but don't
want to embark on that in case you folks have an approach you'd prefer.

Thanks,

Chris

Re: Announcing FreeType 2.10.3

[Chris Liddell]

On 12/10/2020 18:00, Chris Liddell wrote:
> On 12/10/2020 17:47, Alexei Podtelezhnikov wrote:
>>
>> > So, we've had a report that building Ghostscript against Freetype
>> > 2.10.3 fails because FT_CALLBACK_DEF() has been moved to internal
>> > use only.
>> >
>> > Ghostcript supplies callbacks for memory management
>> > (i.e. FT_MemoryRec) and we used FT_CALLBACK_DEF() for those, which
>> > seemed logical when defining callbacks!
>>
>> Looks like an oversight to make it internal.  Fact is that this macro
>> is not publicly documented...
>>
>>
>> The internal description suggests that this is a placeholder for
>> __attribute__((fastcall)) and __atribute__((cdecl)), which we do not use
>> ourselves.
>>
>> > Is there now an alternative way to do that?  Or should we just
>> > switch to explicitly declaring them static?
>>
>>
>> Would ghostscript like to use those attributes?
> 
> I don't see any compelling reason for us to do so.
> 
> As I said, I'm quite happy just changing our callbacks to be directly
> declared static functions. I just want to check that's what's intended,
> and that there isn't a replacement for/alternative to FT_CALLBACK_DEF()
> that we should be using.

So, in the absence of any alternative guidance, I'm going with the
change to explicitly define the gs/ft callbacks as static.

Chris

Re: Announcing FreeType 2.10.3

[Chris Liddell]

On 12/10/2020 17:47, Alexei Podtelezhnikov wrote:
> 
> > So, we've had a report that building Ghostscript against Freetype
> > 2.10.3 fails because FT_CALLBACK_DEF() has been moved to internal
> > use only.
> >
> > Ghostcript supplies callbacks for memory management
> > (i.e. FT_MemoryRec) and we used FT_CALLBACK_DEF() for those, which
> > seemed logical when defining callbacks!
> 
> Looks like an oversight to make it internal.  Fact is that this macro
> is not publicly documented...
> 
> 
> The internal description suggests that this is a placeholder for
> __attribute__((fastcall)) and __atribute__((cdecl)), which we do not use
> ourselves.
> 
> > Is there now an alternative way to do that?  Or should we just
> > switch to explicitly declaring them static?
> 
> 
> Would ghostscript like to use those attributes?

I don't see any compelling reason for us to do so.

As I said, I'm quite happy just changing our callbacks to be directly
declared static functions. I just want to check that's what's intended,
and that there isn't a replacement for/alternative to FT_CALLBACK_DEF()
that we should be using.

Re: Announcing FreeType 2.10.3

[Chris Liddell]

So, we've had a report that building Ghostscript against Freetype 2.10.3
fails because FT_CALLBACK_DEF() has been moved to internal use only.

Ghostcript supplies callbacks for memory management (i.e. FT_MemoryRec)
and we used FT_CALLBACK_DEF() for those, which seemed logical when
defining callbacks!

Is there now an alternative way to do that? Or should we just switch to
explicitly declaring them static?

Cheers,

Chris


On 10/10/2020 17:49, Werner LEMBERG wrote:
> 
> FreeType 2.10.3 has been released.
> 
> It is available from
> 
> http://savannah.nongnu.org/download/freetype/
> 
> or
> 
> http://sourceforge.net/projects/freetype/files/
> 
> The latter site also holds older versions of the FreeType library.
> 
> See below for the relevant snippet from the CHANGES file.
> 
> Enjoy!
> 
> 
>Werner
> 
> 
> PS: Downloads from  savannah.nongnu.org  will redirect to your nearest
> mirror site.   Files on  mirrors may  be subject to  a replication
> delay   of   up   to   24   hours.   In   case   of  problems  use
> http://download-mirror.savannah.gnu.org/releases/
> 
> 
> --
> 
> 
> http://www.freetype.org
> 
> 
> FreeType 2  is a software  font engine that  is designed to  be small,
> efficient,  highly   customizable,  and  portable   while  capable  of
> producing high-quality output (glyph images) of most vector and bitmap
> font formats.
> 
> Note that  FreeType 2 is  a font service  and doesn't provide  APIs to
> perform higher-level features, like text layout or graphics processing
> (e.g.,  colored  text  rendering,  `hollowing',  etc.).   However,  it
> greatly simplifies these tasks by providing a simple, easy to use, and
> uniform interface to access the content of font files.
> 
> FreeType  2  is  released  under  two open-source  licenses:  our  own
> BSD-like FreeType  License and the  GPL.  It can  thus be used  by any
> kind of projects, be they proprietary or not.
> 
> 
> --
> 
> 
> CHANGES BETWEEN 2.10.2 and 2.10.3
> 
>   I. IMPORTANT CHANGES
> 
>   - New flag `FT_OUTLINE_OVERLAP'.  If set, make the smooth rasterizer
> do  4x4 oversampling  to  mitigate artifacts  in pixels  partially
> covered  by  overlapping  contours.Note  that  this  at  least
> quadruples the rendering time.
> 
> If  a  glyph  in  a  TrueType font  has  the  `OVERLAP_SIMPLE'  or
> `OVERLAP_COMPOUND'  bit set,  FreeType automatically  selects this
> rendering mode.
> 
> 
>   II. MISCELLANEOUS
> 
>   - Using the  arcane method of  including FreeType header  files with
> macros like  `FT_FREETYPE_H' is no longer  mandatory (but retained
> as an optional feature for backward compatibility).
> 
>   - Support for  building the library  with Meson.  Building  the demo
> programs with Meson will follow in a forthcoming release.
> 
>   - Minor improvements to the B/W rasterizer.
> 
>   - Auto-hinter support for Medefaidrin script.
> 
>   - Fix various  memory leaks (mainly  for CFF) and other  issues that
> might cause crashes in rare circumstances.
> 
>   - Jam support has been removed.
> 
>   - In  `ftview', custom  LCD  filter values  are  now normalized  and
> balanced.  Unorthodox filters are still available through the `-L'
> command line option.
> 
>   - The GUI demo programs can now be resized.
> 
>   - Demo programs that accept command  line option `-k' can now handle
> function keys, too.  The  corresponding character codes start with
> 0xF1.  As  an example, the  POSIX shell syntax (accepted  by bash,
> ksh, and zsh)
> 
>   -k $'\xF3q'
> 
> emulates the pressing of function key `F3' followed by key `q'.
> 

Re: freetype/coverity

[Chris Liddell]

Sorry folks... hit the send button by mistake

On 13/02/2020 12:20, Chris Liddell wrote:
> Hi Werner,
> 
> On 04/02/2020 11:46, Werner LEMBERG wrote:
>>
>> Hello Chris,
>>
>>
>>> We use Freetype with Ghostscript. We have also been using coverity
>>> static analysis for quite some time, [...]
>>>
>>> Would you (mainly Werner, but others too) consider there to be value
>>> in us doing the same for Freetype?
>>
>> yes, this would be valuable!  Thanks for the offer.  I'm certainly
>> interested in seeing the results.
> 
> Cool, I'll look at at working it into our schedule.
> 
> From experience, there will be a lot of changes that will be small edits
> (making casts explicit, adding prototypes, adding "/ fall through */"
> comments to switch statements).
> 
> So, I would be inclined to setup a github repo, and point you guys at
> commits, which you can critique, pull, or redo as you see fit. But I'm
> willing to

(as this was supposed to say:)

 willing to fit in whatever (reasonable) workflow you'd prefer.

Regards

Chris

Re: freetype/coverity

[Chris Liddell]

Hi Werner,

On 04/02/2020 11:46, Werner LEMBERG wrote:
> 
> Hello Chris,
> 
> 
>> We use Freetype with Ghostscript. We have also been using coverity
>> static analysis for quite some time, [...]
>>
>> Would you (mainly Werner, but others too) consider there to be value
>> in us doing the same for Freetype?
> 
> yes, this would be valuable!  Thanks for the offer.  I'm certainly
> interested in seeing the results.

Cool, I'll look at at working it into our schedule.

>From experience, there will be a lot of changes that will be small edits
(making casts explicit, adding prototypes, adding "/ fall through */"
comments to switch statements).

So, I would be inclined to setup a github repo, and point you guys at
commits, which you can critique, pull, or redo as you see fit. But I'm
willing to

Chris

freetype/coverity

[Chris Liddell]

Hi all,

We use Freetype with Ghostscript. We have also been using coverity
static analysis for quite some time, but during the last 4/5 months,
we've had a concerted effort to get our sources free of coverity issues,
and that finally happened in the last week or two.

We're now discussing whether to turn our attention to the libraries that
we incorporate of which, as I said, Freetype is one.

Would you (mainly Werner, but others too) consider there to be value in
us doing the same for Freetype?

Since, by default, we package with (most of) our dependency sources, it
would be trivial to include Freetype in the Ghostscript Coverity scan.

Regards,

Chris

Re: [ft-devel] Can freetype be more tolerant with this font?

[Chris Liddell]

On 07/01/2019 20:07, Alexei Podtelezhnikov wrote:
>>> I am testing with ftview and ftstring: statically linked - no
>>> problem.  dynamically linked - yes problem.
> 
> "make devel" defines T1_CONFIG_OPTION_OLD_ENGINE, which calls
> t1_decoder_parse_charstrings and it works.
> otherwise, cf2_decoder_parse_charstrings is called and it does not
> work. They do produce different outlines...

I added a comment to the bug (#55414), but since there's discussion
here, too, I figure I'll post it.

This change fixes the problem, as far as I can tell:

https://tinyurl.com/y8zcqsfm


It looks like a omission when integrating the Type 1 and CFF parser path
building calls.


Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] MultipleMaster: no setweightvector?

[Chris Liddell]

On 27/11/2018 21:25, Werner LEMBERG wrote:
> 
>> Revised (I fixed some/all(?) of the 2/4 space indent confusions):
>>
>> https://tinyurl.com/ydyx2sjs
> 
> Massaged and applied to git, thanks!

Thanks Werner, much appreciated.

Chris



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] MultipleMaster: no setweightvector?

[Chris Liddell]

On 26/11/2018 05:33, Werner LEMBERG wrote:
> 
 I'd like to add the ability to set/get the weight vector directly
 (FT_Set/Get_MM_Weight_Vector), [...]
>>
>> I've taken a first pass at this:
>>
>> https://tinyurl.com/yatcd4xn
>>
>> I'm sure I've messed up some coding standard, or API detail things,
>> so let me know if anyone has issues with it.
> 
> Coding is fine, thanks :-) While checking it in more detail I'll fix
> whitespace issues here and there (e.g., the indentation level is
> always two spaces, not four), but IMHO this is nothing you should
> worry about.
> 
> Some observations:
> 
> . I'm missing a diff for the API entry in `ftmm.h'.  Is this
>   intentional or an omission?

An omission: diff/patch mistake porting from the freetype in gs to the
current master branch.

> . You are talking about -1 as a return value of
>   `FT_Set_MM_WeightVector_Func'.  I don't see this in the code.
>   Additionally, the return type is `FT_Error' so it's not clear to me
>   what you mean with `return value'.

Leftover from earlier iteration of the patch, sorry.

> . The special handling of `*len' in `T1_Get_MM_WeightVector' needs
>   documentation, i.e., at least a comment.

See the missing ftmm.h changes!

Revised (I fixed some/all(?) of the 2/4 space indent confusions):

https://tinyurl.com/ydyx2sjs

Cheers,

Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] MultipleMaster: no setweightvector?

[Chris Liddell]

On 23/11/2018 16:44, Werner LEMBERG wrote:
> 
 I'd like to add the ability to set/get the weight vector directly
 (FT_Set/Get_MM_Weight_Vector), [...]
>>
>> I've taken a first pass at this:
>>
>> https://tinyurl.com/yatcd4xn
>>
>> I'm sure I've messed up some coding standard, or API detail things,
>> so let me know if anyone has issues with it.
> 
> Sorry for not responding earlier; I'll look at it in the next few
> days.

Not a problem, I just assumed you were busy.

Chris


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] MultipleMaster: no setweightvector?

[Chris Liddell]

On 21/12/2017 07:47, Werner LEMBERG wrote:
> 
>> I'm guessing setting the weight vector directly isn't included
>> because it wasn't originally part of Adobe's MM usage.
> 
> Maybe.  Another reason was probably the goal to have a uniform
> interface for both MM and GX fonts.
> 
>> I'd like to add the ability to set/get the weight vector directly
>> (FT_Set/Get_MM_Weight_Vector), [...]
> 
> This is OK.
> 
>> If no one knows, or there was no such reason, then I'll put a patch
>> together.
> 
> Thanks for working on this!

I've taken a first pass at this:

https://tinyurl.com/yatcd4xn

I'm sure I've messed up some coding standard, or API detail things, so
let me know if anyone has issues with it.

Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Chris Liddell]

On 03/04/18 15:12, Alexei Podtelezhnikov wrote:
 We're currently experiencing a problem with FreeType 2.9 in
 conjunction with Ghostscript.  Some TrueType glyphs are rendering as
 if the hinting is broken, or points are being moved/dropped.
>>
>> Well, the good news is that the corrupted glyph rendering is resolved in
>> the current freetype.git HEAD code.
>>
> 
> This must be bug 52846 .

Seems extremely like it - I could bisect, but it didn't seem worth the
effort.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Chris Liddell]

On 02/04/18 16:04, Werner LEMBERG wrote:
> 
>> We're currently experiencing a problem with FreeType 2.9 in
>> conjunction with Ghostscript.  Some TrueType glyphs are rendering as
>> if the hinting is broken, or points are being moved/dropped.
> 
> Interesting.
> 
>> If your projected timescale is later than this week that's probably
>> OK for us.  I hope we can at least isolate the problem this week and
>> then you can decide whether to delay releasing until we can propose
>> a good fix.
> 
> OK, will wait until you report.  There is no hurry :-)
> 
> And thanks in advance for your investigations!

Hi Werner,

Well, the good news is that the corrupted glyph rendering is resolved in
the current freetype.git HEAD code.

I found a couple of other changes in the output, but one is a (badly!)
broken font, and the other is almost certainly unique to the way
Ghostscript uses Freetype, and I can address that in our code.

So from a Ghostscript perspective, the current code looks good.

Chris


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Chris Liddell]

On 13/02/18 07:17, Werner LEMBERG wrote:
>>> Maybe we can announce in the forthcoming release that we are
>>> switching to C99 later on.
>>
> 
>> I have no objection to have some conditional parts for C99-specific
>> feature, but I feel negative with the total migration to C99.  "For
>> LLP64 platform except of Win64, C99 compiler is needed" would be
>> enough, if Pierre's guessing is correct.
> 
> Hmm.  Even the dinosaur called `emacs' moved to C99 a few years
> ago :-) While being conservative, it doesn't make sense in case
> everyone already moved on – I've looked into Wikipedia's C99 page, and
> it seems that there aren't any major compilers that don't support it
> (at least the very decent set of changes we would need or use).

The concern is installed bases of systems like AIX, HP-UX, OpenVMS that
haven't been updated in some time, and using the default C compiler.
With Ghostscript, we regularly get reports from such users (not to
mention Windows 95/98/ME, NT 4.0, OS/2, etc, etc - !).

It is odd that they insist on using obsolete hardware and operating
systems, but want the latest releases of other software!

Using C99 types, with sane fallbacks makes sense, but using the more
invasive parts of C99 (like mixing declarations and code) could be
problematic.

>> The usage of FT_UINT_TO_POINTER() macro is only used to store the
>> 32-bit integer (GID) into the storage of FT_List object directly.  I
>> feel it's overkill to close C89 support just to keep this method in
>> LLP64 on the platforms which we have not known their names yet.
> 
> I still vote for the possibility to change FT_UINT_TO_POINTER in a
> configuration file, for example with some code in `ftstdlib.h'.

I guess that would come under the heading of "sane fallback" mentioned
above.

Chris



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] MultipleMaster: no setweightvector?

[Chris Liddell]

I'm messing with Freetype's MultipleMaster Type 1 support, and I notice
there's no way to directly set the weight vector. That's a bit of a pain
because working backwards from the weight vector values really isn't
viable, and Adobe does let you set the weight vector directly.

I'm guessing setting the weight vector directly isn't included because
it wasn't originally part of Adobe's MM usage.

I'd like to add the ability to set/get the weight vector directly
(FT_Set/Get_MM_Weight_Vector), but before I do the work, and submit a
patch, I wanted to check if there was a specific reason such a call
wasn't included originally (other than not being part of the Adobe's
original MM support)?

If no one knows, or there was no such reason, then I'll put a patch
together.

Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Gone Redmond

[Chris Liddell]

On 21/09/17 14:24, Alexei Podtelezhnikov wrote:
> On Thu, Sep 21, 2017 at 3:32 AM, Chris Liddell
> <chris.lidd...@artifex.com> wrote:
>>
>>
>> My point was whether "dropping vc2005" meant just the VS2005
>> project/solution files, or whether it was something more entailed, for
>> example, switching to a requirement for full C99?
> 
> I am only interested in improving msbuild/vc toolbox support.
> 

Thanks, that's what I figured, but thought it worth checking.

It's a pain we have to keep using VS2005 for Ghostscript binaries, but I
still get occasional complains that we dropped support for Win95 - I
really can't face the deluge of complaints if we dropped Win2k thru
WinXP right now!

Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Gone Redmond

[Chris Liddell]

On 20/09/17 17:00, Alexei Podtelezhnikov wrote:
> On Wed, Sep 20, 2017 at 10:01 AM, Chris Liddell
> <chris.lidd...@artifex.com> wrote:
>>> - drop vc2005 and earlier support altogether as those compilers have
>>> reached their EOL.
>>> - drop wince as well since vc2012 and up supports wince
>>> - drop vc2008 next year
>>> - drop single-threaded configurations deprecated as of 2005
>>> - add dynamic library configuration
>>> - get freetype-demos to build
> 
> Not necessarily in that order :). I want to get or demo programs to
> build out of box on Windows first.


My point was whether "dropping vc2005" meant just the VS2005
project/solution files, or whether it was something more entailed, for
example, switching to a requirement for full C99?


Similarly, "drop single-threaded configurations": that's in terms of the
libraries linked in the VS builds, and not always requiring threading
support in the Freetype core?


>> we use our own build system to build the Freetype sources.
> 
> I would appreciate if your shared the project/solution and resource
> files for FreeType.

It's just a "simple" makefile, integrated into the Ghostscript build system:
https://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=base/freetype.mak

Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Gone Redmond

[Chris Liddell]

On 19/09/17 16:06, Alexei Podtelezhnikov wrote:
> Hi guys,
> 
> I will be doing some FreeType development on Windows 10 in this
> release cycle. It was surprisingly easy to set up the environment. I
> only needed two things:
> 1) Git for Windows, https://git-for-windows.github.io/, which comes
> with a bash shell and vi.
> 2) Build Tools for Visual Studio 2017,
> https://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017,
> which is a free minimal environment with msbuild and a compiler,
> without IDE.
> 
> I have managed to build the static library already in this environment
> and committed the first round of cleanups in the project file. The
> draft plans are:
> - drop vc2005 and earlier support altogether as those compilers have
> reached their EOL.
> - drop wince as well since vc2012 and up supports wince
> - drop vc2008 next year
> - drop single-threaded configurations deprecated as of 2005
> - add dynamic library configuration
> - get freetype-demos to build

When you say "drop vc2005 and earlier.." and "drop single-threaded
configurations" I assume you mean purely in terms of the
project/solution files and C library to which you link?

I ask as with Ghostscript we continue to use VS2005 (not really by
choice!)), and only use Freetype in single threaded environment. We'd
rather not add a hard requirement for threading, and we use our own
build system to build the Freetype sources, so changes to you Freetype
build won't directly affect a "normal" Ghostscript build.

Thanks,

Chris


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] new CFF engine

[Chris Liddell]

Hi Werner,

Looks like a very exciting development!

I'm just getting ready to do some testing in Ghostscript, and I noticed
a missing header inclusion. Trivial patch attached.

Cheers,

Chris


On Wed, 01 May 2013 20:11:31 +0200 (CEST)
Werner LEMBERG w...@gnu.org wrote:

 
 Folks,
 
 
 Adobe, in collaboration with Google, has contributed a new CFF parsing
 and hinting engine.  The last few months it was my job to fully
 integrate the code into FreeType, and I'm very pleased with the
 results.  Here are links to the relevant blogs:
 
   http://adobe.ly/12mJWGv
   http://google-opensource.blogspot.com/2013/05/got-cff.html
 
 Look at the comparison images :-)
 
 Below are the relevant parts of the CHANGES file (which also give
 details how to enable it); as you can see, there are also a bunch of
 improvements for ftview and ftdiff.
 
 I plan to release 2.4.12 in about a week.
 
 
   Please test and enjoy!  
 
 Werner
 
 
 ==
 
 
 - We have another CFF parsing and hinting engine!  Written by Dave
   Arnold darn...@adobe.com,  this work  has been  contributed by
   Adobe in  collaboration with Google.   It is vastly  superior to
   the old CFF engine, and it  will replace it in the next release.
   Right  now,  it  is  still  off by  default,  and  you  have  to
   explicitly select it using  the new `hinting-engine' property of
   the cff driver:
 
 ...
 #include FT_CFF_DRIVER_H
 
 FT_Library  library;
 int engine = FT_CFF_HINTING_ADOBE;
 
 
 ...
 FT_Property_Set( library, cff, hinting-engine, engine );
 
   The code has  a (mature) beta status; we encourage  all users to
   test it and report any problems.
 
 [...]
 
 - Using the `H'  key, it is now possible to  select the CFF engine
   in both `ftview' and `ftdiff'.
 
 - It is  now possible  to directly select  the LCD  rendering mode
   with the keys `A'-`F' in  `ftview'.  The key mapping for cycling
   through LCD modes  has been changed from `K' and  `L' to `k' and
   `l', and  toggling custom LCD  filtering is no longer  mapped to
   key `F' but to key `L'.
 
 - In `ftdiff',  key `x' toggles  between layout modes:  Either use
   the  advance width  (this is  new and  now the  default) or  the
   bounding box information to determine line breaks.
 
 ___
 Freetype-devel mailing list
 Freetype-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/freetype-devel

From 05a0da6fa15a4d424fcc4555bce8cc88b8b0ecd4 Mon Sep 17 00:00:00 2001
From: Chris Liddell chris.lidd...@artifex.com
Date: Thu, 2 May 2013 08:41:22 +0100
Subject: [PATCH] Add missing header.

src/cff/cffgload.c - add #include FT_CFF_DRIVER_H
---
 src/cff/cffgload.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/src/cff/cffgload.c b/src/cff/cffgload.c
index 7d62a9f..fc01d98 100644
--- a/src/cff/cffgload.c
+++ b/src/cff/cffgload.c
@@ -21,6 +21,7 @@
 #include FT_INTERNAL_STREAM_H
 #include FT_INTERNAL_SFNT_H
 #include FT_OUTLINE_H
+#include FT_CFF_DRIVER_H
 
 #include cffobjs.h
 #include cffload.h
-- 
1.7.10.4

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] controlling FreeType modules

[Chris Liddell]

On 06/09/12 07:05, Werner LEMBERG wrote:

Another example that I recently stumbled across (and haven't yet
investigated fully) is the rendering of notdef glyphs. For Truetype,
Freetype is (correctly) using the TTF notdef glyph (the empty
rectangle), but for Postscript/PDF/PCL/PXL, the notdef is a
non-marking glyph. So, in the event that we're using a TTF in a
PS/PDF/PCL/PXL context, we'll need a way to influence that
behaviour.


This sounds like a good candidate for a property of the truetype
module...


I think I have a workaround for now, but it would certainly be easier if 
it were supported in the library. I need to look more closely at how the 
Truetype module sets all this up, but it would probably be moderately 
easy to have GID 0 setup as a whitespace glyph.



My preference is to have a dual level API: where you might have a
simple high level interface, which includes the very simplest use
cases and hides the vast majority of the details of what the library
is doing from the calling app, and users need very little knowledge
to use it.  Then you have a low level API, where users need a lot
more knowledge of what they're doing, but they then have the ability
to access and influence a lot more of the behaviour of the library.


But this doesn't solve the problem of exposing internal structures to
the public...


The reality is that it means that the low level API will likely extend 
over time - as folks identify new aspects they want to interrogate or 
influence, we add functions to handle those to the API.


It's very much a compromise, but I don't think there is a right answer 
which doesn't end up reducing flexibility and increasing the change of 
the code being forked.


Alternatively, we could go a bit object oriented, so (almost?) every 
internal structure includes an accessor function pointer (I'd make the 
accessor the first entry in every relevant structure). Then we can 
change the internal representations any way we want, and just modify the 
accessor function to suit. We can also make additional information 
available through the accessor as required without superficially 
changing the API.



Also, a note on the fontconfig interaction mentioned: I'm not clear
on what that proposal involves, but I would urge against Freetype
interacting directly with fontconfig.  I feel Freetype should
continue to be purely a font scaling/rendering library, and
shouldn't get involved in font management, or other peripheral
functionality.


Basically, I agree.  However, the border between font objects and font
management is fuzzy.  For example, do you consider composite fonts
like Windows 7's `CompositeFont' objects or PostScript's `FontType 0'
fonts as something FreeType should handle?  I think it doesn't really
belong to FontConfig.  Instead, I can imagine a layer on top of
FreeType which handles such formats.


Hmmm, I haven't really looked into the Windows 7 CompositeFont things (I 
probably will have to at some point). By Postscript Type 0, I assume you 
mean a CIDFont which has been composed with a CMap? From a Ghostscript 
point of view, we handle all the Type 0 font stuff ourselves, so 
Freetype only ever sees the descendant fonts, but in general, I would 
consider combining the CIDFont with the CMap to be part of loading a 
font for use, so within Freetype's remit.


Having said that, given that you need a Postscript interpreter to really 
handle CIDFont/CMap combinations in the general case, I can't imagine 
there being much demand for it, so that may well be moot.


I just think that Freetype should remain an engine which takes a font 
from some source, and uses it to to create outline or bitmap glyphs. I 
would not like to see Freetype getting sucked into loading fonts by name 
(even if that was done by punting off the fontconfig), or gaining any 
kind of layout capabilities.


Chris



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Regression issue - CFF

[Chris Liddell]

On 08/08/12 23:07, Werner LEMBERG wrote:




If this looks like becoming more important, and no one else is up
for it, I can try to focus more time on the task.


Yes, it would be nice if you could work on this.  However, a malformed
font is a malformed font.  Actually, Ivan should send a bug report to
Adobe IMHO...  I don't think that the incorrect output of this Adobe
tool is intended.


I agree about it being a malformed font, which is one reason I haven't 
treated the issue with much priority.


I'm involved in a fairly large project just now, but I'll try to devote 
some proper time to the monochrome scan converter soon.


Chris


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Regression issue - CFF

[Chris Liddell]

This looks very much like a winding-rule issue. Despite Adobe's font 
documentation claiming that glyphs should be rendered with non-zero 
winding, the Adobe *font* scalers/renderers actually use even-odd.


This can be seen in CPSI (if anyone has access to it), by drawing a 
series of glyphs like the one in this example getting larger and larger.


They will start rendering as intended (with the bowl hollow) whilst 
the font renderer is rendering them into the glyph cache. At some point, 
the glyph gets too large to cache, and the glyph is converted to path, 
and rendered by the normal line-art rendering code, using a normal 
fill operation - which is non-zero winding, and glyph ends up drawn as 
Freetype does (with the bowl filled).


We (Ghostscript) also have an example of a font with at least one glyph 
like this.


In my experience, most other PS/PDF products that implement their own 
font rendering have also adopted the even-odd rule, for obvious reasons: 
a well formed glyph, that follows the spec will render correctly with 
either non-zero or even-odd, badly formed glyphs, like this example, 
will still render as intended (although, arguable, not correctly).



I've been periodically looking at revising the Freetype monochrome scan 
conversion code to optionally support even-odd, but I really haven't 
been able to dedicate the time to it to really make headway. (I believe, 
from the comments, that the grayscale renderer already supports even-odd).


If this looks like becoming more important, and no one else is up for 
it, I can try to focus more time on the task.


Chris


On 08/08/12 04:02, suzuki toshiya wrote:

I reproduced this issue by 2.4.6, 2.3.12, 2.3.0.
Although it would be an issue, I think this is NOT regression.

Regards,
mpsuzuki

Ivan Nincic wrote:

Hello Werner,

FYI: I ran into a discrepancy between how FT (latest) and Acrobat render
some CFF fonts.
It seem that the error is cause due to interpretation of the fill rule (even
odd vs. winding) or something like that.

The font file was generated with Adobe PaperCapture.

IvanN


-Original Message-
From: Ivan Nincic [mailto:inin...@pdftron.com]
Sent: Friday, April 13, 2012 10:50 AM
To: 'w...@gnu.org'
Cc: 'da...@freetype.org'; 'freetype-devel@nongnu.org'
Subject: Regression issue - CFF

Hello Werner,

FYI: I run into a regression issue with the latest FT (trunk) version.
Attached is a sample font. I don't claim that this is a valid font however
FT was able to render the file in 2.4.4 but not in 2.4.9.

IvanN




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Type 1 dictionary information

[Chris Liddell]

On 27/10/11 10:48, Werner LEMBERG wrote:
 [...]  For reasons I won't bore you with, we do need to be able to
 create a (fairly) valid Postscript type 1 font dictionary which can
 be seen by the Postscript interpreter.  We're only talking about
 Type 1 streams from PDF files, in Postscript jobs we have to
 continue to use the PS interpreter.
 
 Is there a difference between a Type 1 font coming from a PDF and a PS
 file?

Basically, we're seeing Type 1 streams from PDF files which are simply
broken Postscript, but are close enough to satisfy the simplified Type 1
specific parsing rules used in the likes of FT's parser (or the one used
in Acrobat.). So we're seeing streams, for example, that don't call
the definefont operator, or fail to prefix dictionary keys with a /,
leave objects on the operand stack they shouldn't and so on.

We know FT is happy with these things, because mupdf, xpdf, poppler and
so on all read the jobs fine.

It's increasingly a problem that people are generating PDFs with very
limited reference to the various specifications involved, and simply
hack it until it opens in Acrobat, xpdf or other random PDF viewer. The
vast majority of which are not built on a Postscript interpreter, so
they don't spot problems like these - then we (Ghostscript) get shouted
at because we do trip over these issues.

 Whatever, your idea sounds useful, so please provide patches.

Thanks, I'll get started on it properly - I didn't want to devote much
time to it in case it wasn't required/wanted.

Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Type 1 dictionary information

[Chris Liddell]

Hi Folks,

I'm looking at getting Type 1 font data *out* of Freetype to use in
Ghostscript - in other words, using FT to parse a Postscript T1 font stream,
and then retrieve the data to build a Postscript font dictionary for use by
Ghostscript.

At moment, I don't see public API call(s) to retrieve the font dictionary
data, but there are calls to retrieve the Private dictionary contents and
FontInfo dictionary contents - which I would think would be of limited use
without the rest of the font data.

So, is this something amenable to change?

Thanks,

Chris
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Type 1 dictionary information

[Chris Liddell]

On 26 October 2011 18:41, Werner LEMBERG w...@gnu.org wrote:

 
  So, is this something amenable to change?

 I'm not sure whether this really works.  While you get most
 informations from a `standard' Type 1 font with FreeType's parsing
 algorithm, there are examples like Adobe's `optima' family where this
 fails...

 In general, I hesitate to provide an API to data which can be
 sometimes incorrect...

 What exactly do you have in mind?


My thought was to provide an API call, for example,  FT_Get_PS_Font_Value(),
which would take (amongst others) an enum parameter which would identify a
dictionary key to return. That would mean the currently private type 1 data
structures can remain private, and would make it explicit that only a subset
of possible keys are actually available.

The problem we have is that there are now many more type 1 implementations
that are independent of a Postscript interpreter. As with the FT one, they
tend to be much more fast and loose with the Postscript syntax. As a
result, we're seeing PDF files with really broken Type 1 font streams which
most PDF consumers happily consume.

As we're already using Freetype for glyph rendering, it would make sense for
us to use it, rather than write our own or fork the FT T1 code. For reasons
I won't bore you with, we do need to be able to create a (fairly) valid
Postscript type 1 font  dictionary which can be seen by the Postscript
interpreter. We're only talking about Type 1 streams from PDF files, in
Postscript jobs we have to continue to use the PS interpreter.

Chris
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] AF_Err_Ok undefined

[Chris Liddell]

Hi Folks,

Hopefully, I'm not going nuts, but the updates to afdummy.c (on 
2011-01-23) added AF_Err_Ok for the return values, but didn't define it 
anywhere.


I assume there's a header file missing from the push?

Thanks!

Chris


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Proposal: add a raster specific allocation function to the memory management API

[Chris Liddell]

On 26/07/2010 05:32, Werner LEMBERG wrote:
 
 My intention would be to have the API call take a bitmap struct as
 it's parameter, [...]
 
 I assume that you want to implement a new API function, right?  For
 backwards compatibility it's not possible to alter the existing ones.

Yes. Actually, two new functions a (re)alloc raster and a free
raster - just in case calling applications implement a memory pool
specifically for raster data. They'd be added to the end of the existing
memory API structure so there'd be a chance of retaining binary
compatibility.

 Mainly, I wanted to check whether this type of capability would be
 seen as beneficial enough to warrant including, before I spend too
 much more time on it!  Especially as it is a change in the public
 API.
 
 It seems to be a change with only small modifications of the internal
 structures, and without any large size or speed impacts, so please go
 on!

Cool, thanks. I'll try to get to it this week sometime.

Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Proposal: add a raster specific allocation function to the memory management API

[Chris Liddell]

Hi,

I guess this is primarily aimed at Werner, but posted here for any
interested parties to comment.


I'd like to add a callback to the memory management specifically for
(re)allocating bitmap/raster memory.

My intention would be to have the API call take a bitmap struct as it's
parameter, and the allocated address would be added to the structure by
the function, with a return code to indicate success/failure. This would
allow Freetype consumers to have Freetype render directly into their own
buffers, with raster alignment suited to their own needs.

Using my own special interest as an example (use of Freetype in
Ghostscript), at the moment glyphs are rendered to a Freetype bitmap,
and are then copied, either into GS's own glyph cache bitmap, or to
other GS internal bitmaps depending on their end use. This is done for
two reasons, 1) because (partly due to the original integration)
Freetype is left largely in charge of the bitmap lifespan, and 2)
because Ghostscript uses and expects a different raster alignment.

By allowing the calling application, in this case Ghostscript, to know
it is allocating bitmap memory, and by allowing it to modify (well,
increase) the raster line alignment, we (and hopefully others) could
avoid copying entire bitmaps from Freetype bitmap memory to the
application's own buffer - in our case, enable us to insert the bitmap
directly in the glyph cache, or wherever it needed to go.

I did a little investigating, and a little experimenting, and the
Freetype rendering code (as of 2.4.1) seems fairly agnostic about the
raster alignment used, so hopefully the code changes required would be
relatively small - this is made easier since, I think, Freetype
currently uses what is probably the smallest reasonable alignment, so
any consumer will likely only ever want to increase it.

Mainly, I wanted to check whether this type of capability would be seen
as beneficial enough to warrant including, before I spend too much more
time on it! Especially as it is a change in the public API.

Thoughts, opinions, flames?

Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel