Re: ttfautohint's functionality from the removal of the infinality patch

[Dave Crossland]

On Sun, 20 Aug 2023 at 17:41, Hin-Tak Leung 
wrote:

> On Sunday, 20 August 2023 at 18:28:54 BST, Dave Crossland 
> wrote:
>
> > Since almost all new fonts are vf, I'm no longer seeing ttfautohint in
> common usage, but I don't think it's effected by this.
>
> That's not necessarily true - people with poorer monitors are also likely
> to be less technically competent, and therefore unlikely to ever actually
> report any issues.
>
> (I am just saying that, it is actually quite dangerous and partial for
> people with expensive high-def monitors to decide what is and what isn't
> "generally" relevant ...)
>

Almost all new fonts are vf, and there are no libre tools for hinting VFs

Re: ttfautohint's functionality from the removal of the infinality patch

[Dave Crossland]

Since almost all new fonts are vf, I'm no longer seeing ttfautohint in
common usage, but I don't think it's effected by this.

Re: [ft-devel] OpenType in SVG support?

[Dave Crossland]

I'm curious if you have any updates on this? :)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] OpenType in SVG support?

[Dave Crossland]

Hi

Does freetype support OpenType in SVG fonts?

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

Re: [ft-devel] Patent info for LCD subpixel filter

[Dave Crossland]

In the photocomp era, may different machines were developed that produced
the same visual typography using different methods :)

On 2 September 2017 at 19:30, Behdad Esfahbod  wrote:

> At least in the English that I learned, two things that are not the same
> are different. So I find the claim that "they are more same than different,
> as such are not different" to be patently false.
>
> On Sep 1, 2017 11:47 PM, "Werner LEMBERG"  wrote:
>
>>
>> > I am contacting you to have some information regarding the patent
>> > for the LCD subpixel filtering.
>> >
>> > I am currently using the Skia library with freetype, and I noticed
>> > in your website that there is
>> > a patent regarding this feature, but it’s really unclear if it’s
>> > possible to enable it with no risks or not.
>>
>> Well, we can't answer this since we aren't lawyers.  We can only warn
>> that it the ClearType LCD filtering stuff is patented...
>>
>> > Will it be possible to have more information about it?
>>
>> Not from us, sorry.
>>
>> > Or is there a safe way to use the feature?
>>
>> The next release of FreeType will provide a different LCD sub-pixel
>> rendering method as the default (called `Harmony'), yielding
>> approximately identical results.  To our best knowledge the new
>> algorithm is not affected by any patents.
>>
>>
>> Werner
>> ___
>> 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
>
>


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

Re: [ft-devel] Font Validator 2.1 binaries.

[Dave Crossland]

Congrats on getting this release out there :)

On 15 August 2017 at 16:52, Hin-Tak Leung 
wrote:

> Finally got round to build the binary - just get
> FontVal-2.1.0-py-bin-net4.zip from
> https://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft%20Font%
> 20Validator/
>
> I recovered the test results I did almost a month ago from my old computer,
> on all fedora 26 shipped fonts - will upload at some point. Break-down is
> this:
>
> 3283 fonts examined in total
> 1493 fonts with CFF outlines (skipped for truetype hinting instruction
> check)
> 1395 fonts with truetype outlines passed
> 394 fonts with various degree of hinting instruction warnings/errors
> 1 zero-length font file, filed as https://bugzilla.redhat.com/
> show_bug.cgi?id=1473437
>Redhat had already shipped an updated
> font package (I have not re-tested yet).
>
> 1 + 394 + 1395 + 1493 == 3283
>
> i.e. roughly 400 (22%) out of 1800 of fonts with truetype hinting could do
> with some love on correcting the hinting instructions. Quite similar to a
> year ago.
>
> As you know the delay was due to computer broke and new computer, so
> please feel free to donate ( https://sourceforge.net/p/hp-
> pxl-jetready/donate/ ) . I want the Mac OS X binary to be as
> fully-featured (needs to build with a newer cross-compiler), so 2.1.1 will
> be a Mac OS X-specific release, whenever that might be.
>
> More details in the release notes about what changed in the last 12 months
> since 2.0:
> https://github.com/HinTak/Font-Validator/blob/master/Release-Notes
>
> I have decided to revert the "Windows-only problem fixed: can now accept
> non-ascii font name" change, because it causes intermittent (about 1 in 10)
> failures. So the binary is built to work for english font file names only,
> as it did for the release 2.0 a year ago. Sorry about that.
>



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

Re: [ft-devel] Fwd: Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

[Dave Crossland]

On Jun 14, 2017 1:59 AM, "Werner LEMBERG"  wrote:


Felipe,


> (I really miss a Freetype method to alter a single design-space
> coordinate, instead of having to pass the full array, by the way)

what API do you suggest?  Given that normally an application wants to
control *all* axes, it is not obvious to me where the benefits are, so
please elaborate.


In fontview or axis-praxis the ui is an array of sliders, and it is unusual
for a user to have two or more pointers and adjust 2 or more sliders at
once.

I'm guessing Felipe wants to pass a designspace coordinate delta, based
only on the user input for the single axis typically adjusted by the user.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] goodbye and thank you

[Dave Crossland]

Thanks for the kind note Graham! I love these bits of history :))

On May 24, 2017 6:33 AM, "Graham Asher"  wrote:

> I'm now leaving the FreeType development mailing list. My product,
> CartoType, still relies on FreeType for its typography and will always do
> so, but I can no longer keep up with the discussions and new versions; I
> haven't got time, and I haven't contributed any changes or suggestions for
> a long while. I have been using FreeType since about 1998, when I was
> working for Symbian Ltd., and my claim to fame (well, not fame exactly, but
> a very small part of history) is that I introduced scalable vector fonts to
> two operating systems, Symbian and Blackberry OS, both sadly no longer with
> us, and used FreeType to achieve that.
>
> Thanks to David Turner and Werner Lemberg and everyone else for creating
> and improving FreeType over so many years.
>
> Best wishes,
>
> Graham
>
>
> --
> Graham Asher
> founder and CTO
> CartoType Ltd
> graham.as...@cartotype.com
> +44 (0) 7718 895191 <+44%207718%20895191>
>
> ___
> 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] freetype-py python binding to FontVal's FreeType backend.

[Dave Crossland]

I love it

On Mar 29, 2017 8:48 AM, "Hin-Tak Leung"  wrote:

> 
> On Wed, 29/3/17, Werner LEMBERG  wrote:
>
> > Nice!  This essentially makes a command line
>  version of FontVal,
>  right?
>
>
> Yes, it is a python-based command line tool to run the FreeType-based part
> of FontVal,
> without any of the C# code.
>
> Hin-Tak
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] glyf (i.e. contour) analysis reports on libre fonts.

[Dave Crossland]

Thanks Hin-Tak! You did an amazing thing in the last year :D
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GX news

[Dave Crossland]

Hi

Wow, that's awesome!



On 16 July 2016 at 12:50, Werner LEMBERG  wrote:

>
> Support for GX in FreeType becomes better and better :-)
>
> Behdad has just fixed some bugs in the GX delta handling – now all
> glyphs from the infamous `Zycon' font are displayed correctly!
>
> I've just added support for the completely undocumented (but
> confirmed) `GETVARIATION' bytecode instruction – now instances from
> Skia.ttf get hinted correctly!
>
> Please test.  There still may be bugs lurking around.
>
>
> Werner
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>



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

Re: [ft-devel] Support for Cherokee

[Dave Crossland]

Great news! Thank you Werner!

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

[ft-devel] TTFAutohint Without TT Point Numbers

[Dave Crossland]

Hi

On twitter, Behdad said of ttfautohint control files,

"Any reliance on ttf point numbers is futile..."


- https://twitter.com/behdadesfahbod/status/719340420216434688

In response, I asked, how should type designers be hinting fonts these
days? :)

Behdad suggested we move the discussion to this list, and here we are :)

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

Re: [ft-devel] proposed enhancement to freetype for truetype diagnostics.

[Dave Crossland]

Thanks for keeping us informed! :)

On 10 February 2016 at 01:26, Hin-Tak Leung 
wrote:

> Hi,
>
> An earlier version of some of this was sent to Werner privately
> yesterday. I thought a bit more, and posted it as:
>
> https://github.com/HinTak/Font-Validator/issues/5#issuecomment-182210815
>
> So this is a head-up that something will happen in that direction.
>
> Hin-Tak
>
> ===
> Implementing the whole 60 errors and dozen warnings from the closed source
> MS renderer seems daunting; so I looked into what is achievable/possible.
> Last summer I collected the test results of the 2003 binary against the
> fonts in win 8.1. The errors and warnings shown is actually a very
> restricted set:
>
> warnings:
> 3066 Instruction is only valid on the Apple platform
> 3555 Projection and freedom vectors at or near perpendicular
>
> errors:
> 4 Instruction already defined by rasterizer
> 69 Not called from pre-program
> 885 Point out of range
> 22788 RP1 and RP2 have the same position on the projection vector
> 1243 X and Y components of vector are invalid. X^2 + Y^2 != 0x4000^2
>
> "Instruction is only valid on the Apple platform" was determined to be
> bogus in previous private discussion with Werner. Out of this small list,
> "RP1 and RP2 have the same position on the projection vector" seems the
> obvious one to look at, as it is much more frequent by far, 90% of errors
> by instances, and also by other metrices (fonts involved, etc).
>
> grep'ing for 'rp1' in freetype sources show that back in Feb 2013, a very
> localized change in Freetype was made to make it cope with such brokenness
> in fonts to match the MS renderer's exact behavior.
> (
> http://savannah.nongnu.org/bugs/?38211
> https://bugs.freedesktop.org/show_bug.cgi?id=16442
> http://savannah.nongnu.org/bugs/?40975
> )
>
> So here is a plan: at exactly the same condition, a diagnostics enhanced
> Freetype should abort and return an error detail, instead of silently
> carrying on and working around brokenness in fonts.
>
> This goes towards implementing a test on already fairly well-behaved
> fonts, to make them even better - there are much more serious brokenness, I
> am sure, but it is a beginning to start something.
> ===
>



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

Re: [ft-devel] Bengali support in FreeType ttfautohint

[Dave Crossland]

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

Re: [ft-devel] Myanmar support

[Dave Crossland]

On 14 December 2015 at 18:35, Behdad Esfahbod 
wrote:

> On 15-12-14 01:51 PM, Sascha Brawer wrote:
> > According to a Myanmar speaker here at Google, the autohinted version is
> > actually better (easier to read) than the manually hinted one.
> Congratulations!
>
> Cool!  Got screenshots?


https://rawgit.com/lemzwerg/noto-hinted/master/NotoSansMyanmar/index.html
:)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Announcing FreeType 2.6.2

[Dave Crossland]

On 6 December 2015 at 22:42, Nikolaus Waxweiler  wrote:

> Would you be willing to host the site on Github Pages?
>>
>> http://pages.github.com
>>
>
> Is this addressed to Werner?


Yes


> I personally would vote in favor of moving the FreeType site and main code
> repository to GitHub, simply because it's the most popular service with the
> largest user base and has nice things for running a project. I think this
> can make it easier for people to contribute to FreeType.
>

I agree :)



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

Re: [ft-devel] Announcing FreeType 2.6.2

[Dave Crossland]

On 1 December 2015 at 04:07, Werner LEMBERG  wrote:

> Basically, I don't object.


Would you be willing to host the site on Github Pages?

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

Re: [ft-devel] auto-hinter and base characters

[Dave Crossland]

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

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

[Dave Crossland]

Hi

On Aug 25, 2015 8:21 PM, Dave Arnold darn...@adobe.com wrote:

 I'm happy to see all of this activity on stem darkening in the past week.
It looks like excellent progress. I'm sorry it was a period when I was on
vacation and away from email. Hopefully, most questions have been answered,
but please let me know if there are outstanding issues that I can help with.

Thanks for all this, it's great stuff :)

 Here are some comments on questions that I saw in the thread that may
help.

 Yes, unhinted glyphs are darkened, too. The need to enhance contrast at
small sizes exists whether or not the glyph is hinted. There is a separate
control to turn off darkening, if that is needed.

 The CFF code is designed to darken by different amounts in horizontal and
vertical directions. The amount of darkening is determined by scaled stem
width, so in a high contrast font, horizontal stems are thinner than
vertical stems and need more darkening. In other words, the typographic
contrast is reduced at small sizes. (This is similar to what is done for
optical sizes.)

 There is a CFF feature called family blues that limits we darken
horizontal stems. I can provide more detail if you want, but this should
not apply to TrueType.

 As you noted, stdHW and stdVW are normally obtained from a CFF font
dictionary. For TT, we (at Adobe) estimate stem width values based on the
OS/2 weight class. We use three values, light (50/1000), regular (75/1000)
and bold (110/1000).

I'm confused about this. If a single style family had a weight class of 400
but it's stems are much more/less than 75, will that font be
darkened/lightened too much?

 If we darken TT outlines *after* hinting, we darken vertical stems only,
and we apply less darkening than we do for CFF. This is because the nature
of TT hints tends to darken horizontal stems at small sizes. (Consider a
scaled horizontal stem that is less than one pixel wide. Typically, the
hinting will snap it to a full integer pixel, effectively darkening it.)
The TT darkening amounts were tuned experimentally so the combined
darkening for CFF and TT looked similar.

 If we darken TT outlines *before* hinting (e.g., by the autohinter) I'd
expect horizontal and vertical darkening amounts could be computed
separately. I'm not sure how to best estimate the stdHW or the contrast,
though.

 It is necessary to know the direction of the paths in order to darken by
adjusting the path outward.
 While there is a recommended direction for both CFF and TrueType, some
fonts don't always follow it. There are three cases:
 1. All glyphs in the font have the wrong winding order. Some font
converters fail to reverse path direction when moving from CFF to TT or
back.
 2. Some glyphs in the font have the wrong winding order. Perhaps some
glyphs are produced as reflections?
 3. Some glyphs contain inconsistent subpaths; some are correct and some
are wrong.

 The CFF rasterizer contains code to compute the winding order direction
as the outline is traversed. If, at the end of the glyph outline, the
winding order is as expected, then nothing extra needs to be done. If the
winding order is wrong, then the glyph is re-rendered with darkening
reversed. And the expected direction for this font is reversed. This
means for case 1, above, only the first glyph pays a penalty. For case 2,
above, a few glyphs will be rendered twice. For case 3, (very rare) we
ignore the problem; some glyph components will be lightened instead of
darkened.

 Thanks.

 -Dave



 On 8/23/2015 9:14 AM, Werner LEMBERG wrote:

 A similar argument holds for `af_latin_metrics_init_widths': Only
 the stem width measured along the vertical axis is used for light
 hinting.

 Meaning, I'd have to modify AF_*Metrics to also compute stem widths
 on the horizontal axis and use that for stemWidth?

 I don't think so.  Since we don't want emboldening for the `strong'
 hinting mode (actually, we *do* want that, but this is a much harder
 problem to solve), you don't have to change anything along the
 horizontal axis.

 By the way, I can't directly access
 e.g. AF_LatinMetrics-axis-standard_width from my
 af_loader_compute_darkening() as I have only an AF_StyleMetrics to
 go from..  Is there a reason why standard_width is specific to
 writing class implementations of AF_StyleMetrics?

 I don't know.  Many of the details evolved over the time...

 The current subpixel hinting code should already be quite near to
 that goal.

 And what keeps it from being made the default mode for the native TT
 fitter?

 Behdad has answered that.  I haven't found time yet (and I probably
 won't in the very near future) to run a profiler on the code, fixing
 hot spots.  Maybe this is your follow-up project? :-)

 Oh, and what's that about subpixel hinting in
 af_loader_load_glyph()?

 For `light' hinting mode, you can ignore that.


   Werner

 ___
 Freetype-devel mailing list
 Freetype-devel@nongnu.org
 

Re: [ft-devel] max_instructions in ttfautohint

[Dave Crossland]

On 8 June 2015 at 18:37, Werner LEMBERG w...@gnu.org wrote:


  is that a rethoric question? ;-)
 
  No, quite serious :)

 How shall this work?  We have no influence on Microsoft...  It would
 be great if we could snip with the fingers, and the font guys there do
 a new release of the FontValidator immediately :-)


I have discussed with MS making a private distribution of the C# FontVal
source code to people who would like to work on a fresh derivative, which
MS would retain ownership of, but release under a simple permissive libre
license on Github.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] max_instructions in ttfautohint

[Dave Crossland]

On 8 Jun 2015 8:35 pm, Behdad Esfahbod behdad.esfah...@gmail.com wrote:

 On 15-06-08 05:21 PM, Dave Crossland wrote:
 
  On 8 Jun 2015 8:15 pm, Behdad Esfahbod behdad.esfah...@gmail.com
  mailto:behdad.esfah...@gmail.com wrote:
 
  On 15-06-08 03:57 PM, Dave Crossland wrote:
  
  
   On 8 June 2015 at 18:37, Werner LEMBERG w...@gnu.org mailto:
w...@gnu.org
  mailto:w...@gnu.org mailto:w...@gnu.org wrote:
  
  
is that a rethoric question? ;-)
   
No, quite serious :)
  
   How shall this work?  We have no influence on Microsoft...  It
would
   be great if we could snip with the fingers, and the font guys
there do
   a new release of the FontValidator immediately :-)
  
  
   I have discussed with MS making a private distribution of the C#
FontVal
   source code to people who would like to work on a fresh derivative,
which MS
   would retain ownership of, but release under a simple permissive
libre license
   on Github.
 
  Why not they straight releasing it on github?
 
  Specifically: It's linked to their rasteriser and they won't share
that, so
  publishing it as-is with the rasterisation parts removed wouldn't be
useful.
 
  Generally: at such old school companies who have yet to grasp the
opportunity
  costs of being precious with such things, it would be harder to get
internal
  approval for liberating anything outright compared to this method.

 So, same thing as Adobe ~1.5 years ago.  They need a *guarantee* that they
 will get contributions.  Which doesn't quite work.  Your best bet is to
show
 them that *any* piece of font-related code that has been open sourced has
got
 lots of contributions, starting on the day after it was released. :)

I'm not sure it is the same, but overall yes I agree, and I think attempts
by such companies to reduce their perceived risk and guarantee
contributions become self fulfilling prophecies that reduce contribution
because it makes their projects smell bad.

In this case ms isn't some mom and pop shop like Xara, they know full well
what they are doing, and this was the only way to salvage the sinking ship
that is fontval.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] max_instructions in ttfautohint

[Dave Crossland]

On 8 Jun 2015 8:15 pm, Behdad Esfahbod behdad.esfah...@gmail.com wrote:

 On 15-06-08 03:57 PM, Dave Crossland wrote:
 
 
  On 8 June 2015 at 18:37, Werner LEMBERG w...@gnu.org mailto:w...@gnu.org
wrote:
 
 
   is that a rethoric question? ;-)
  
   No, quite serious :)
 
  How shall this work?  We have no influence on Microsoft...  It would
  be great if we could snip with the fingers, and the font guys there
do
  a new release of the FontValidator immediately :-)
 
 
  I have discussed with MS making a private distribution of the C# FontVal
  source code to people who would like to work on a fresh derivative,
which MS
  would retain ownership of, but release under a simple permissive libre
license
  on Github.

 Why not they straight releasing it on github?

Specifically: It's linked to their rasteriser and they won't share that, so
publishing it as-is with the rasterisation parts removed wouldn't be useful.

Generally: at such old school companies who have yet to grasp the
opportunity costs of being precious with such things, it would be harder to
get internal approval for liberating anything outright compared to this
method.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] max_instructions in ttfautohint

[Dave Crossland]

On 8 June 2015 at 06:47, Cosimo Lupo cosimo.l...@daltonmaag.com wrote:

 And yes, FVal is very old — although the warning is in accordance with the
 TT and OT specs on the matter.


Is anyone interested in updating it?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] max_instructions in ttfautohint

[Dave Crossland]

On 8 June 2015 at 07:39, Cosimo Lupo cosimo.l...@daltonmaag.com wrote:

 is that a rethoric question? ;-)


No, quite serious :)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GX support now working

[Dave Crossland]

Hi

BTW, http://typedrawers.com/discussion/comment/12720/ :)

On 31 May 2015 at 06:38, Werner LEMBERG w...@gnu.org wrote:


 Folks,


 GX support should now work in general, please test!  At least with
 `Skia.ttf' I no longer see artifacts.

 Adam, I still have problems with two glyphs in `Zycon Regular', namely
 the cat and the lizard.  The shapes are heavily distorted if you move
 one of the two axes that are active for those glyphs.  As far as I can
 see, this is a problem in the font – is it possible that this small
 font is a demo only, with those two glyphs intentionally scrambled?
 Please compare the results on your old OS X machine for verification.


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




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

Re: [ft-devel] Arabic support in auto-hinter (and ttfautohint)

[Dave Crossland]

Hi

Great!! :)

On 12 March 2015 at 12:07, Werner LEMBERG w...@gnu.org wrote:


 Folks,


 I've just added support for the Arabic script in FreeType's
 auto-hinter and to ttfautohint.  This is experimental stuff!  Please
 test.


 Werner

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




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

Re: [ft-devel] ftgrid now supports MM (and GX) fonts

[Dave Crossland]

Having a gx demo font will be sweet!!
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Improved auto-hinter algorithm

[Dave Crossland]

Good stuff! The A is much better
On 12 Apr 2014 19:54, Werner LEMBERG w...@gnu.org wrote:


 Folks,


 I've just improved the recognition of strong points in the
 auto-hinter.  From the ChangeLog file:

   [autofit] Redesign the recognition algorithm of strong points.

   In particular, local extrema without horizontal or vertical segments
   are better recognized:

 + A+ D
  \/
   \  /
\/
 \  /
  \+ C
   \/
  B +/

   If the distances AB and CD are large, point B wasn't previously
   detected as an extremum since the `ft_corner_is_flat' function
   `swallowed' BC regardless of its direction, tagging point B as weak.
   The next iteration started at B and made `ft_corner_is_flat' swallow
   point C, tagging it as weak also, et voilà.

   To improve that, another pass gets now performed before calling
   `ft_corner_is_flat' to improve the `topology' of an outline: A
   sequence of non-horizontal or non-vertical vectors that point into
   the same quadrant are handled as a single, large vector.

   Additionally, distances of near points are now accumulated, which
   makes the auto-hinter handle them as if they were prepended to the
   next non-near vector.

   This generally improves the auto-hinter's rendering results.

 Please test!  Note that the same change has been applied to
 ttfautohint also; attached are two images that demonstrate the
 expected improvements for some fonts.


 Werner

 ___
 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] ttfautohint 1.00 has been released!

[Dave Crossland]

Congratulations Werner! This is a huge milestone! :)


On 23 March 2014 06:42, Werner LEMBERG w...@gnu.org wrote:


 http://freetype.org/ttfautohint

 ttfautohint 1.00 has been released.  It took me three years of hard
 work to finally present a version that I consider as usable for daily
 work.

 If you like my efforts, or can actually use ttfautohint in your
 business, please donate to the pledgie campaign at

   https://pledgie.com/campaigns/15816

 There you can also find my roadmap for future work.


   Thanks in advance :-)

 Werner


 ==


 The source tarball, statically-linked binaries for Win32 (TTY and GUI)
 and OS X (TTY only) are available from

 http://savannah.nongnu.org/download/freetype/

 or

 http://sourceforge.net/projects/freetype/files/ttfautohint/1.00

 Instructions to build the GUI version on OS X can be found at

 http://freetype.org/ttfautohint/osx.html


 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/


 --


 This project provides a library which takes a TrueType font as the
 input, remove its bytecode instructions (if any), and return a new
 font where all glyphs are bytecode hinted using the information given
 by FreeType's auto-hinting module.  The idea is to provide the
 excellent quality of the auto-hinter on platforms which don't use
 FreeType.

 The library has a single API function, `TTF_autohint'; see source code
 file `lib/ttfautohint.h' for a detailed description.  Note that the
 library itself won't get installed currently.

 A command-line interface to the library is the `ttfautohint' program;
 after compilation and installation, say

   ttfautohint --help

 for usage information, or say

   man ttfautohint

 to read its manual page.

 A GUI to the library is `ttfautohintGUI'; it uses the Qt4 framework.
 The compilation of this application can be disabled with the
 `--without-qt' configuration option.


 --


 New in 1.00:

 * Much less memory consumption while handling fonts with complicated
   glyphs.

 * Option `-s' was partially broken.




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

[ft-devel] Libre Graphics Meeting 2014: Call For Paper

[Dave Crossland]

Hi!

http://libregraphicsmeeting.org/2014/?p=199

The Call for Participation has now been published!

For this year we are especially interested in presentations that
showcase how the gap between technical and design development can be
bridged.

We are looking for:

In-depth presentations on Libre Graphics technologies
Showcases of excellent work made using Libre Graphics tools
New projects in this area to meet the wider community
Reports, use-cases, best practices
New emerging media; breaking free from analog constraints
Well articulated ideas for future approaches, tools and standards

Available formats are:

Lightning talk (10 minutes, selected at the event unconference style)
Presentations (20 minutes extendable to 40 minutes)
Entry for State of the Libre Graphics Union (1-2 slides)
Workshops (2 hours or more)
Birds Of a Feather (BOF), discussion meetings or Hackathons (2 hrs or more)

The 2014 Libre Graphics Meeting will be held April 2 – 5 in Leipzig,
Germany at Universität Leipzig.

Deadline for submissions: 15 January 2014

Selection notifications by: 25 January 2014 at the latest.

http://libregraphicsmeeting.org/2014/?page_id=165


The Libre Graphics Meeting 2014 will take place 2. – 5. April 2014 in
Leipzig, Germany.
This yearly event is an occasion for projects and individual
contributors/artists from all over the world to work together, to
share experiences and to hear about new ideas.

By Libre Graphics we mean Free, Libre and Open Source tools for
design, illustration, photography, typography, art, graphics, page
layout, publishing, cartography, animation, video, interactive media,
generative graphics and visual live-coding. The Libre Graphics Meeting
is not just about software, but extends to standards, file formats and
actual use of these in creative work.
We are looking for:

In-depth presentations on Libre Graphics technologies
Showcases of excellent work made using Libre Graphics tools
New projects in this area to meet the wider community
Reports, use-cases, best practices
New emerging media; breaking free from analog constraints
Well articulated ideas for future approaches, tools and standards

Available formats (including questions):

Lightning talk (10 minutes, selected at the event unconference style)
Presentations (20 minutes extendable to 40 minutes)
Entry for State of the Libre Graphics Union (1-2 slides)
Workshops (2 hours or more)
Birds Of a Feather (BOF), discussion meetings or Hackathons (2 hrs or more)

State of the Libre Graphics Union:
We will kick off this year’s event with a joint session that sums up
all things that have happened in our wide landscape over the last
year. Instead of slots in the schedule for general updates on each and
every libre graphics project, we invite you to submit a maximum of two
slides, show-casing new abilities and/or text enumerating the leaps
forward that your project made.

Special focus:
For the 2014 edition of LGM, we are specifically interested in
presentations that showcase how the gap between technical and design
development can be bridged. We are looking for contributions on
computational and generative media; examples of projects where design
decisions and experimentation is done directly with logic and code or
indirectly with the end user providing constraints/selection of good
results. We are interested in projects where design and development
are considered necessary ingredients in a collaborative process done
by peers of technological artists, using and pushing the constraints
of creative work.
Practical Details:

Call opens Monday 25. November 2014

Deadline: 15. January 2014. We will let you know if your presentation
is selected by 25. January 2014 latest.

In the context of the meeting, we prefer short and concise presentations.

For each BOF or meeting that will be on the public schedule, we ask
you to provide a report, to be made available to the Libre Graphics
Community afterwards.

If you propose a workshop, let us know what you expect participants to
bring, in terms of both prior experience and required items
(sketchbook, laptop with which applications installed, etc.)





-- 
Cheers
Dave

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

Re: [ft-devel] major autohinter change

[Dave Crossland]

Hi!

On 19 July 2013 17:50, Werner LEMBERG w...@gnu.org wrote:
 This is a major change which should improve the rendering results
 enormously for many TrueType fonts

Could you post a visual sample?

Will this improve ttfautohint?

--
Cheers
Dave

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

Re: [ft-devel] new CFF engine

[Dave Crossland]

On 1 May 2013 20:16, vernon adams v...@newtypography.co.uk wrote:
 That's look like good stuff.

 Will this new code also be integrated into ttfautohint library? :)

Its CFF so no

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

Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome

[Dave Crossland]

On 11 April 2013 00:54, Jungshik Shin (신정식, 申政湜) jungs...@google.com wrote:

 the issue appears to be in fontforge

I've started a ff bug for this at
https://github.com/fontforge/fontforge/issues/528

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

Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome

[Dave Crossland]

On 11 April 2013 01:35, Jungshik Shin (신정식, 申政湜) jungs...@google.com wrote:
 your bug description has misleading bits

I've read everyone again more carefully and updated
https://github.com/fontforge/fontforge/issues/528 - please let me know
if further updates are needed :)

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

Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome

[Dave Crossland]

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

[ft-devel] Nice TTFAutohint screencasts (Hebrew)

[Dave Crossland]

Hi!

TTFAutohint is compared to other hinting methods in screencasts on
http://openfonts.hagilda.com :-)

-- 
Cheers
Dave

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

Re: [ft-devel] Unit test environment for FreeType

[Dave Crossland]

On 27 November 2012 21:07, Werner LEMBERG w...@gnu.org wrote:
 Many of them are not freely available but are essential for
 testing.  Any idea how to handle this?

Like http://packages.debian.org/de/sid/ttf-mscorefonts-installer

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

Re: [ft-devel] first auto-hinter infinality patch added to git

[Dave Crossland]

Will this arrive in ttfautohint? :)

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

Re: [ft-devel] [autohint] improved handling of serif fonts

[Dave Crossland]

On 4 July 2012 20:15, vernon adams v...@newtypography.co.uk wrote:
On 4 July 2012 17:28, Werner LEMBERG w...@gnu.org wrote:

 please test the current git.  I have slightly changed the code in the
 auto-hinter which recognizes flat segments; it now accepts a broader
 group of shapes.  As a consequence, handling of serif fonts like
 Palatino or Quattrocento should be much improved.

 I have also imported this code to ttfautohint.

 I was hoping this would fix the 'Q-tail' effect, but it hasn't.
 Please see the tails on uppercase Q's at 17, 16, 15 px
 https://lh5.googleusercontent.com/-kA_3D758Iks/T_GZDZ5yIeI/D4E/9Fl0PH15BIY/s949/ubuntu-XP-firefox-ttfautohint-wgGD.png

Hmmm, yes. Diagonals are always tricky :-)

 i notice that file sizes of ttfautohinted fonts are only a slight
 % larger than the manual hinted originals now :)

That is really super news!

-- 
Cheers
Dave

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

Re: [ft-devel] [ttfautohint] stem width handling is now selectable

[Dave Crossland]

On 3 July 2012 12:09, Werner LEMBERG w...@gnu.org wrote:

 Hello Vern!


 In git, I've now fixed the situation displayed in your
 `Capture-G-win7GDI.png' image (showing Open Sans at 21px, please look
 at the ugly rendering of digit 3, for example): It was a buglet in
 FreeType's autofit module which didn't show up because of its smooth
 rendering algorithm.

 The old code contained both a (scaled) stem width of 95 and 97 units;
 for the strong stem width algorithm, the former was rounded to 1px but
 the latter to 2px.  The new code avoids this by unifying such almost
 identical stem widths, taking the mean value, 96.  As a threshold,
 widths which are different less than or equal to 1% of the em size are
 unified; this is certainly not noticeable visually.

Wow, that is a really substantial improvement :-) Well done Werner, bravo!

On 2 July 2012 06:43, Vernon Adams v...@newtypography.co.uk wrote:

 I maybe wrong, but I thought dw was found in explorer
 9 and Firefox 7+ but not the win system.

Yes, Win 7 has DW available but apps have to be rewritten to use it
(because the apps currently use the GDI API)

So we can expect that in Win 8 most of the MS apps will be using it,
but many 3rd party apps will take some time to change. Some maybe
never will.

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

Re: [ft-devel] [ttfautohint] stem width handling is now selectable

[Dave Crossland]

On 3 July 2012 20:58, Werner LEMBERG w...@gnu.org wrote:
 I prefer the human to the computer.

+1

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

Re: [ft-devel] [ttfautohint] stem width handling is now selectable

[Dave Crossland]

Hi

 it is the 'G' option that gave the only 'different' rendering
 i saw, and it's not overall better anyway

Hmm. Looks to me like Capture-G-win7GDI.PNG is the best of those 3,
though the c and e and some numbers have some issues, there are less
overall than the other 2.

Alas I think there is a desperate need for a much more advanced GUI
for this, which can generate images of sample texts in all the
rendering environments and present these images 2-up or onion skinned
and so on. Adam? :-)

Cheers
Dave

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

Re: [ft-devel] GDI ClearType support for ttfautohint available

[Dave Crossland]

I confirm this works on Mac OS X 10.7 Lino

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

Re: [ft-devel] Horizontal Stem Snapping in Autohinter

[Dave Crossland]

Wow, this is a very exciting development! Erik, thanks for all your
help with this :-)

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

Re: [ft-devel] ttfautohint: use native freetype on Mac OS X

[Dave Crossland]

Thanks! I really appreciate your contribute :-)

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

Re: [ft-devel] ttfautohint - latest source build error OSX

[Dave Crossland]

I support the use of pandoc.

Does it output texinfo?

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

Re: [ft-devel] [ft] ttfautohint now has a GUI

[Dave Crossland]

On 23 January 2012 19:49, Werner LEMBERG w...@gnu.org wrote:
 I agree that ttfautohint should continue to build the same as
 before, and additionally have a GUI.

 I don't like that.  Having two separate programs which do the same is
 problematic to synchronize.  As mentioned in another mail, I'll add an
 configuration option to be able to compile without Qt.

Okay, that sounds reasonable :-)

 I believe the command line application and GUI application should
 each link to a shared ttfautohint library.

 This is an option as soon as the TTFautohint library is stable enough.

Great! :)

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

Re: [ft-devel] [ft] FreeType License and patents

[Dave Crossland]

On 17 January 2012 09:25, David Turner di...@google.com wrote:
 An easier approach would be to ask for all future contributions to be
 covered by FreeType License 1.1,
 ...
 Apache2 is not compatible with GPLv2 notably because of this
 particular patent clause (that's the general agreement anyway -- some
 see GPLv2 as already having an equivalent clause, albeit less
 explicit). Apache2 is compatible with GPLv3, however.

 GPL is already not an issue since the original FreeType license is not
 compatible either (due to the credit clause). That's why we dual-license the
 library by the way. I don't see why anything would change with the proposed
 license update.

But its GPLv2 only :-(

Apache 2 is GPLv3 compatible.

So I'd suggest either using Apache 2, or using FreeType License 1.1
and GPLv2-or-later.

-- 
Cheers
Dave

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

Re: [ft-devel] [ft] FreeType License and patents

[Dave Crossland]

On 13 January 2012 20:13, Werner LEMBERG w...@gnu.org wrote:
 I would like to add something similar, with the exception that code
 especially marked as patented within the FreeType source code is not
 covered.

 Comments?

Why not just switch to Apache?

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

Re: [ft-devel] ttfautohint: The next round

[Dave Crossland]

Hi

What technology is best to implement the GUI with?

QT?

Web?

Cheers
Dave

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

Re: [ft-devel] ttfautohint: How to install

[Dave Crossland]

On 18 June 2011 04:42, Werner LEMBERG w...@gnu.org wrote:

 Please post a URL
 where I can download the Ubuntu font you've used.

http://font.ubuntu.com

 Of note is that at larger sizes (20px - 30px) the rendering breaks up
 on curves. Is it possible that the autohinter is not yet set to
 instruct those larger sizes?

 What do you mean with `breaks up'?

British sland for 'does not work well' :-)

 Please give more details what
 exactly you think is bad.  The hinting range is set to 8ppem-1000ppem,
 BTW, so these sizes are covered.

The original 'o' in Ubuntu appears more circular - more symmetrical in
both x and y directions - but the autohinted 'o' appears 'egg' shaped
with x symmetry but the top is thinner than the bottom.

 Overall it's looking good to me. There are specific issues at
 certain sizes, e.g uppercase bowls are flattening too abruptly at
 the cap-height, see 'O' at 15, 19, 21px, but i'm assuming these
 things can be tweaked away.

 Yes, this is what I've noted too.  I'll look into it.

Great!

-- 
Cheers
Dave

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

Re: [ft-devel] ttfautohint: How to install

[Dave Crossland]

On 17 June 2011 19:43, Dave Crossland dcrossl...@google.com wrote:
 A Verdana comparison would be nice! :)

Yet, on consideration, impossible, due to proprietary licensing
restrictions. What a pain! :)

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