Re: Memory safety for fonts & text

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

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

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

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

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

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

Re: removing `ftrandom`?

I didn't even know it exists 

Re: meson and logging support

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

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

> >> 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

Re: meson and logging support

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?

I think you are responding to a spam generator 

Re: moving freetype-web to gitlab instance

(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

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

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

Re: Commit ec9b6c314dc018bbf0af4ff657fa5ff56a5bf9f7 breaks existing programs

Werks! Thanks!

Commit ec9b6c314dc018bbf0af4ff657fa5ff56a5bf9f7 breaks existing programs

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

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

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.

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

Wrong mailing list.

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

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?

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

Re: Meson build, continued

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

> > 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

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

Re: Gitlab Migration Progress

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

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

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

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

Re: Gitlab Migration Progress

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

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

Re: OVERLAP_SIMPLE or OVERLAP_COMPOUND

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

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)

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

Re: [patch] Simplify ftconfig.h

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

Re: [patch] Simplify ftconfig.h

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

Re: Overlap oversampling

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

Re: Overlap oversampling

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

> 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

Re: Build system considerations

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

Re: Build system considerations

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

Re: LCD filtering changes are due

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

Re: LCD filtering changes are due

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

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

> 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

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

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

Re: I'm back

(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.freety

Re: I'm back

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,

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

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

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.

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.

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

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

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

Commit 4270e9f3243079bb90b6af618ed4d4fd31266412 makes space glyphs in CFF2s zero-width

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 +++

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

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:

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

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

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

> > .. 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. >

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

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

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

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

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

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

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

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

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

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

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

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

Re: [ft-devel] GSOC -Project Availability

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

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

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

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

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

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

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

Re: [ft-devel] what FT_Color

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)

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?

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?

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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?

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

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

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

> 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

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

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

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

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?

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

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

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. > >

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

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

Re: [ft-devel] Qt installation help

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

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

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

Re: [ft-devel] Removing FT_Outline_New_Internal

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

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

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

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

Re: [ft-devel] Integrating Docwriter into FreeType

> > 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

Re: [ft-devel] Integrating Docwriter into FreeType

> > 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 >

Re: [ft-devel] Integrating Docwriter into FreeType

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

Re: [ft-devel] Integrating Docwriter into FreeType

> > (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/

Re: [ft-devel] Integrating Docwriter into FreeType

> (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

Re: [ft-devel] Integrating Docwriter into FreeType

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

  1   2   3   4   5   >