Good afternoon,
When building FreeType, GCC is warning of strncpy() calls which are not nul
terminated.
Probably not a big problem in view of the context.
Example :
src/ftchkwd.c:172:9: warning: 'strncpy' output truncated before terminating nul
copying 4 bytes from a string of the same length
On Fri, Apr 24, 2020 at 4:02 PM David Turner wrote:
> Voila, I'd be happy to read your suggestions, Happy to be here.
Welcome back, David!
If you still enjoy coding the renderers... We need to implement a
color one and deal with FT_Glyph and FT_GlyphSlot insufficiencies for
that. I made some
Le lun. 27 avr. 2020 à 18:09, Ben Wagner a écrit :
> One thing that's been on my mind is around releasing (and this is a
> fairly general observation not specific to FreeType). FreeType has
> generally tagged a VER-2-X-X release about once every six months and
> hasn't had maintained release
Le ven. 24 avr. 2020 à 22:46, Nikolaus Waxweiler a
écrit :
> 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.
Can you clarify what that means
Thank you, filed as https://savannah.nongnu.org/bugs/index.php?58275 now
Le mer. 29 avr. 2020 à 18:18, WILSON, MICHAEL a
écrit :
> Good afternoon,
>
>
>
> When building FreeType, GCC is warning of strncpy() calls which are not
> nul terminated.
>
> Probably not a big problem in view of the
Starting a thread here to discuss potential build system improvements for
FreeType.
The current FreeType 2 build system has many flaws. To its credit, it was
designed in a very different time, when things like CMake / Meson / Ninja/
Maven / GN / Bazel didn't even exist, when Autotools was
Le lun. 27 avr. 2020 à 18:21, Vincent Torri a
écrit :
> Hello
>
> not a pressure issue, but i would like to have VF driver. A Summer of
> Code task has begun, never finished, though.
>
> Are you talking about TeX Virtual Fonts, or OpenType Variable Fonts here?
For the former, that sounds like a
>> [...] I think it would be helpful if FreeType (and more open source
>> projects) tagged bugfix releases more often.
Tagging is the easy thing, but doing the release process is tedious,
for which I often lack time and, admittedly, energy.
> We should probably look at the patches applied on
>> not a pressure issue, but i would like to have VF driver. A Summer
>> of Code task has begun, never finished, though.
>
> Are you talking about TeX Virtual Fonts, or OpenType Variable Fonts
> here?
He talks about the former. Support for OpenType VFs is already part
of FreeType.
> For the
>> 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.
>
> Can you clarify what that means exactly? I think I lack context
> and/or examples :-)
I leave
> [...] I have experience with CMake (I find it a vast improvement
> over auto-tools for package / feature detection, but a hot mess for
> about anything else), GN/Ninja (very powerful, but essentially
> requires too much dependencies to get the most out of it) and Bazel
> (can be hard to get
On Thu, Apr 30, 2020 at 2:34 AM David Turner wrote:
>
> Starting a thread here to discuss potential build system improvements for
> FreeType.
>
> The current FreeType 2 build system has many flaws. To its credit, it was
> designed in a very different time, when things like CMake / Meson /
On Wed, Apr 29, 2020 at 8:34 PM David Turner wrote:
>
> Starting a thread here to discuss potential build system improvements for
> FreeType.
>
> The current FreeType 2 build system has many flaws. To its credit, it was
> designed in a very different time, when things like CMake / Meson /
On Fri, Apr 24, 2020 at 4:02 PM David Turner wrote:
> Voila, I'd be happy to read your suggestions, Happy to be here.
.. and another project is on the table after we lost Moazin's GSoC
proposal on font-rs. I was actually advocating for a couple of
FT_Renderer modules for alternative rasterizers:
Dear Alexei, Turner,
It is a pity that I hear the lack of -fvisibility=hidden is
not only current status but promised in the future release X-(.
BTW, during the participation to Poppler and SVG Native Viewer,
I had big headache by the CMake's lack of the seamless (or
side-by-side) support for
On Wed, Apr 29, 2020 at 10:17 PM suzuki toshiya
wrote:
> It is a pity that I hear the lack of -fvisibility=hidden is
> not only current status but promised in the future release X-(.
Suzuki san,
We have -fvisibility=hidden despite libtool.
Alexei
16 matches
Mail list logo
