Re: Memory safety for fonts & text

[Nikolaus Waxweiler]

Exciting :)

> lessons learned over the years

I have a feature request: please add stem darkening to Skrifa, in the
way FreeType's CFF driver does, for unhinted and autohinted output
(not sure what to do about hinted TTFs). Then, turn it on by default
and have Skia or Chrome do linear alpha blending and gamma correction
of text. Then we can finally have correct text rendering outside Qt.

Re: Dealing with different character map formats when mapping glyph indicies to character codes

[Nikolaus Waxweiler]

Hi Craig,
you should be able to trust the (Unicode) cmap sub-tables you find in a 
font to give you the intended Unicode character to glyph ID mapping. 
You can probably follow the logic in


https://github.com/fonttools/fonttools/blob/77a35fe16d07c16e3bb52863344df35520e9b770/Lib/fontTools/ttLib/ttFont.py#L806-L841

to determine which cmap to look at. I wouldn't try and do any overlap 
analysis in a first pass.

Re: Infinality removal (Freetype-devel Digest, Vol 209, Issue 11)

[Nikolaus Waxweiler]

I wonder how well it really matches? As far as I remember, it does
something superficially similar but the actual MS rasterizer works
differently?

Re: FontDebug: A new GUI app for freetype

[Nikolaus Waxweiler]

Hi Serdar,
Nice! Thanks for sharing, will take a look at some point.

Re: removing `ftrandom`?

[Nikolaus Waxweiler]

I didn't even know it exists 

Re: meson and logging support

[Nikolaus Waxweiler]

Another idea: have a look at what HarfBuzz is doing because they also
do a YES/NO feature summary thing:
https://github.com/harfbuzz/harfbuzz/blob/main/meson.build

Re: meson and logging support

[Nikolaus Waxweiler]

I suppose you could ask Meson people 
(https://mesonbuild.com/index.html#community) but I wouldn't get my 
hopes up. There's a reason Meson is lean and fast.

Re: meson and logging support

[Nikolaus Waxweiler]

> 
>> What message do you mean?
> 
> What are you referring to?

I was stumped by "I'm not completely happy about the message meson emits“. Do 
you mean the red „No“?

> 
>> I don't know meson well enough, but a quick skim of the Meson
>> offline manual and the one on https://mesonbuild.com show no easy
>> option to configure a project "from within".
> 
> It seems so.  Here I definitely lack the flexibility of autoconf...
> It's not clear to me why a 'NO' answer must always be coloured in
> red.  IMHO, red should be reserved for severe problems.

Hm. I can see Meson’s potential reasoning here. It’s much more sane to have 
Meson at the center of configuration, rather than having arbitrary config 
sources ;) It _does_ provide a mechanism to generate a header file with your 
chosen configuration.

Re: meson and logging support

[Nikolaus Waxweiler]

What message do you mean?

I don't know meson well enough, but a quick skim of the Meson offline 
manual and the one on https://mesonbuild.com show no easy option to 
configure a project "from within".

Re: animated vector font?

[Nikolaus Waxweiler]

I think you are responding to a spam generator 

Re: moving freetype-web to gitlab instance

[Nikolaus Waxweiler]

(With GitLab's CI, you don't need a 10 minute cron an can instead make CI
rsync every commit to master as it comes)

Re: Warning with the latest harfbuzz version

[Nikolaus Waxweiler]

Tested the new GitLab instance by doing 
https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/3


Next step: find out what it means for the code to not have a hard count 
of 2, as suggested in the HarfBuzz repo.

Re: Migrating FreeType to freedesktop.org

[Nikolaus Waxweiler]

Cool! Thanks for moving ahead with this and thanks to Anurag for 
instigating it ;)

Re: Commit ec9b6c314dc018bbf0af4ff657fa5ff56a5bf9f7 breaks existing programs

[Nikolaus Waxweiler]

Werks! Thanks!

Commit ec9b6c314dc018bbf0af4ff657fa5ff56a5bf9f7 breaks existing programs

[Nikolaus Waxweiler]

Hi!
Not sure if this is intentional or anything, but the aforementioned 
commit makes programs fail to render on Fedora 33. I.e. GTK3 apps spam 
the console with


(gnome-calculator:44487): Gtk-WARNING **: 23:32:19.658: drawing failure 
for widget 'MathWindow': invalid value for an input cairo_format_t


and don't render any UI. Can't run git master anymore :(

Re: [PATCH] [autofit] Fix double division in stem darkening.

[Nikolaus Waxweiler]

I guess that's similar to what was described in one of the Adobe CFF 
mails back in the days, where The renderer would use some darkening 
valuebased on OS/2 weight class or something.

Re: [PATCH] [autofit] Fix double division in stem darkening.

[Nikolaus Waxweiler]

Yes please! The big blockers are

1) how to get autohinter stem darkening as good as CFF darkening
2) how to darken natively hinted TTFs

Re: iVMS4200 silent install

[Nikolaus Waxweiler]

Wrong mailing list.

Re: Meson/Configure: different pkg-config file version number?

[Nikolaus Waxweiler]

Cool, thanks. Out of curiosity, where did the higher number come from? 
Why is it not the official version number?

Meson/Configure: different pkg-config file version number?

[Nikolaus Waxweiler]

Hi!
The freetype2.pc file generated by Meson carries the version number 
6.17.4 or something (the .so version number), but the one generated by 
configure says "Version: 23.4.17" -- who is right?


For what it's worth, some build systems like RetroArch's seem to look 
for the higher number and fail on 6.x.

Re: Meson build, continued

[Nikolaus Waxweiler]

I'll tell Werner that black is better, speaking in my capacity of a
professional python font developer!

@Werner: see above

Ps: thanks for doing meson work! Can't wait to see all other build systems
be dropped!

Re: Meson build, continued

[Nikolaus Waxweiler]

>
> PS: This introduces several python scripts, I have been using the "yapf"
> tool to format them. If you know of a better python reformatter, let me
> know.
>

Black It's the best

>

Re: upcoming raster changes

[Nikolaus Waxweiler]

If only we had a test suite with comparison images, we could see the 
effect these patches have immediately!

Re: Gitlab Migration Progress

[Nikolaus Waxweiler]

Any decision yet on whether it should be gitlab.com or freedesktop.org? 
My interaction with the CMake-install-info-file issue on Savannah just 
now made me wish we had a forge.

Re: Dropping Infinality

[Nikolaus Waxweiler]

I had a very quick look over all Infinality defines and I think the 
only value it adds is tweakability and some few very special edge case 
hacks.

Re: Dropping Infinality

[Nikolaus Waxweiler]

I think there is a niche community of users who rely on Infinality, but I'd
be in favor of dropping it anyway if it helps maintainability.

Re: Gitlab Migration Progress

[Nikolaus Waxweiler]

 Nice to see an effort on moving FreeType to a more modern UI :) Even
 if I wish GitLab would be (much) faster.


Really?  Obviously you have a more than excellent internet connection
to notice such things...



You probably mean GitHub 


Nope, GitLab :) We use it at work and I find it sluggish. Otherwise, 
it's good enough.

Re: Gitlab Migration Progress

[Nikolaus Waxweiler]

Nice to see an effort on moving FreeType to a more modern UI :) Even if 
I wish GitLab would be (much) faster.


I'm wondering when the issue migration is complete? Or am I missing 
something?


Also! Wasn't there a CI GSoC effort here somewhere.

Re: OVERLAP_SIMPLE or OVERLAP_COMPOUND

[Nikolaus Waxweiler]

Hm. Can't really say, but I have recently encountered a bug in InDesign
which subsets a VF for embedding into a document and turns it into a static
font... without removing overlaps or setting the overlap flags, leading to
even-odd rendering errors in macOS Preview. So I plan on modifying the
usual font pipeline to indiscriminately enable these flags for VFs... at
some point, unless someone stops me. So, yeah.

Re: OVERLAP_SIMPLE or OVERLAP_COMPOUND

[Nikolaus Waxweiler]

I mean use the script to set it  the usual compiler suspects don't set it
by themselves currently afaik

Re: OVERLAP_SIMPLE or OVERLAP_COMPOUND

[Nikolaus Waxweiler]

Try running the script in

https://github.com/TypeNetwork/Vollkorn-Typeface/issues/8#issuecomment-655791672

on a VF of your choice (e.g. Source Serif Variable is full of overlaps). Do
modify the OVERLAP_SIMPLE flag to 0x40 first, though. You'll need fontTools.

Re: [nkoo, N'KO identification issue on Ubuntu 20.04] (Re: Freetype-devel Digest, Vol 186, Issue 28)

[Nikolaus Waxweiler]

Hello,
please ask in a Ubuntu forum, this project is entirely unaffiliated 
with Ubuntu.

Re: [patch] Simplify ftconfig.h

[Nikolaus Waxweiler]

Would you consider dropping the ChangeLog entries. It is far simpler 
to rely on the git history for this, and just enforcing that commiter 
provide meaningful commit message should be enough?


Yes please. Alternatively, there are tools like 
https://pypi.org/project/towncrier/.


> Would you consider using clang-format to automate the formatting 
task? I think we can get pretty close to the FreeType formatting 
standard with a Clang style sheet. It won't be 100% the same, but close 
enough to avoid repetitive work.


YES YES YES. It is _so_ nice to just hit a format hotkey. It's become 
so automatic for me that I rarely think about formatting anymore.

Re: [patch] Simplify ftconfig.h

[Nikolaus Waxweiler]

Meson has a check-dist thing built in. Just saying 

Re: Overlap oversampling

[Nikolaus Waxweiler]

I have 0 idea actually. I think macOS triggers different rendering 
automatically when it encounters any OVERLAP_* thingy.

Re: Overlap oversampling

[Nikolaus Waxweiler]

Random thought: Test with Cascadia Code 
(https://github.com/microsoft/cascadia-code/releases/tag/v2007.01). The 
(variable) font is very Lego-like in its construction.

Re: GSOC Build tests

[Nikolaus Waxweiler]

> I did have some issues with Mac/iOS builds as your repo seems to
 > have an iOS.cmake that is 6 years old and incompatible with modern
 > xcode and I had so set a blank signing key for OS X.  I found a
 > newer iOS.cmake to replace your current one and it seems to work
 > however it does not currently bundle the binaries in the packaging
 > stage.  Please let me know if you have better solution for either 
of

 > these.

 Maybe other people can chime in who have more experience with cmake.

That's the kind of issues you will get all the time with CMake, there 
are 10 different versions of the tool being used in the wild, which 
are mostly similar,
but it's very hard to get CMake modules from third-party libraries 
that work well for everyone (especially when cross-compiling with 
different sysroots,
many will pick up the wrong headers / versions of the module's 
dependencies due to subtle configuration issues)


Also one of the reasons why I'm not a huge fan of CMake, even if it's 
the "standard".


Unfortunately, I don't have a solution for the iOS issue you describe.


I think I was the last person to do major (?) changes to the 
CMakeLists.txt file, just to build it for freetype-py. I saw the iOS 
files but did not update them, as I don't have a way to build for iOS. 
Honestly, is anyone compiling FT for iOS themselves? Maybe the entire 
support can be cut out to focus on higher value targets?


Regarding X CMake versions, I'd advocate for setting the minimum 
supported version higher. Like, 3.10 or something. The build system is 
not officially supported (according to last time I spoke to Werner 
about it, haven't followed recent conversations), so I think nailing 
the project to wide compatibility there makes little sense.

Re: Build system considerations

[Nikolaus Waxweiler]

Also note different optimisation levels. The make system uses -O2 by
default.

Re: Build system considerations

[Nikolaus Waxweiler]

First off: all of this sounds fantastic! I always love when stuff is deleted :)

> In the end, and this is personal opinion, I find Meson cleaner than CMake,

I'd vote for removing CMake support. Its inofficial status means that
people shouldn't rely on it anyway, even if there inevitably are
people that do.

> - I would like to drop the dynamic module instantiation / lookup code from
> the library, to simplify certain code paths.

Has this ever been used by anyone?

> - There are many things I'd like to get rid of, but apparently [cut off]

... yes? :D

> - Finally, the largest issue I've seen is the dependency on Harfbuzz. The
> situation where both libraries depend on each other is a little bit
> ridiculous. I wonder how much of Harfbuzz we need, and if it's worth
> re-implementing in FreeType2 itself. But something tells me implementing
> hb_shape() can be really subtle. Any informed opinions on this?

This can probably only be answered by HarfBuzz people. I think Behdad
is lurking here somewhere...

Re: LCD filtering changes are due

[Nikolaus Waxweiler]

You could release the next version and 2.11 back to back.

Re: LCD filtering changes are due

[Nikolaus Waxweiler]

I agree because I'm principally in favor of removing layers of code, no 
matter what for or how it is achieved.


Also: I just remembered that I never heard back from the RedHat lawyer 
that I or someone else asked to look into the ClearType patent 
situation.

Re: [freetype2-demos] Fix compiler warnings

[Nikolaus Waxweiler]

There are tools like towncrier and probably others where your patches are
accompanied by news fragments in a news dir that are assembled into a news
file and then cleared on release.

Re: Build system considerations

[Nikolaus Waxweiler]

> I'm not sure you realize that what you wrote sounds insensitive and is
> bordering ad-hominen.
> You could have said that you disagree and that this doesn't match your
> experience for example.
> Instead you tone devalues the point you're trying to make.

+1

> A) One of the major features of FreeType is that is can be easily built on
> many many systems (included embedded ones with weird toolchains), and it's
> something I'd like to keep for the core library.
>   In other words, I really want to keep the ability to compile an official
> release of FreeType with "./configure && make". That doesn't mean we have
> to use auto-tools or the current Make-based system though.
>   We may also consider providing CMake scripts to help use of FreeType
> releases into CMake-based projects.

There is a CMake build file already, it is for building a library and
maybe a package only though. Sometimes people try to build a
distribution package from it and run into problems...

>
> B) [...] choosing
> a solution that brings joy is more important than something that could
> support a team of 50 people working on it, or is industry standard.

+1 :)

I generally like the idea of having one nice primary build system and
supporting bare Makefiles for niche platforms.

> so we may consider keeping autotools/libtool as an escape hatch for esoteric 
> systems that still exist, and use something simpler/better for Linux and OS X?

I honestly wonder how many of those esoteric systems are still in use
and want to compile git master.

> Apart from that, it would be easy to write a script to generate the proper 
> compilation database

Ok :) I just thought it was neat that CMake can generate this
automatically during configure and my IDE will just pick it up.

Re: [Freetype-devel] Re: Build system considerations

[Nikolaus Waxweiler]

One thing regarding build systems and IDE/tool integration:

Cmake and others can generate a
https://clang.llvm.org/docs/JSONCompilationDatabase.html that help
tools like static analyzers and language servers and IDEs parse
projects. It's very nice have when you hack on something.

It also means that you have to have an entry for every single .c file,
unless I'm missing something. FreeType bundles several .c files into
bigger .c files, breaking the database. Werner mentioned that this is
done because older compilers have worse inlining or dead code
elimination or something like that. It would still be nice to have the
database.

Something to consider when cleaning up the build system :)

2020-04-30 9:11 GMT+01:00, suzuki toshiya :
> The circular dependency is a headache, but I don't think the
> reconsideration of the building system is good place to discuss
> the simplification of the dependency between FreeType and harfbuzz.
>
> In my understanding, the features of harfbuzz used by FreeType are
> very small subset, the classification of character encoding, script
> and language. Although I sympathize with the circular dependency
> problem, it would not be good idea to cloning them into FreeType
> source code, because of the different time-frames between FreeType
> and Unicode related features of harfbuzz (or Unicode itself).
>
> Some meta-building system would be the easiest way to avoid the
> manual and repeated building of FreeType and harfbuzz, aslike some
> GNU toolchains (binutils + gcc + gdb) ?
>
> Regards,
> mpsuzuki
>
> P.S.
> But, I'm interested in the decision under a situation: if harfbuzz
> requires libstdc++, should we care the dependency of FreeType?
>
>
> Vincent Torri wrote:
>> On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG  wrote:
>>>
 currently, to have harfbuzz support, freetype must be compiled
 without hb support, then build hb with freetype support, then
 freetype with hb.

 it would be nice to remove this circular dependency
>>> AFAIK, this would only be possible by splitting either HarfBuzz or
>>> FreeType into two packages, and this won't happen.
>>
>> or moving/coying some functions from freetype to hb, or conversely  ?
>>
>> Vincent Torri
>>
>>
>
>

Re: I'm back

[Nikolaus Waxweiler]

(oops, forgot to send to the list)

-- Forwarded message --
From: Nikolaus Waxweiler 
Date: Thu, 30 Apr 2020 09:28:34 +0100
Subject: Re: I'm back
To: David Turner 

> Can you clarify what that means exactly? I think I lack context and/or
> examples :-)

See https://www.freetype.org/freetype2/docs/text-rendering-general.html :)

>> Then Qt can go all in on stem
>> darkening and rendering fonts correctly. And hopefully everyone else.
>>
>> What do you mean by "going all in on stem darkening", especially for QT?
> Are you advocating for UIs with darker / bolder fonts or something like
> that?
> Just trying to understand.

To correctly render fonts, you need to linearly alpha blend FreeType's
output onto a surface and then gamma correct it. This necessarily
lightens text, so you stem-darken to counter the thinning. The Adobe
CFF renderer introduced that functionality and Qt 5.9+ will use linear
alpha blending and gamma correction plus stem darkening on CFF fonts.
I implemented stem darkening for the autohinter, but quality at
smaller sizes where it matters most does not match the CFF driver :(
Providing good stem darkening for all drivers would enable Qt (and
hopefully Skia and others) to use correct font rendering regardless of
the underlying font format.

>> Also, the build system generation thing sounds very meta. I'd prefer
>> settling on a single build system (either CMake or Meson and nothing
>> else) 
>>
>> I was thinking about something much simpler at first. For example, I have
> some local changes to considerably simplify the content of the rules.mk /
> module.mk.
> This uses a few custom GNU Make functions but that's a hidden /
> implementation detail. The point is to make these .mk files easily
> parseable by something else.
>
> The current build system was designed in a very different time, and there
> is definitely value in changing it more drastically. I'll start a different
> thread to discuss the idea though.

I suppose a simplification would be a good start in any case.

Maybe a single build system like Meson that also generates Makefiles
for other platforms while assembling a release would do the job?
Werner said he'd like a bare git checkout to just work with `make`,
but maybe it's good enough to provide that just in release tar balls?

> Is there a specific corpus of font files being used currently for
> regression testing? Should we try to create one or improve the existing
> one?

I don't know of any test fonts, outside of maybe Armin's fuzzing collection.

BTW, one idea for a regression test I had here would be to have some
fonts like the Noto fonts in OTF and TTF format compiled from the same
source and ensure that e.g. advance width and other metrics match
exactly between drivers (also slight autohinting that should not mess
with various metrics).

Re: I'm back

[Nikolaus Waxweiler]

Woah 

My favorite pet issue I never got around to fixing: make stem darkening 
for the autohinter be as good as the CFF variant. Also, at least basic 
stem darkening for bytecode'd TTFs. Then Qt can go all in on stem 
darkening and rendering fonts correctly. And hopefully everyone else.


Also, the build system generation thing sounds very meta. I'd prefer 
settling on a single build system (either CMake or Meson and nothing 
else) 


And even a basic testing framework sounds good. One could, if so 
inclined, even use https://github.com/rougier/freetype-py and use 
pytest and hypothesis to hammer out a test suite.

Re: Fw: GSoc 2020 project : Integrate distance fields to freetype

[Nikolaus Waxweiler]

I faintly remember that there has been some additional research on this 
topic since Valve presented their approach. I think there even was 
something in Qt. Might be worth snooping around for different 
implementations.

Re: commit 6a92b1fad makes FreeType reject woff files

[Nikolaus Waxweiler]

The quickest way to find out is to remove it for the next patch release and
see where the screams come from.

Re: ttfautohint — additional feature requests.

[Nikolaus Waxweiler]

Thanks, but I mean the original original mail. What you point to seems 
to be a response? It feels like entering a conversation in the middle :)

Re: ttfautohint — additional feature requests.

[Nikolaus Waxweiler]

So I'm trying to read the email thread and am confused. Where is the 
original mail?


From what I am piecing together from the back and forth so far: I 
suggest you implement your ideas in a proof of concept (maybe even 
something that generates VTT code), so it can be tested.


Can't comment on the rest because I don't see the full context. Except 
for this:


> Seeing the community think like this is cringe. This only delays the 
development
> of ttfautohint even further, even though bilevel optimized hinting 
is of course

> a very important feature. [...] All because of the
> mindset that blurry text is ever so slightly, but not really, better 
on higher
> resolutions than on lower resolutions. That's desirable for a 
commercial company
> like Microsoft (it can get away with selling systems that default to 
incorrect
> gamma anti-aliasing, which looks awful regardless of resolution), 
but certainly
> undesirable for free software. I suggest ttfautohint developers to 
immediately

> think of ways to achieve bilevel-optimized hinting.

Aaargh. I'm not sure if this has to do with English not being you 
native language, but this comes across exceptionally poorly. It is a 
mix of condescension, passing off opinion as fact and feeling entitled 
to tell someone else what to work on. I recommend you work on your 
communication style, as you'll quickly turn people off.

Re: Pd: Re: Odp: Re: ttfautohint — additional feature requests.

[Nikolaus Waxweiler]

Your mail is shown to me as empty with an attached .txt file.

Commit 4270e9f3243079bb90b6af618ed4d4fd31266412 makes space glyphs in CFF2s zero-width

[Nikolaus Waxweiler]

Testable with e.g. the CFF2 variable font in 
https://github.com/adobe-fonts/source-sans-pro/releases/tag/3.006R in 
Chromium on www.axis-praxis.org.


The cause is this diff:

```
diff --git a/src/psaux/psft.c b/src/psaux/psft.c
index 54be46834..a823ac800 100644
--- a/src/psaux/psft.c
+++ b/src/psaux/psft.c
@@ -313,9 +313,12 @@
FT_Error error = FT_Err_Ok;
CF2_Font font;

- FT_Bool is_t1 = decoder->builder.is_t1;
+ FT_Bool is_t1 = decoder->builder.is_t1;


+ if ( !charstring_base || !charstring_len )
+ return FT_ERR( Invalid_File_Format );
+
FT_ASSERT( decoder &&
   ( is_t1 || decoder->cff ) );
```


Removing the `if` block makes spaces spacy again. I have no idea what 
to do about the returning UBSan warnings though. The check itself seems 
wrong to me. Here's a TTX dump of the space glyph of Source Sans 
Variable:


   
   

[ft-devel] Glitchy rendering of overlapping outlines in variable fonts

[Nikolaus Waxweiler]

Hi list,
I was just looking at SourceSerifVariable-Roman.otf from 
https://github.com/adobe-fonts/source-serif-pro/releases/tag/3.000R and 
found this discrepancy between the variable instance of Black and the 
static one with overlaps removed:


https://i.postimg.cc/VLLmQqV2/Bildschirmfoto-vom-2019-09-25-21-22-01.png

Same thing in the variable TTF. Is this a known limitation in the 
renderer?




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

Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics

[Nikolaus Waxweiler]

Undefined does not mean scary.


Actually yes. Have you read e.g. 
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html?



Why do we even care?

The burden is actually on the compiler to not do anything crazy or 
face consequences from users and public. For some reason the burden 
is put on  the innocent and quite reasonable public. This does not 
make sense.


I think if you are innocent and reasonable, you don't use C/C++ 



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

Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics

[Nikolaus Waxweiler]

>
> .. and undo those macros?
>

Well, if you then can? Signed integer overflow being undefined strikes me
as a severe deficiency in the C language. This of course makes -wrapv a
compiler level workaround, which may not be available to every compiler
FreeType wants to support. Hm.

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

Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics

[Nikolaus Waxweiler]

This makes me wonder if maybe FreeType should be compiled with -wrapv
by default?

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

Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics

[Nikolaus Waxweiler]

Thanks for looking into it. FWIW, my commit merely re-enabled an older 
code path.




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

[ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics

[Nikolaus Waxweiler]

Forwarding the following message I received regarding a fuzzer find. 
I'm not sure what to do about it.


-- Weitergeleitete Nachricht --
Von: kkal… via monorail 
Betreff: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in 
compute_glyph_metrics

Datum: Wed, 10 Jul 2019 00:34:24 -0700
An: madig...@gmail.com

{ "@context": "http://schema.org;, "@type": "EmailMessage", 
"potentialAction": { "@type": "ViewAction", "name": "View Issue", 
"url": "https://bugs.chromium.org/p/chromium/issues/detail?id=977845; 
}, "description": "" }

Updates:
Labels: M-76 Test-Predator-Wrong

Comment #5 on issue 977845 by kkal...@chromium.org: pdf_font_fuzzer: 
Integer-overflow in compute_glyph_metrics

https://bugs.chromium.org/p/chromium/issues/detail?id=977845#c5

Unable to provide possible suspect using Predator, CL and Code Search.
Could someone please look into the issue.

Thank You...

--
You received this message because:
 1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.



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

Re: [ft-devel] CMake build system: some proposed changes

[Nikolaus Waxweiler]

I do not understand the problem. I do not think a user of our build
system is an expert who packages it for distribution. Our user is
likely happy that very few FreeType dependencies are autodetected. An
expert packager will probably add extra flags and override any
dependency. More so every expert has his own opinion and we cannot
accommodate them all.


Mh, ok. Maybe I need to give an example of disabling all dependencies 
in the comments.



Please do not screw average Joe the user. I consider there is only one
problem with CMake: it edits ftoption.h in one direction, which is
weird.


I think it only feels weird because it's a different approach to 
configuring a project. What CMake can and Meson will do is make you use 
different out-of-source build folders for different configurations. 
I.e. you can have `build-debug`, `build-release-no-deps`, 
`build-debug-bundled-zlib`, `build-debug-system-zlib`, etc. 
side-by-side without them littering over each other. The workflow is 
that you create and configure the project into these build folders and 
then not touch what's inside. This is different to the lol-whatever 
approach usually taken by autotools-like build systems and is why I was 
thinking of option-alizing all of ftoptions.h. That can also be done by 
hand before configuring a build folder, so... meh.



What about making cmake emit a report after execution, similar to the
`configure' script, which also lists the cmake CLI options to switch
the corresponding features on or off?

After cmake execution a hint could be printed that guides people what
to do if further tweaks are necessary.


Sounds good.



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

[ft-devel] CMake build system: some proposed changes

[Nikolaus Waxweiler]

Hi list,
I've been looking at some CMake issues filed over at Savannah. One ting 
that pops up in a few places is that some people do not expect CMake to 
autodetect external dependencies, which can lead to problems when e.g. 
baking packages for distribution.


I don't have a strong opinion on this and tried to find "best 
practices" on this in the CMake world, but didn't get much of anything 
resembling, well, anything useful. Maybe it's just the CMake world 
being as anarchic as usual. Or maybe I didn't put in enough effort.


My idea: implement knobs for all (?) ON/OFF options listed in 
ftoptions.h and make their default state mirror the default state in 
ftoptions.h. This would also mean external dependencies are off by 
default. I will not change the default build system. The idea is that 
you configure freetype2 the "idiomatic" CMake way, instead of fiddling 
with ftoption.h yourself.


Anyone opposed to this?



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

Re: [ft-devel] WOFF2 support update and questions

[Nikolaus Waxweiler]

Regarding testing, you can try the following:

1. otsanitizer has a test data directory with "good" and "bad" fonts: 
https://github.com/khaledhosny/ots. Remember to compile your copy of 
the library with the `-fsanitize=address,undefined 
-fno-sanitize-recover` compiler switches so that you get pretty 
explosions if your code does weird things with the input :)


2. Use fonttools' WOFF2 compression to compress random fonts yourself: 
https://github.com/fonttools/fonttools/blob/master/Snippets/woff2_compress.py




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

Re: [ft-devel] harfbuzz dependencies for FT 2.10.0

[Nikolaus Waxweiler]

If CMakeLists.txt readily removes the comment around 
FT_CONFIG_OPTION_USE_HARFBUZZ, it should also put it back when OFF.


Uhm, what do you mean?

Or better actually, simply add -DFT_CONFIG_OPTION_USE_HARFBUZZ. to 
the compile options when ON.




Hm. Werner, the default build system modifies ftoption.h so that the 
defines are persisted when the file gets installed into the target 
include directory, no?


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

Re: [ft-devel] GSOC -Project Availability

[Nikolaus Waxweiler]

A random thought on testing FreeType: I recently read about a small testing
library for C code, here:
https://www.bassi.io/articles/2019/03/14/a-little-testing/. Might be
interesting. Another option could be using the freetype-py wrapper and test
with that (pytest is nice). One thing that would be welcome is a continuous
integration ready approach, meaning that every commit would trigger test
runs under different operating system images and compilers. This could help
with uncovering differences due to compilers.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] harfbuzz dependencies for FT 2.10.0

[Nikolaus Waxweiler]

The OFF switches toggle between use-deps-if-available and 
use-deps-definitively. Read the top of the CMakeLists.txt to find out how to 
disable deps.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Shared libfreetype.so with ccmake

[Nikolaus Waxweiler]

BUILD_SHARED_LIBS is a fundamental CMake-internal thing. I don’t know ccmake 
but I’d recommend looking at ccmake harder, there must be something for it.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] To Add support for the 'SVG' OpenType table to render color fonts.

[Nikolaus Waxweiler]

There was an article on LWN recently that reported on a conflict in the
Debian community about librsvg. Rust's main compiler is officially
supported on just a few architectures (x86 mostly, I think ARM is still not
officially Tier 1?), causing problems for Debian on fringe ones.

Not that I necessarily think that this is a big issue. If macports decides
to support discontinued macOS versions, they can do so on their own. If
people want to run on fringe architectures, they may need to live without
SVG support, which isn't a huge deal I think.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] what FT_Color

[Nikolaus Waxweiler]

Make FT_Color an optional C11 Part and force everyone to update their
compilers 
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] (no subject)

[Nikolaus Waxweiler]

There’s a link to unsubscribe at the bottom of every eMail.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Done, pushed and fingers crossed.


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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Thanks for chiming in. Well, the patch works and at least two people 
say it's the right thing to do, so I'd say let's merge it. Werner, is 
that ok?



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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

The short version is that Firefox and Chromium seem to directly access hhea
and typo themselves. The patches seem to have no effect except that
Chromium seems to react to freetype not blindly setting typo values in VF
instances anymore, but only with small metrics changes.

GTK and Qt let text and UI elements compress if bit 7 is set and typo
ascender plus descender < hhea ascender plus descender. I have no idea how
much this is the result of theming in either toolkit and if it is what is
supposed to happen.

So.

Still not sure we want mvar typo deltas to modify currently active metrics?

... Merge and break out asbestos pants?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Then what should happen is that everything is just shifted, no? E.g. Qt 
does this:


https://i.postimg.cc/ZR3x17mw/Bildschirmfoto-vom-2019-01-31-00-09-31.png
https://i.postimg.cc/PJjQhWrT/Bildschirmfoto-vom-2019-01-31-00-09-56.png

Text becomes compressed.
Am Do, 31. Jan, 2019 um 12:38 A. M. schrieb Behdad Esfahbod 
:
That's what line-gap is: gap between consecutive lines.  There is no 
line before the first line, and as such, no gap.



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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Even more testing.

ftview and Qt actually do the same GTK does: they don't add the line 
gap to the top, so text fields look compressed when the 
USE_TYPO_METRICS bit is set and typo asc+desc is smaller than hhea 
asc+desc. I'm not sure this is supposed to happen?! Didn't test MVAR 
modification.


Firefox and Chromium disregard FT_Face's ascender, descender and height 
attributes and use either hhea (I think; no USE_TYPO_METRICS) or typo 
metrics (USE_TYPO_METRICS), modifying typo metrics and the FT_Face 
attributes through the MVAR table therefore has no effect unless the 
USE_TYPO_METRICS bit is set.


The document body of a new text file in LibreOffice Writer 6.1.4.2 
stays the same  regardless of bit so I think LO Writer is doing it 
right. It doesn't support VFs though so I can't test MVAR modifications.


Behdad, I'm not completely sure of typo deltas in MVAR modifying the 
currently active metrics. Given that the hhea set is basically a legacy 
value and is probably taller spaced than the typo metrics, so we might 
end up doing things the designer didn't intend? What FF/Chromium do 
strikes me as saner, i.e. writing typo metrics to FT_Face 
ascender/descender/height when USE_TYPO_METRICS is set :/


Otherwise, I'd say unless anyone has objections, I think we can merge 
the branch.



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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Some more testing today. Turns out that if have just the MVAR apply
patch active, Chromium still changes the line-height when switching
between the same Cantarell VF (one with bit 7, one without). As there
actually are no metric field values in the MVAR table, the FT_Face
ascender, descender and height values stay the same between both.
Bizarre. As if Chromium actually depends on the current behavior and
fixes it itself.

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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

After doing some vanilla/patch switching of FreeType and testing, I 
found that Chromium is indeed impacted by the patch. Without it, 
switching between the VFs I attached to 
https://gitlab.gnome.org/GNOME/gtk/issues/1626 makes no difference on 
http://www.cyreal.org/Font-Testing-Page/index.php makes no difference. 
With the patch, I can see changes. Firefox stays the same with and 
without the patch. Hm.



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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Actually, Behdad, just so I understand correctly:

In the case of Cantarell, assuming the line gap is put at the top, 
toggling USE_TYPO_METRICS should _in theory_ not make any difference 
because each of hhea, typo and win sums up to a total height of 1200 
font units (1000 upM font + 20% line spacing as recommended by the 
OpenType spec), no?


I'm asking because that's what I think should happen but does neither 
in Frefox nor in Chromium.



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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Oh, right, sorry :D

So after some weeks of testing, I can say that fonts that set the 
USE_TYPO_METRICS bit and have a sTypoLineHeight set to non-zero 
consistently look shifted up in GNOME, so this patch seems to work ;) 
No eye-catching change in Qt UI, Chromium or Firefox. Will test some 
more as time allows, but want to get this in before 2.10.



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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Werner,
what do you think about the patch? Any objections to merging it? :)


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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

I implemented something at

http://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/?h=use-typo-metrics

http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=use-typo-metrics=1250af7acecb22b2f5080efeb8dd14ab28779f6a
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=use-typo-metrics=7c379c466107a17e30155995a85a74cfa8f536bd

I installed this on my machine, let's see what happens.


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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

The thinking within the working group was that no one uses win 
metrics, so we didn't encode their variations.  Indeed, the only time 
one uses them these days is if typo and hhea metrics are not set...





But MVAR tags for win metrics exist?

https://docs.microsoft.com/en-us/typography/opentype/spec/mvar#value-tags

'hcla'  horizontal clipping ascent  OS/2.usWinAscent
'hcld'  horizontal clipping descent OS/2.usWinDescent

Or are they specifically for clipping avoidance and should never modify 
line metrics? Then the code should be removed anyway from the MVAR 
apply function. I see in the HB code you linked that you use the typo 
metrics if the typo bit is set and hhea metrics otherwise. I can find 
no mention of win* metrics in the codebase. Should FreeType behave 
similarly? I.e.


1. If OS/2 table exists and typo bit is on, use typo metrics
2. Otherwise, use hhea metrics
3. Unless they are zero, then use typo metrics. If they are zero as 
well, so be it.

(4. Always ignore win metrics)

The comment given in sfobjs.c:1662 says that some ARIALNB.ttf has typo 
metrics set to zero. So, not sure about 4., maybe only for static fonts?


I'm in a bit of a bind with Cantarell, as I already released a version 
that ships with GNOME and does not have the typo bit set. Grr. I guess 
I need to look into how to make GTK or whatever add line gap somewhere 
or change the metrics around...



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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

I suggest FreeType be changed to respect OS/2 useTypoMetrics bit.


I'm gonna experiment with that.


GTK/Pango/Cairo just call into FreeType for metrics.

I'm confused.  What does "default outline" vs "default instance" mean?




By default outline I mean the outline that is displayed by ftview when 
you open a VF, before pressing `n` to cycle through the instances. I 
noticed that GTK apps display Cantarell-Regular using the default 
outlines but use e.g. the bold instance for -Bold. That's how I noticed 
the metrics difference.


There's also the question of whether MVAR tags should apply to 
whatever was used for ascent/descent.  I think yes.  And I'll 
implement that in HB.


What would you do when

1. the typo metrics are modified by the MVAR table
2. win metrics are modified
3. both are modified

?


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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

> This is certainly the most convenient solution for me since I have
> nothing to do on the FreeType side :-)

(As an aside, GTK/Pango seem to make the same mistake as TextEdit then,
putting the line gap at the bottom instead of on both sides or something,
so this would still look wrong even if FT would default to typo metrics for
VFs)

> Your question, however, is a fundamental one: Shall a VF font be
> always treated as VF, or is the `VFness' an optional feature?

I'd say the primary purpose of a VF is to be a VF, it is only optionally so
for applications that don't know what a VF is. You'd think that using the
hhea metrics for the default outlines would make sense in that case, but
this still presents a corner case if the applications increases in
smartness and suddenly the same font has different metrics 樂
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

I just tested the static and variable fonts in macOS 10.14 TextEdit.
For the static instances, it presumably takes the hhea metrics, for
the VF, it always takes typo metrics. (It also adds the line gap at
the bottom, making text look weird, but maybe that's because the
layout logic is broken.)

So that would speak in favor of always using either typo or win
metrics for variable fonts, even for the default outlines?

Or maybe this is really the fault of GTK/Pango/something because it
loads the default outline instead of the default instance, which would
yield the correct metrics?

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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

OR MAYBEE if we detect a variable font, the default/static
outlines gets typo or win metrics instead of hhea metrics?

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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Actually, maybe the "patch" is wrong. Should the decision making
between static faces and instances be harmonized instead? I.e. should
static faces default to typo metrics instead of hhea metrics? Should
ascender/descender in tt_apply_mvar only be changed if hhea metrics
are zero, like for static fonts?

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

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Thanks Alexei for chiming in at
https://github.com/googlei18n/fontmake/issues/492#issuecomment-448249543.

> The following seems to be different: hhea does not seem to be used in VF. 
> Compare and decide which one is correct.
>
> https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/truetype/ttgxvar.c#n1365
> https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/sfnt/sfobjs.c#n1670

The OpenType spec says nothing variation specific about hhea/typo/win
metrics, except that hhea vmetrics don't seem to be supported by the
`MVAR` in that only win and typo metrics have `MVAR` tags:

- 
https://docs.microsoft.com/en-us/typography/opentype/spec/hhea#39hhea39-table-and-opentype-font-variations
- https://docs.microsoft.com/en-us/typography/opentype/spec/mvar#value-tags
- https://docs.microsoft.com/en-us/typography/opentype/spec/os2#stypoascender
- https://docs.microsoft.com/en-us/typography/opentype/spec/os2#uswinascent

Regarding ascender, descender and height calculation in sfobjs.c and
ttgxvar.c: the math seems to be the same:

- hhea: ascender 983, descender -217, line gap 0 -> total height 1200 fU
- typo: ascender 739, descender -217, line gap 244 -> total height 1200 fU
- win: ascender 983, descender 217, line gap 0 -> total height 1200 fU

For static fonts, FT uses hhea metrics: `root->height = root->ascender
- root->descender + face->horizontal.Line_Gap;` or `983 - (- 217) + 0
= 1200`
For instances, it uses typo metrics: `root->height = root->ascender -
root->descender + face->os2.sTypoLineGap;` or `739 - (-217) + 244 =
1200`

Will look into this deeper later.

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

[ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Hi list,
I'm trying to turn Cantarell into a VF and am hitting a hhea/typo/win 
metrics issue: the metrics seem to be interpreted differently for the 
VF instances compared to the static fonts an I'm not sure if I'm doing 
something wrong. The instances look as if their baseline was shifted 
upwards relative to the static fonts. Equalizing hhea and typo metrics 
makes the difference go away.


Here's a screenshot of the baseline difference: 
https://github.com/googlei18n/fontmake/issues/492#issuecomment-447760311


Here are the three static masters and the resulting VF: 
https://github.com/googlei18n/fontmake/issues/492#issuecomment-448005088


(Note that the Regular serves as the master for various fields, e.g. 
the "Use Typo Metrics" bit. Toggling it does not help.)


This happens on master and on 2.9.1. Am I overlooking something?


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

Re: [ft-devel] Qt installation help

[Nikolaus Waxweiler]

Hi,
I suggest you ask on a Qt user help channel, we are not affiliated with Qt
in any way.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [PATCH] Install DLL files in CMAKE_INSTALL_BINDIR

[Nikolaus Waxweiler]

I remember adding and removing this for some reason 樂 Guess I'll find out
at the next update.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Removing FT_Outline_New_Internal

[Nikolaus Waxweiler]

Ugh.

A cursory search on GitHub 
(https://github.com/search?q=FT_Outline_Done_Internal=Code 
) says that the 
two functions at least seem to be part of Servo’s FreeType bindings 
(https://github.com/servo/rust-freetype/search?q=FT_Outline_Done_Internal_q=FT_Outline_Done_Internal
 ) 
and of freetype-sys 
(https://github.com/PistonDevelopers/freetype-sys/search?q=FT_Outline_Done_Internal_q=FT_Outline_Done_Internal
 
),
 so I suppose generated bindings may be the primary users of those two 
functions?

I think we’re out of luck here...___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Removing FT_Outline_New_Internal

[Nikolaus Waxweiler]

What would speak against going to 7?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] On atomic ops and text stack thread-safety

[Nikolaus Waxweiler]

Very informative, would read more. Behdad, please write more.

So… should we rewrite FT in Rust to avoid all these things? 類
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Integrating Docwriter into FreeType

[Nikolaus Waxweiler]

It basically runs "pip install ." or "python setup.py install", so it
does whatever setup.py does.

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

Re: [ft-devel] Integrating Docwriter into FreeType

[Nikolaus Waxweiler]

The very point of tox is to install a package in a version-specific
venv to run tests on it, so you're actually testing that the
installation works :)

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

Re: [ft-devel] Integrating Docwriter into FreeType

[Nikolaus Waxweiler]

> 
> This is a bit tricky in Python, see 
> https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure 
> .
> 
> Basically, tox and therefore pytest is run from the project root directory, 
> which happens to have the docwriter module-directory. Python by default has 
> the current directory in the import path. pytest will collect the tests and 
> run them — when they import docwriter, they will actually import the 
> module-directory in the project root! You however want to test the package as 
> installed by tox somewhere in .tox/…. Stepping out of the root directory, 
> e.g. into the tests directory ensures this.
> 
> Well, if I cd into tests/ (with changedir), I'm getting a bunch of import 
> errors. This is because now the tests don't know where 'docwriter' is (outer 
> directory). I'm confused, please advise.

I think that helped you find a bug in your packaging :) The tests should find a 
docwriter module because that’s what tox installs in the testenv. Look into 
what is actually getting installed deep in .tox.___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Integrating Docwriter into FreeType

[Nikolaus Waxweiler]

> 
> Keep in mind that you need to tell tox to cd into tests/ before running 
> pytest, otherwise you’re testing the source directory instead of the 
> installed package.
> 
> https://tox.readthedocs.io/en/latest/config.html#confval-changedir=path 
> 
> 
> I'm running the tests on the source directory using `python -m pytest' with 
> tox. Pytest collects all tests and runs it on the source, and all imports in 
> the test files are like 'from docwriter import ...' so I think this is the 
> right configuration. Am I missing something? 
> (https://travis-ci.com/nikramakrishnan/freetype-docwriter/jobs/136998196#L445 
> )
>  

This is a bit tricky in Python, see 
https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure 
.

Basically, tox and therefore pytest is run from the project root directory, 
which happens to have the docwriter module-directory. Python by default has the 
current directory in the import path. pytest will collect the tests and run 
them — when they import docwriter, they will actually import the 
module-directory in the project root! You however want to test the package as 
installed by tox somewhere in .tox/…. Stepping out of the root directory, e.g. 
into the tests directory ensures this.___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Integrating Docwriter into FreeType

[Nikolaus Waxweiler]

Keep in mind that you need to tell tox to cd into tests/ before running pytest, 
otherwise you’re testing the source directory instead of the installed package.

https://tox.readthedocs.io/en/latest/config.html#confval-changedir=path
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Integrating Docwriter into FreeType

[Nikolaus Waxweiler]

> 
> (0) Make docwriter a PyPI package.
> 
> I do not have experience with packaging and publishing libraries to pip.
> I tried doing it yesterday but got a bunch of import errors, so I might
> need some help with this one.

You can follow https://packaging.python.org/  
for that.___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Integrating Docwriter into FreeType

[Nikolaus Waxweiler]

> (1) Add a check for (a) `python', (b) `pip', and (c) `docwriter' in
>FreeType's `configure' script.

I meant, if you go the PyPI route, you don’t need to check for pip as you 
really only care about docwriter (and maybe python).
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Integrating Docwriter into FreeType

[Nikolaus Waxweiler]

Did you mean "python" and "docwriter"? We only need pip for installing it.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel