Hello Sanjiban,
> On going through the project proposals, I found the project
> Improving Develop a test framework for checking FreeType's rendering
> output, Replace FreeType's tracing and debugging facilities with an
> external logging library, interesting to work upon and contribute
> and
>> I'm using the windows environment as per the project idea on the
>> subject field of this mail. Its actually difficult and unfriendly
>> going about the project. seeking for appropriate directives as per
>> starting up the FreeType on windows.
You have to be more explicit what is
[Anuj, please subscribe to the mailing list, see
https://lists.nongnu.org/mailman/listinfo/freetype-devel !]
[And please don't use top-posting while answering e-mails.]
>> I faintly remember that there has been some additional research on
>> this topic since Valve presented their approach. I
paper this time properly [
https://steamcdn-a.akamaihd.net/apps/valve/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
]
Thank you,
Anuj
On Wed, Mar 18, 2020 at 11:57 AM Werner LEMBERG wrote:
>
> [Original message sent to the list deleted since it contains a 7MByte
> PDF a
Hello Denil,
> I would like to Port the font-rs rendering engine to FreeType as my
> GSoC Project.
Great!
> I'm familiar with C and Unix systems. I will learn rust within the
> application period.
Mhmm, I'm not sure whether this is sufficient – how will you submit a
proposal if you only
[Original message sent to the list deleted since it contains a 7MByte
PDF attachment of a potentially non-public file]
[Please subscribe to the `freetype-devel` mailing list!]
Hello Anuj,
> My name is Anuj and I am a 3rd year computer science student. I am
> interested in game engine
Hello Parth,
> I went through the GSoC 2017 implementation of the `test-famework'
> project.
>
> * Some ideas like, using Murmur hash, using CSS sprite sheets for
> images are well discussed previously and spending time again for
> them will just be like reinventing the wheel.
Yep.
> *
> Recently some ClearType byte code interpreter patents have
> expired. Subpixel rendering ones, not quite. Most of them expired in
> November last year, but these are still active until end of July:
>
> https://patents.google.com/patent/US6282327
> https://patents.google.com/patent/US6393145
>
> I did check Veeki's commits I couldn't find a lot. I guess it would
> be better if I rollback to his commits and try to implement. I
> compiled freetype on my device and I'm still getting used to the
> codebase. once I'm a little confident I'll ask you about more stuff
> maybe.
OK.
> are
Hallo Zubin,
> I'm a Google Summer of Code 2020 aspirant and I am interested in
> this project.
Great!
> I do have a little experience in C, C++ and Qt framework.
OK.
> I just cloned the freetype-2 demos and wen't through the last years
> commits. are there any commits that I should work
> In my project, I'm using SDL_TTF, which is a wrapper library for
> FreeType. On credits for 3rd party libraries, I only mention 'SDL
> and its extensions', which SDL_TTF is 1 of them. Is this enough for
> you, or should I mention FreeType explicitly?
Good question. If your project uses the
Hello Priyesh,
> Working forward in an external library hunt i came across two
> C based logging libraries: [...]
>
> I am also working on a prototype that will print log messages
> generated by FT_ERROR into a log file.
Hold your horses – what you do currently is already part of the GSoC
(if porting) to high (if reimplementing).
Requirements: Rust, C, Unix build tools. Potential mentors:
Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki (FreeType).
[1] https://github.com/raphlinus/font-rs
Werner
> So you're saying the only anti-aliasing is overkill
> anti-aliasing.
? What do you mean?
> Who thought of this as a good idea? It is ever so slightly more
> accurate but really not worth it on lower end hardware such as
> embedded systems. 4*4 oversampling is a high priority feature
>
Looks great, thanks! A tiny nitpick: Please use two spaces after a
full stop.
And please commit!
Werner
> The quickest way to find out is to remove it for the next patch
> release and see where the screams come from.
Nice idea :-) However, this is probably too disruptive. Moazin
already started with updating zlib; hopefully he can finish that soon.
Werner
> Out of interest, why does FreeType still embed zlib? It's old, and
> building against a system version is better.
Maybe it makes sense to completely remove it. I'm not sure about
that.
Werner
> You mean something like this?
>
> #ifdef FT_CONFIG_OPTION_SYSTEM_ZLIB
> err = inflateInit2( , MAX_WBITS|32 );
> #else
> err = inflateInit2( , MAX_WBITS );
> #endif
Yes, something like this, a really quick fix until you find time to
update zlib.
Werner
> Do you know whether it is Not controlled, or if it has an Export
> control classification number (ECCN) in compliance with US export
> control laws ?
FreeType does not have an ECCN. Note that none of the main authors
and maintainers is from the US. We are from France, Austria, Japan,
and
> I just got some time look at this and I think I have figured out the
> problem. In a make devel build, the internal copy of zlib is being
> used which is very old and thus fails with my patch.
Yes. However, this might also happen if the user compiles on systems
that don't have zlib for
Hello Priyesh!
Thanks for your interest in FreeType.
>[...] Therefore, I propose to implement separate code files for
>logging, which could be based on C++ and can be easily plugged
>into the existing C code base. In addition to this, improving a
>bit on documentation can
Hello Moazin!
Your patch
6a92b1fadde26477a9179cbea988b3e04bd2decc
[gzip] Add support for `gzip' encoded header (#9812).
makes fonts like
https://github.com/source-foundry/Hack/blob/master/build/web/fonts/hack-bold-subset.woff
fail in FreeType – just to be sure: we are talking about
> > [about displaying embedded bitmaps]
>
> Uhh I do NOT care about DirectWrite rendering and I never intend to
> optimize my fonts for it because there are so many flavors of
> DirectWrite and each application chooses its own, so it's entirely
> meaningless to do this.
But if you are in GDI
>> Microsoft Calibri has embed bitmaps, but they don't appear to be
>> used, ever, at all. Instead, GDI uses its broken hinting. I've
>> heard Microsoft Windows has to detect for several Japanese
>> characters in the font before using embed bitmaps.
>
> I will ask a Microsoft guy about the
> 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 :)
Well, yes, but it essentially starts a new thread. Before, we had
some private communication.
Werner
> So I'm trying to read the email thread and am confused. Where is the
> original mail?
https://lists.nongnu.org/archive/html/freetype-devel/2020-02/msg8.html
Werner
> Uh, what are you doing?
??? My e-mail contained a CC field to the 'freetype-devel' list.
Your reply was only to me, and you omitted the list. You probably
have to press the 'Reply to all' button.
> Do I still have to embed plaintext files to send messages?
Yes, please, since your e-mail
> High-power platforms with high-DPI displays are not the only place
> where FreeType might be deployed. Case in point, I am using
> FreeType to render fonts on an ESP32 platform for a 72 DPI 128x96
> display. Hinting (or at least reasonable antialiasing) is very
> important to make text
[please don't remove the CC fields]
> > While the current increase of computing power would allow for
> > better algorithms to handle B/W auto-hinting, it becomes moot at
> > the same time because the increase of today's screen resolution
> > even for the cheapest displays makes hinting
Piotr's reply.
--- Begin Message ---
Plaintext file. Be sure your txt interpreter can read UTF-8, the UTF-8 BOM and
the Microsoft newlines.
/*
While the current increase of computing power would allow for better
algorithms to handle B/W auto-hinting, it becomes moot at the same
time because
I've just updated our GSoC page.
https://www.freetype.org/gsoc.html
If you have more suggestions, please chime in.
Werner
> From experience, there will be a lot of changes that will be small
> edits (making casts explicit, adding prototypes, adding "/ fall
> through */" comments to switch statements).
>
> So, I would be inclined to setup a github repo, and point you guys
> at commits, which you can critique, pull,
[Sorry for the very late reply. I had to prepare a conference and a
concert, and I took a vacation, too, with limited e-mail access.]
> Hi, I am interested in doing the project, “Replace FreeType's
> tracing and debugging facilities with an external logging library.”
> Is this still open for
Hello Piotr,
finally I have some time to answer your e-mail. Thanks a lot for your
thoughts, which I have tried to group for easier reading! Note that
your ideas look quite generic; it probably makes more sense to add
some of your ideas to FreeType's auto-hinter (which would then be
exported
Hello Chris,
> We use Freetype with Ghostscript. We have also been using coverity
> static analysis for quite some time, [...]
>
> Would you (mainly Werner, but others too) consider there to be value
> in us doing the same for Freetype?
yes, this would be valuable! Thanks for the offer.
Hello Yan,
sorry for the late reply.
> I'm trying to darken/embolden fonts. [...] As a result
> LCD-antialiased fonts look just perfect on my monitor:
> https://imgur.com/v8Wa63s
>
> Now I want to darken/embolden fonts that are rendered using the
> normal (grayscale) AA. How do I do that?
> Is it really true that FT_Outline_Get_Bitmap is not guaranteed to
> return an image of pixel mode BGRA when asked to do so with
> FT_PIXEL_MODE_BGRA?
>
> This can't be true, I must be doing something wrong. And yet, much
> to my horror, I get a grayscale image with one byte per pixel!!
> I am Faldu Amish from India. I am interested in contributing great
> ideas through *GSOC 2020* to your organisation and I am enthusiastic
> about it. I can code in *Python3 and C++ programming language and I
> have very good knowledge of Data Structures and Algorithms*. But I
> am confused
>> For most outline fonts, it is not possible to get exact glyph
>> dimensions in advance (exception: the font contains an `hdmx' table
>> that holds horizontal, device-dependent information for selected
>> pixel sizes). In other words, you have to render all (needed)
>> glyphs to get their
>> For most outline fonts, it is not possible to get exact glyph
>> dimensions in advance (exception: the font contains an `hdmx' table
>> that holds horizontal, device-dependent information for selected
>> pixel sizes). In other words, you have to render all (needed)
>> glyphs to get their
> I am currently working on a Thai text synthesis project which used
> freetype. My code is as follows (I’m using the font:“angsa.ttf”):
>
> if (FT_Set_Pixel_Sizes(face, charWidth, charDotSize) != 0)
> {
> return (ERROR);
> }
>
> ascender = FT_MulFix(face->ascender,
> I am currently working on a Thai text synthesis project which used
> freetype. My code is as follows (I’m using the font:“angsa.ttf”):
>
> if (FT_Set_Pixel_Sizes(face, charWidth, charDotSize) != 0)
> {
> return (ERROR);
> }
>
> ascender = FT_MulFix(face->ascender,
> I need these in my custom build setup. Looks correct to me.
Will apply, thanks.
However: The `aflatin2' stuff is never activated; I'm not sure whether
it still compiles at all. What are you doing with it?
Werner
Hello Behdad,
> I like to compose multiple glyphs in a bitmap without using any
> graphics library. I found that FT_Bitmap_Blend() does exactly what
> I want except that if none of the glyphs are color, it still
> promotes the image to a color bitmap.
>
> Would be nice to have another version
>> Jamie, could you suggest a documentation enhancement to cover the
>> difficulty you've experienced?
>
> I think the difficulty was just caused by the regression. Usually
> you wouldn't give a clip rect unless you know what you're doing, but
> the regression required one to avoid the crash,
>> Thanks, do you know how much difference the span batching made to
>> performance?
>
> In depends on your program. Simple scanlines might be delivered at
> once. Freetype won't wait for you to process each spam.
Jamie, could you suggest a documentation enhancement to cover the
difficulty
> I don't know if it was a change in gcc v9.2.0, but I had to add
> freetype2 to the #includes for ft2build.h:
>
>
> find /usr/include/freetype2 -type f -name "*.h" \
> -exec sed 's,,,' -i {} \;
>
> Error: ft2build.h not found.
Please give more details. What FreeType version, how did
> FreeType 2.6 used to use an unbounded clip_box in the
> FT_Raster_Params struct, and internally the gray_compute_cbox
> function would clamp it to a reasonable range.
>
> That clamping no longer happens, so you have to do it yourself
> before calling the function. The docs don't really
> Would it be possible to modify how the ftoption.h and ftconfig.h
> files are created in the CMakeLists.txt file? These files are
> recreated every time the cmake generation command is called even if
> the files already exist and no changes are required. It would be
> much better to use the
> Here's a minute addition to the FT_Open_Args documentation that I
> think could be useful for FFI binding authors.
Applied with some minor modifications, thanks! Please check.
> Feel free to ignore this mail altogether, if the proposed change is
> not appropriate. Apologies if this is a
Hello Di,
sorry for the late reply.
> I use FreeType to read [a] TTF font and get the image from
> FTC_SBitRec. Then I copy the data to [the] Alpha channel in 32Bit
> bitmap.
>
> That means when I finish the copy action, the FTC_SBitRec.buffer is
> not useful. My question is [whether] I
> I need it to compile pygame for python3 which needs freetype2 >=2.0
Where does this dependency version number come from? Note that
FreeType 2.0 has been released almost 19 years ago.
> Pygame building fails because pkg-config freetype2 --modversion
> gives 19.0.13, and not pkg-config
> recently I was working on expanding my program to handle Hindi
> (Devanagari) complex glyph like: ( न + ् + न ) which translates into:
> न्न
>
> I used old version of FT so I updated to last available version
> 2.10.1 but still I can not render that glyph properly, obtaining: न्
> न (without
> recently I was working on expanding my program to handle Hindi
> (Devanagari) complex glyph like: ( न + ् + न ) which translates into:
> न्न
>
> I used old version of FT so I updated to last available version
> 2.10.1 but still I can not render that glyph properly, obtaining: न्
> न (without
>>> freetype2/src/sfnt/sfwoff2.c: In function 'woff2_open_font.isra.24':
>>> freetype2/src/sfnt/sfwoff2.c:1729:22: warning: '*((void *)+16)'
>>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>>> WOFF2_InfoRecinfo;
>>> ^
>>> [...]
>>
>> What
> freetype2/src/sfnt/sfwoff2.c: In function 'woff2_open_font.isra.24':
> freetype2/src/sfnt/sfwoff2.c:1729:22: warning: '*((void *)+16)'
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> WOFF2_InfoRecinfo;
> ^
> [...]
What compiler is this? And
>> I've just integrated your woff2 stuff into FreeType. Thanks again
>> for working on this!
>
> I had a great time working on this! Thanks for fixing formatting and
> adding the comments.
:-)
BTW, a minor nit to avoid in future commits: I've noticed while
preparing the ChangeLog entries that
Nikhil,
I've just integrated your woff2 stuff into FreeType. Thanks again for
working on this!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
> Thanks Alexei, good to know about FreeType sticking to C89, and that
> it should be ok to redefine.
>
> Though I do see a FT_Int32 type defined in FreeType in ftconfig.h?
While `FT_Int32' gets used for more recent additions to the API (in
case it makes sense), we cannot change the original
> I have prepared a report and it is available at
>
> https://gist.github.com/nikramakrishnan/f88f3bae3cd2f0ba06d20ab3e0c74fb3
>
> Please let me know if I should add anything.
Looks good, thanks.
Werner
___
Freetype-devel mailing list
> I have improved trace comments and added functions to handle most
> (hopefully all) cases from the WOFF2 recommendation. Please test!
With my quick testing of some woff2 fonts: everything looks fine,
thanks! Please prepare your report.
Werner
> The devel build works now. But since `devel/ftoption.h' doesn't
> have the SVG flags, OT-SVG glyphs won't be enabled. It seems like
> we have a choice here.
>
> For a devel build, we can either enable just the OT-SVG feature
> without the default library or we can assume that librsvg's
>> Nobody tried. I would hope that font-rs or Pathfinder tried it.
>> That can be next year GSoC. Or, would Moazin kindly try a
>> dedicated SVG renderer?
>
> I don't mind trying it at all. :)
Great! If this indeed works we can provide a template for a module,
and this might be the way to go
> What I didn't realize is that we can choose to NOT expose certain
> properties via `FREETYPE_PROPERTIES'.
>
> If I have done this correctly,
> https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=GSoC-2019-moazin=b6403ad54eb9749810a239571805f2f350fa235e
> should prevent the
> You have to implement (and maintain) hooks instead of maintaining
> renderer modules. You are asking secondary libraries to implement
> hooks instead of the renderer module. There is nothing absolutely
> nothing easier, or more logical, or simpler. It buys you absolutely
> nothing!!!
I
> The whole environment variable thing is a string, so a sequence of
> bytes. If I set FREETYPE_PROPERTIES to
> `ot-svg:svg_hooks=asdjkfsjlfdk', In `ft_svg_property_set', `value'
> will have the address of letter `a' and thus, when the types are
> cast to hooks, weird address will be set and
> As I see it, there are going to be two types of users of the OT-SVG
> feature:
>
> 1. Who don't really care about which library will be used to render
>OT-SVG glyphs.
> 2. Who are interested in plugging some specific library.
Exactly.
> For 2, yes, there is the burden of writing the hooks
> ... but does this mean one can crash FreeType-using apps by just
> setting an environment variable?
A valid concern. However, this will definitely not happen – how will
you specify four or even more C function pointers within an
environment variable? It would be necessary instead to specify
>> Having a structure certainly reduces possible coding errors, but in
>> the end there is still a cast from one type to another, something
>> that disables type checking on the compiler level.
>
> The hooks are static, aren't they? Otherwise, how do you plan to
> document them?
Not sure what
> [...], after this commit, I am not abusing it to set pointer to
> code. I am abusing it to set a structure of four function pointers.
>
> Let me know if your concerns remain the same with this change.
His concerns stay the same. He doesn't like `multi-purpose' API calls
that do more than a
> I have improved trace comments and added functions to handle most
> (hopefully all) cases from the WOFF2 recommendation. Please test!
Will do that soon, thanks!
Some minor comments to the code.
* In API header documentation blocks (even the internal ones) please
replace `foo' with `foo` or
> I have added the support for transformations.
Thanks!
> For traditional glyphs, you can apply a transformation multiple
> times, since the transformation is just directly applied on the
> actual coordinates. But for SVG glyphs, the transformation is just
> stored with the actual SVG document
> I'm not sure what exactly points of discussion are, but in HarfBuzz
> we do purposefully ignore position overflows. We use a macro like
> this for that:
>
> #define HB_NO_SANITIZE_SIGNED_INTEGER_OVERFLOW
> __attribute__((no_sanitize("signed-integer-overflow")))
>
> If you want to copy the
> @Werner: should I apply it?
Yes, please.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
> I'm trying to add support for transformations to OT-SVG glyphs.
> [...]
>
> The solution that I have in mind is, let the user pretend that the
> glyph is just a traditional one, then we take the transformation
> that the user has given and convert it to an equivalent one for the
> SVG
> In `TT_Load_Glyph', there is some code that checks if the sizes have been
> set correctly. [...]
>
> For OT-SVG glyphs, I want to check if the size has been set earlier
> than this (because my checks for OT-SVG glyphs come early too). Are
> there easy ways to do that? Since I only care about
> Quick intro: https://youtu.be/d3NuqFckEoU
Thanks! You are making progress, which is good :-)
However, there is a lot of things that don't work right now. Here's
my list of things that I encountered while playing with the new
features.
* The biggest problem is that glyphs in the `ftview'
> I'm trying to read FT_Palette_Data (using FT_Palette_Data_Get) but I'm
> always getting nulls (and no errors):
>
> num_palettes = 1
> palette_name_ids = NULL
> palette_flags = NULL
> num_palette_entries = 2
> palette_entry_name_ids = NULL
The data is correct: The font contains one
> Instead of handling all of this in `woff2_open_font', I have
> introduced a new variable in `sfnt_open_font' (woff2_num_faces), and
> I use this to set `face->root.num_faces' if the input font is a
> WOFF2. (I believe) this solves all the issues. I've implemented
> this in commit b25c352.
> So are you suggesting that `sfwoff2.c' directly output the total
> number of faces and named instances (if the index is < 0) and exit
> with error so that FT_Open_Face does not try to read and output this
> data again?
In case this makes life simpler, please do it! The alternative as
> `woff2_open_font' reads the WOFF2 TTC header and uses that
> information to get tables for the requested font index.
This means that you can quickly extract the number of TTC subfonts,
right?
>> However, to get the number of named instances for a variation font
>> with index N, loading this
> Do you know whether it is Not controlled, or if it has an Export
> control classification number (ECCN) in compliance with US export
> control laws ?
I guess it's `Not Controlled' – the original author of the software is
French, the current maintainer (me) is Austrian... In other words,
this
> With commit af7d296 (in branch `GSoC-2019-nikhil'), we can now quite
> efficiently convert a WOFF2 to an SFNT font, which can then be
> rendered by FreeType.
Great!
> (1) If the WOFF2 is a TTC, only the requested face is loaded. So,
> instead of a TTC, we generate a single-face sfnt with one
> So I guess then the table size checks are probably not useful,
> however, the checks for `numEntries' not being non-zero and an SVG
> document's length not being non-zero are probably needed? Since, my
> code directly relies on these two. If `numEntries' is zero, the SVG
> table is pointless.
> Well one thing that just came to my mind is that though these checks
> aren't problematic, I am not sure how useful they are from a
> practical point of view. If somebody had to get invalid tables
> passed in, there can be many ways to do that and its impossible and
> also pointless to check
> I am aware of the fact that Travis CI is broken since midweek and
> I'm trying to talk to someone from Travis to get that fixed. [...]
Thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
>> So yes, please define errors and use them in the external code, but
>> just without FT_THROW. Maybe the library uses its own error code
>> debugging feature...
>
> How does this look?
This is OK :-)
Werner
___
Freetype-devel mailing list
>> If you say `rendering port', you mean code that gets added to
>> librsvg, to FreeType, or to the calling application?
>
> I mean the hook functions which the client will write and set them
> using `FT_Property_Set'. These will of course be different for each
> library. Have a look here:
>
> I was trying to write some good error handling code in the
> `librsvg' rendering port.
If you say `rendering port', you mean code that gets added to librsvg,
to FreeType, or to the calling application?
> What I did is that I created a new error `Invalid_SVG_Document'.
> Then, I check the
> In this email I intend to list the features we require from an SVG
> rendering library for use in OT-SVG project. [...]
Thanks for the overview.
> `librsvg' recently got a new function added namely,
> `rsvg_handle_get_intrinsic_dimensions' which meets (1) completely.
> However, it's too
> Currently, the SVG document lookup is a simple linear search. See
> `find_doc' in `src/sfnt/ttsvg.c'. This is inefficient and I think I
> should convert it to binary search.
Yes – and you've already done so, thanks :-)
Werner
___
> Werner, the integration of a default SVG library in the GNU build
> system (`configure.raw' and `Makefiles') is almost complete now.
Excellent, thanks!
> Should I now integrate it in other build systems too?
Hmm.
> I see mainly two other build systems namely CMake and Jam. If yes,
> which
>> Simply protect the whole code in the SVG module file(s) with
>>
>> #ifdef FT_CONFIG_OPTION_SVG
>> ...
>> #endif
>
> I tried this. But there's one problem with it. The `bzip2' module
> doesn't expose anything apart from some functions. However, my `svg'
> module exposes a renderer class
> 1. The `rules.mk' of the `svg' module compiles the port files. That
>should only be compiled only if a default SVG port is needed,
>otherwise not. So, my question was how do I access this
>information (whether `yes'/`auto' was selected or `no-default')
>in my `rules.mk'. The
> One more thing, in case the user chose `yes' or `auto' and the
> default SVG library wasn't found in the system and neither were the
> environment variables, should we fallback to `no' (No SVG support)
> or `no-default' (SVG code compiled but no default hooks).
If the user chooses `yes' and
>> [...] I believe that my suggested `no-default' mode is a simpler
>> solution; [...]
>
> Okay, so if I have understood this correctly. In case of `auto' or
> `yes', we see if our default is available, and if yes, we use that,
> if the user chose `no-default' then the user would need to plug
>> ... simply use the `PKG_CHECK_MODULES' macro in `configure.raw',
>> which provides both the necessary environment variables and a check
>> whether a proper .pc file is available (the former overrides the
>> latter).
>
> Thanks. I have done the basic work needed to have a default library.
>> imho, just set CPPFLAGS and LDFLAGS accordingly so that header
>> files and libraries are found. These environment variables exist
>> for such purpose
Yes, so...
> However, ultimately when we do decide on a default library, we'd
> wanna have proper configuration for the SVG library in the
> It is supposed to work from an environment variable
> FREETYPE_PROPERTIES too. So please use:
>
> FT_Property_Get( library, "svg", "svg_library", "librsvg" );
> FT_Property_Get( library, "svg", "svg_library", "resvg" );
>
> and then hide the presets and consider proper default
> PS: One easy solution that just came to my mind is making the hook
> structure public and just passing the pointer to it. Only one call
> to `FT_Property_Set'. :)
Yep. Thanks for the quick change!
Werner
___
Freetype-devel mailing list
801 - 900 of 5352 matches
Mail list logo
