On Sat, May 23, 2020 at 6:01 AM Dmitry Timoshkov wrote:
> In addition to CS_HREDRAW | CS_VREDRAW the WM_SIZE handler should call
> DefWindowProc() so that default message processing forces a window update.
> After that the window gets repainted while being resized.
I've achieved the same effect w
> >
> > Indeed we need a callback or... Would a longjmp to break the loop work?
>
> That would leave user32 in broken internal state.
Ok. They also say that PostQuitMessage should get me out of any modal loop.
Can I use that mechanism to stop the resizing loop? What If I quit on any
message? I sho
> On May 23, 2020, at 23:43, Anuj Verma wrote:
>
> Also, the application crashes when the width/height becomes zero.
> So it should check the values of width/height before `gr_win32_surface_resize'
> in the `WM_SIZE' message.
Thank you and Dmitry for your suggestions and testing. Clearly, the
Alexei A Podtelezhnikov, PhD
>> Thank you and Dmitry for your suggestions and testing. Clearly, the smooth
>> resizing is probably not meant to be in Windows by design.
>
> Well, the applications are supposed to render window contents on WM_PAINT,
> and on WM_SIZE change the canvas size. In ot
Hi Anuj,
> I have written the program, you can find it at:
> https://github.com/preversewharf45/freetype2-sdf
> To view the output I'm currently using a small OpenGL framework:
> https://github.com/preversewharf45/freetype2-sdf-demo
> this already has the sdf code.
I like the style. Looks good.
On Mon, Jun 1, 2020 at 2:43 PM Werner LEMBERG wrote:
>
>
> >> However there is an issue with the program, the glyphs which
> >> contain intersecting contours have an issue. (example:
> >> https://imgur.com/MxJfAwY)
> >
> > The intersecting contours used to be discouraged and [are] still
> > quite
On Wed, Jun 3, 2020 at 6:11 AM Niyas k wrote:
> When loading a freetype font, it comes with a bounding-box. We are trying to
> create depressed edge effect by writing the font multiple times in (x-i) and
> (y-i) positions to create the depressed edge effect. Now with the
> bounding-box in pictu
> lol. Intersecting contours have been a reality of TrueType since forever.
> The cedilla on a c always overlapped it. That's why there's a fill rule...
>
lol? Two straight lines intersect inside a square pixel. What's the
coverage? Please come back with a formula when you have it. Stop
giving
On Wed, Jun 3, 2020 at 10:48 PM Anuj Verma wrote:
>
> Hello Behdad, Jim,
>
> > I see that in your implementation you are converting cubics to quadratic
> > spline. That makes a lot of sense and I support that.
>
> Is it better to split the cubic bezier into quadratic one? why? Currently I
> am u
On Wed, Jun 3, 2020 at 11:48 PM Anuj Verma wrote:
>
> Hello Alexei,
>
> > Is 1/65563 not enough accuracy for you? Do not be greedy. What would
> > you gain from extra accuracy in the world of discrete pixels?
>
> 1/65563 is quite enough for SDF, my point is that in a 16.16 fixed point
> I will onl
> Now here the problem what we are facing is when we load the glyph we get the
> data in a bounding box. The glyph which is loaded is a greyscale and it is
> with bounding-box. So when we draw the edges and font as per the above logic,
> the bounding boxes of the edges and the font gets overlapp
On Thu, Jun 4, 2020 at 8:28 AM Aurovind Sagar wrote:
> We are using FreeType. Sorry, the intention was not to report any bug. We are
> looking for suggestions. We are not from graphics background, hence please
> excuse if we have asked any obvious questions.
Guys, you need to learn about alpha
Jim, Behdad,
Please hold your horses. This is Anuj's GSoC project for this summer.
It is not nice to take it over until September. For now, please let
him explore the field. Feel free to discuss your own implementation in
a separate thread or at least povide some explanation instead of
abrupt "8.8
Well. It is your arrogance against my ignorance. Why haven't you
thought about contributing your wonderful DF ideas before? Or, is it
again like HarfBuzz autoshaper that has to be separate and you have to
control it?
On Thu, Jun 4, 2020 at 2:32 PM Behdad Esfahbod wrote:
>
> For more context: I'm
Toshiya-san,
Nowadays, resource fork fonts are seldom used and rarely placed in
weird places like AppleDouble/file or ._file or %file. So I disabled
FT_CONFIG_OPTION_GUESSING_EMBEDDED_RFORK to stop searching around.
This caused fatal build failure.
First,
/freetype2/src/base/ftobjs.c: In function
>> I would also like to test freetype-demos but I'm not sure if those
>> are only valid on desktop configurations.
>
> Yes, it might be problematic to test the demo programs that uses a
> GUI. Maybe (some of) the command line tools will work.
All GUI programs are compiled with a GUIless batch
> > As for bezier curves, there is almost always an overflow because
> > while solving polynomials some large numbers are involved. I even
> > tried using Newton's approximation, but it's too slow and still not
> > as accurate as floating points.
Not a good sign of numerical stability...
> Perha
On Mon, Jun 8, 2020 at 7:37 AM Werner LEMBERG wrote:
> > Since nobody does development on DOS or Windows 9x anymore, we can
> > finally drop the requirement to use file names limited to the 8.3
> > format, which was the reason why the FT_LONG_HEADER_NAME_H macros
> > were introduced in the first p
>> We can remove as well, can't we? It is only used to
>> define the macros. So it is either ft2build.h and macros or neither.
>
> Not until all the consumers of FreeType are adapted to use direct
> header inclusion instead of the macros,
Perhaps I was not clear. There is no point to have #in
Hi David,
I actually thought about FT_Add_Module as a visionary interface for
dynamically plugging alternative renderers:
https://github.com/raphlinus/font-rs
https://github.com/mooman219/fontdue
https://github.com/servo/pathfinder
Admittedly, none of those projects explored this possibility or
On Fri, Jun 12, 2020 at 5:05 AM Moazin Khatri wrote:
>>
>> > Unfortunately, development seems to be stalled; we probably have to go
>> > for something else. Moazin right now is doing another GSoC project;
>> > according to an e-mail exchange with him he plans to work again on the
>> > SVG stuff a
On Fri, Jun 12, 2020 at 7:22 AM Vincent Torri wrote:
>
> On Fri, Jun 12, 2020 at 12:47 PM Alexei Podtelezhnikov
> wrote:
> >
> > On Fri, Jun 12, 2020 at 5:05 AM Moazin Khatri
> > wrote:
> > >>
>
> > Almost certainly, they use FT_Outline_Render w
On Fri, Jun 12, 2020 at 12:31 AM Anuj Verma wrote:
> ... specifically in function `solve_cubic_equation' ...
How many times do you have to solve this for each glyph? How many
different solutions (aka curve points) do you have to find for each
curved segment? I figure there are a lot of grid-curve
On Fri, Jun 12, 2020 at 8:07 AM Stephen McDowell wrote:
> I help maintain the spack package manager when I can, currently users with
> intel compilers cannot build / install any version after 2.7.1 due to the
> usage of __builtin_shuffle (for some reason Intel still doesn't support this).
Is th
On Sun, Jun 14, 2020 at 12:32 AM Anuj Verma wrote:
> A considerable amount of time. If you want the exact number
> it is `width * rows * number_of_conic_curves', without any
> optimization.
I am asking you to do some performance analysis. Specifically, would
you please profile a curve and a strai
Hi Anuj,
> A) Line Segment: ~0.32 microseconds
> B) Conic Bezier: ~1.08 microseconds
> C) Cubic Bezier: ~1.25 microseconds
>
I am very surprised indeed. In the linear case, it is a trivial
cross-product divided by the length of a segment, or the smaller of
two distances to the ends. There are no
Replying to myself...
On Mon, Jun 15, 2020 at 8:11 AM Alexei Podtelezhnikov
wrote:
>
> Hi Anuj,
>
> > A) Line Segment: ~0.32 microseconds
> > B) Conic Bezier: ~1.08 microseconds
> > C) Cubic Bezier: ~1.25 microseconds
> >
>
> I am very surprised inde
On Mon, Jun 15, 2020 at 9:06 AM Anuj Verma wrote:
>
> > Your profiling results indicate that a lot of time is spent
> > calculating distances. Perhaps, you can work with much faster
> > square-distances (they can be signed or signs stored separately) and
> > apply square root as a final processing
On Mon, Jun 15, 2020 at 11:03 AM Anuj Verma wrote:
>
>
> > For linear segments, it will save more than 90% according to your
> > table. Then you will see that splitting Bezier curves is not such a
> > bad option. In general, Bezier curves are used in graphics because it
> > is easy to split and fl
Anuj,
Each curved segment has a large number of neighboring grid points.
each of which has a unique nearest projection on the curve. The curve
is naturally sampled by this projection points a very large number of
times and quite uniformly. Therefore, why not divide the curve into a
large number of
Hi Anuj,
Please let me finish my thoughts below...
>> Each curved segment has a large number of neighboring grid points.
>> each of which has a unique nearest projection on the curve. The curve
>> is naturally sampled by these projection points a very large number of
>> times and quite uniformly.
On Thu, Jun 18, 2020 at 8:01 AM Anuj Verma wrote:
>
> Hello Alexei,
>
> First, about using squared distances instead of `FT_Vector_Length', it
> is much faster to use squared distance. I tested it with a linear case and
> it comes around 0.114 microseconds, which is almost 65% faster than the
> or
On Sat, Jun 20, 2020 at 7:38 AM Anuj Verma wrote:
> Secondly, I did try subdividing the conic curves, for start I simply divided
> them into equal parts and used that to generate SDF. I saw that it require
> at least 32 divisions to produce a decent SDF, which in itself is quite slower
> than simp
On Sat, Jun 20, 2020 at 6:32 PM Behdad Esfahbod wrote:
> Systems without an FPU are vastly less common than they were 20 years ago.
> They still exist, and is a defendable position to want FreeType to continue
> to work on those systems, however:
>
> - Compilers and kernels have stepped up to
Hi everybody,
This is a proof of concept for oversampling to decrease artifacts in
rendering overlaps. The attached images show how the artifact visible
at the top of B, E, F, T decreases as we increase oversampling from
1x1, to 2x2, to 4x4. The price is doubling and quadrupling the
rendering time
Hi again,
The oversampling is implemented though inflating the outline and then
averaging the increased number of cells using FT_RASTER_FLAG_DIRECT
mechanism. The first two patches set the stage by splitting the code
paths for LCD rendering out of the way and trying
FT_RASTER_FLAG_DIRECT for FT_RE
Hi Anuj,
Good job again!
> > foreach line
> >for proximal gridpoints
> > do work
> >
> > where proximal is at most 8 grid units away. The rest is truncated
> > (clamped) at 8. I am choosing 8 because this is probably enough (or
> > not).
>
> I tried this method, and yes it is very (prob
On Tue, Jun 23, 2020 at 3:05 PM David Turner wrote:
>
> [build] Simplify
>
> This patch simplifies the content of ftconfig.h by
> moving things around a little, i.e.:
This greatly consolidates a lot of redundancy in multiple copies of
ftconfig.h too. However, I think you missed the third copy fo
Hello David,
> create mode 100644 include/freetype/config/compiler_macros.h
> create mode 100644 include/freetype/config/integer_types.h
> create mode 100644 include/freetype/config/mac_support.h
> create mode 100644 include/freetype/internal/compiler_macros.h
The same filename albeit in diff
On Wed, Jun 24, 2020 at 12:22 PM Jan Alexander Steffens (heftig)
wrote:
>
> This ensures the includedir for the built FreeType comes first, before
> any flags for a system FreeType which was pulled in through pkg-config
> for harfbuzz.
Committed. Thanks!
H Anuj,
On Fri, Jun 26, 2020 at 8:16 AM Anuj Verma wrote:
> A) Checking all grid points:15.43 seconds (~154ms per glyph average)
> B) Bounding Box check: 0.898 seconds (~8.98ms per glyph average)
> C) Subdivision method : 0.665 seconds (~6.65ms per glyph average)
>
> [for subdivision I e
Hi Anuj,
Thanks for the reference:
> This happens because of underflow, if you check the `solve_cubic_equation'
> function
> (https://github.com/preversewharf45/freetype2-sdf/blob/dcedba69423fc169a9ca95b6391902e1cf27e0b6/src/sdfgen.c#L490)
> there is a term `q3' which is cube of term `q'. So, in
On Sun, Jun 28, 2020 at 10:18 AM Anuj Verma wrote:
> Apart from that, I thought about another optimization:
> Smooth rasterizer is ultra fast, it only takes a few nano-
> seconds to render. So we can embolden the outline by
> spread, render it with the smooth or monochrome rasterizer
> and that wi
David,
On Mon, Jun 29, 2020 at 6:58 PM David Turner wrote:
> So, could have a deep look at the patches here. They're pretty neat. I'll
> just recommend documenting the subtle computations in ft_smooth_slow_spans()
> a little better, and avoid branches altogether, by using bit twiddling to
> pe
Hi guys,
After some more thinking I committed thw oversampling implementation.
It requires new FT_OUTLINE_OVERLAP to use this method consciously.
Alexei
PS: To quickly test it use this one-liner:
diff --git a/src/smooth/ftsmooth.c b/src/smooth/ftsmooth.c
index b32629205..e6d5d04f4 100644
--- a/
Hi Nikolaus
> 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.
You have seen a lot of these fonts. How often the variation fonts set
OVERLAP_SIMPLE or OVERLAP_COMPOSITE ev
>> It is far simpler to rely on the git history for this, and just
>> enforcing that committer provide meaningful commit messages should
>> be enough?
>
> If we can do what Emacs does – namely git commit messages in ChangeLog
> style – I'm all for dropping direct ChangeLog entries.
GCC git-comm
Hi Anuj,
> > Alexei?
>
> Okay, I will probably only need to remove this case statement.
> ```
> case FT_GLYPH_FORMAT_BITMAP: /* already a bitmap, don't do anything */
>break;
> ```
Ok to remove. This only optimizes mistaken calls to FT_Render_Glyph on
bitmap fonts. A related question is whe
> On Jul 16, 2020, at 00:42, Werner LEMBERG wrote:
>
>
>>> I would be less worried about FT_Property_Set if FreeType reserved
>>> the right to remove (ignore) or change properties when it is
>>> reasonable to do so, i.e. properties should not be considered a
>>> part of API.
>>
>> Does tha
Hi Anuj
> Which one do you think is better ? I prefer the second one i.e. adding
> another renderer within the `sdf' module. That way I can share some
> of the code, whereas creating another module will require me to
> rewrite everything.
Same module with two renderers as you described makes se
>> Here's a patch to add a .clang-format style file to the directory.
>
> Thanks. I've slightly improved it, but I think there is still room
> for more fixes. Note that newer `clang-format` binaries have
> additional options; we thus have to specify which version has to be
> used.
Hi all,
I
> > are you compiling static library of freetype ? If you compile a shared
> > library, you should not have this warning
>
> Yes, I am compiling a static library. And yes, they disappear when I compile
> a dynamic library.
It should be controlled by DLL_EXPORT or lack thereof.
Don’t -DFT_EXPORT just yet. Is this because the demos are “illegally” built
with FT2_BUILD_LIBRARY?
Alexei
> On Jul 26, 2020, at 08:02, Anuj Verma wrote:
>
> > for a static lib, FT_EXPORT should be set to nothing. @Anuj Verma add
> > -DFT_EXPORT to CPPFLAGS at configure time
>
> Alright. It
> As you said, I think some recent changes in the
> config file is causing this, it's not there in my own
> branch.
DLL_EXPORT and DLL_IMPORT were dropped but still needed to handle static
libraries.
Alexei A Podtelezhnikov, PhD
> On Jul 26, 2020, at 12:14, Vincent Torri wrote:
>
> On Sun, Jul 26, 2020 at 5:52 PM Alexei Podtelezhnikov
> wrote:
>>
>>
>>> As you said, I think some recent changes in the
>>> config file is causing
Hi folks,
I am looking for a font that sets either OVERLAP_SIMPLE or
OVERLAP_COMPOUND flags. I am having a hard time finding one. Please
help.
Thanks
Alexei
> On Jul 27, 2020, at 12:12, Nikolaus Waxweiler wrote:
>
> 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 f
Hi Anuj,
After I regenerated ftconfig.h with ./autogen.sh the warnings went
away for me. Do you still see it after ./autogen.sh?
Alexei
On Mon, Jul 27, 2020 at 2:01 PM Nikolaus Waxweiler
wrote:
> I mean use the script to set it 😁 the usual compiler suspects don't set
> it by themselves currently afaik
>
Now we have oversampling to deal with overlaps, but I don't clearly see
when to enable it. On one hand, the OVERLAP_SIMPLE and
> 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 modifyin
> The warning is because of the ` FT_INTERNAL_FUNCTION_ATTRIBUTE'
> macro which is defined to . So defining
> it to nothing fixes all the warnings.
That's the thing on win32: you are not supposed to even get to
__attribute__((visibility("hidden")).
You must use __declspec(dllexport), __declspec(dl
Hi Werner,
> Please improve his patch (now in git) if necessary!
Thanks, I will try to revert closer to the original logic where
attributes were only used ifdef FT2_BUILD_LIBRARY. I thought it was
sensible.
On a related note, is there interest in HP C/HP aC++ support of hidden
symbols? I have nu
Hi Dominik and others
On Fri, Jul 10, 2020 at 7:17 AM Dominik Röttsches wrote:
> I've made some progress with the COLR v1 extension implementation in
> FreeType and would be happy to hear initial feedback on the general
> approach and API style.
Let me repeat myself by saying that I am not parti
| 1 +
src/truetype/ttgload.c | 23 +++
4 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index e96ec6101..e64fc23da 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2020-08-01 Alexei Podtelezhnikov
+
+ [truetype] Retain
Hi Werner et al.,
Please review the patch if you agree with the placement of the flag
retention code.
Hi Dominik.
Last time you wanted to be warned about expected pixel differences.
Once applied this will produce pixel differences for glyphs with
OVERLAP_SIMPLE and OVERLAP_COMPOUND.
Thank you,
Hi Anuj,
> I have mostly completed the bitmap to SDF renderer (bsdf), there
> are only a few things remaining such as support for all pixel
> modes (currently it only work with FT_PIXEL_MODE_GRAY),
Only FT_PIXEL_MODE_MONO is necessary to add. I do not understand how
LCD or BGRA can be used for SD
Hi Priyesh
On Mon, Aug 3, 2020 at 10:33 AM Priyesh kumar wrote:
>
> Hi Alexei,
> Is there any update for me regarding Werner's previous mail?
>> > The dlg project contains two configurations: `Debug' and `Debug
>> > Static' on both `x64' and `Win32' platforms and will be built with
>> > FreeType,
Hi Pryiesh,
I am sorry I was not following your logging project closely enough. So
I asked the most general question.
On Tue, Aug 4, 2020 at 7:32 AM Priyesh kumar wrote:
>
> Hi Alexei,
> Thanks for replying.
>
> > It looks ok as far as clean separation. I don't quite understand why
> > you need
> > I would much rather prefer that
> >
> > 1) FT_Load_Glyph sequentially loads and merges all contours from all
> >layers into a single outline and uses FT_GlyphSlot->other to tag
> >each contour with the layer information and the corresponding
> >comprehensive (including gradient) col
Hi Anuj,
> > If I understand correctly, overlaps cause unexpected discontinuity in
> > SDF, which otherwise should not have any. I doubt that detecting and
> > removing contour overlaps is productive. I would rather deal with the
> > discontinuity directly. Perhaps there is a clever way to ignore
On Fri, Aug 7, 2020 at 12:54 AM Anuj Verma wrote:
>
> Hello Alexei,
>
> > Can you describe discontinuities with the same sign if I overlook them?
>
> So, I found there are two types of discontinuities due to overlapping
> contours:
>
> A) Discontinuity in sign. (i.e. there is a sudden jump from n
On Fri, Aug 7, 2020 at 10:58 AM Anuj Verma wrote:
>
> > Yeah. We should basically think of overlaying or combining two
> > distance fields, generated independently one for each contour.
> > Has this been discussed in the literature?
>
> No, it has not been. That sounds interesting, thanks for the
> I.e. always choose a smaller value combining two contours so it seems
This might be oversimplified, but it is clear that the sign is
supposed to agree with the winding number and the priority of
distances should be defined by the fill rule.
Hi Dominik
>> Last time you wanted to be warned about expected pixel differences.
>> Once applied this will produce pixel differences for glyphs with
>> OVERLAP_SIMPLE and OVERLAP_COMPOUND.
>
> Thanks for the heads-up! This one seems to have gone green on our bots and
> did not produce pixel diff
Hi Kleber,
> https://github.com/klebertarcisio/freetype2-1/commit/aab3c841f08c3a67914fbd0167ef4ff174116ccf
What is wrong with a couple of housekeeping lines before returning the
error? Why do you think that it is necessary to drop everything and
run for cover? In fact, libraries are not supposed
> In the first case, I think we need return because ttsize can be NULL and
> t42size->ttsize = ttsize; could get a NULL value.Is it a problem, no?
> In the first case, I think we need return because ttslot can be NULL and
> slot-> ttslot = ttslot; could get a NULL value.Is it a problem, no?
Why
);
> if(!error)
> t42size->ttsize = ttsize;
> FT_Activate_Size( ttsize );
>
> Regards
>
> Kleber
>
> Em quinta-feira, 20 de agosto de 2020 16:17:27 BRT, Alexei Podtelezhnikov
> escreveu:
>
>
> You need to reply to the list.
>
--
Alexei A. Podtelezhnikov, PhD
Hi Werner,
> how do I specify keys like 'F5' with the `-k` command line option to
> the various FreeType demo programs?
I don't think it is possible because grKeyF5 is 0x105, which would be wchar_t.
It is either that or rethink and harmonize control keys more carefully.
Alexei
--
Alexei A.
> >> how do I specify keys like 'F5' with the `-k` command line option to
> >> the various FreeType demo programs?
> >
> > I don't think it is possible because grKeyF5 is 0x105, which would
> > be wchar_t. It is either that or rethink and harmonize control keys
> > more carefully.
>
> Could you in
On Fri, Aug 21, 2020 at 2:11 PM Werner LEMBERG wrote:
>
> >> > I don't think it is possible because grKeyF5 is 0x105, which
> >> > would be wchar_t. It is either that or rethink and harmonize
> >> > control keys more carefully.
> >>
> >> Could you invent something? Being able to insert functions
> > I'm wondering when the issue migration is complete? Or am I missing
> > something?
>
> Right now we are in a preparation phase. No need to rush.
It is not about UI but about community. To me,
https://gitlab.freedesktop.org feels like the right community to move
in. Thanks to Alan for the invi
Hi David,
Other build systems 'sed' to the main copy of ftoption.h, which is
then installed and provides a record of compiled features. Werner
convinced me that it is a good thing to have. It will be a nightmare
to maintain them if each build system has its own version while lose
track of compiled
Hi Werner,
Have you considered dropping infinality especially after v40 have been
integrated and used to great acclaim? It is hard to maintain it with
hardly any benefits. Reading ttinterp.c is prohibitively hard because
Infinality is so invasive.
Thank you,
Alexei
Hi Nicholaus,
> 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.
Is there anything beneficial in Infinality that you forfeit in your
code? Or is there room to improve v40 short of the Infinality manual
ex
On Sat, Aug 29, 2020 at 11:11 PM Anuj Verma wrote:
> You can check it out here:
> https://gitlab.com/-/snippets/2007070
Thank you for this project! This is unbelievable amount of work for
just one summer. Please stay in touch and good luck in your future
adventures!
Alexei
On Thu, Sep 3, 2020 at 6:53 AM Werner LEMBERG wrote:
>
>
> > Any decision yet on whether it should be gitlab.com or
> > freedesktop.org?
>
> Nope. We haven't yet contacted the freedesktop.org people. Do you
> want to do that?
>
> Additionally, I don't want to rush this so that more people can ch
> > Any decision yet on whether it should be gitlab.com or
> > freedesktop.org?
>
> Nope. We haven't yet contacted the freedesktop.org people.
This could be an opportunity to collect all pieces together because
the web page is already hosted on cgit.freedesktop.org. I have no idea
if features are
Hi all,
This is a warning about two fixes in the raster module. See the discussions in
https://savannah.nongnu.org/bugs/index.php?58352
https://savannah.nongnu.org/bugs/index.php?58373
They will subtly change the FT_RENDER_MODE_MONO results bringing it
closer to the OpenType specifications and th
On Sat, Sep 12, 2020 at 12:07 PM Greg Williamson wrote:
>
> You should be able to run the tests I made for my gsoc project locally
> on any linux machine. There are instructions in CI/readme for running
> them
Hi Greg,
Are you aware of -k option or rather -kPq sequence to dump PNG (eg
ftgrid.png
a blink test too?
> It should be
> pretty simple to swap out my xvfb command with whatever you want
> though.
>
> On Sat, Sep 12, 2020 at 1:53 PM Alexei Podtelezhnikov
> wrote:
>>
>>> On Sat, Sep 12, 2020 at 12:07 PM Greg Williamson
>>> wrote:
>
Hi all,
These are some horrible numbers that essentially test FT_Load_Glyph
from compressed unifont.pcf.gz in reverse order:
$ time bin/ftstring -k3q -mZYXWVUTSRQPONMLKJIHGFEDCBA 15
../unifont-12.0.01.pcf.gz
FreeType String Viewer - press ? for help
Execution completed successfully.
real0m6.
> Patch attached for avoid adding lib prefix when compiling with mingw and also
> letting to use FT_CONFIG_OPTION_ERROR_STRINGS from cmake command line.
The lib prefix is your personal aversion. Would this work for the second wish?
cmake -D PUBLIC=FT_CONFIG_OPTION_ERROR_STRINGS or something
On Fri, Sep 18, 2020 at 7:18 AM David Turner wrote:
> Le jeu. 17 sept. 2020 à 14:01, Werner LEMBERG a écrit :
>
>> > These are some horrible numbers that essentially test FT_Load_Glyph
>> > from compressed unifont.pcf.gz in reverse order: [...]
>>
>> We do, there is no "rewinding the compressed
Let's not clog the src folder please
src/base/amiga (not src/amiga)
src/base/unix (not src/unix)
> don't you think that all those (source) files should be in src/ ? I
> > would find these more logical. Maybe in subdirectories of src (like
> > src/unix src/mac src/windows etc...)
On Mon, Sep 21, 2020 at 1:54 AM Werner LEMBERG wrote:
>
> > All right, here's the same set of patches with Black applied.
>
> Applied to the repository, with some changes here and there. Please
> check
Please consider moving scripts into the build/meson folder for consistency.
This is where cm
> > So, we've had a report that building Ghostscript against Freetype
> > 2.10.3 fails because FT_CALLBACK_DEF() has been moved to internal
> > use only.
> >
> > Ghostcript supplies callbacks for memory management
> > (i.e. FT_MemoryRec) and we used FT_CALLBACK_DEF() for those, which
> > seemed log
Hi all,
I have added icons to ftgrid, ftview, and ftstring. The EPS version is
attached too. I thought that little branding would not hurt. Please comment.
Alexei
> > As I said, I'm quite happy just changing our callbacks to be directly
> > declared static functions. I just want to check that's what's intended,
> > and that there isn't a replacement for/alternative to FT_CALLBACK_DEF()
> > that we should be using.
>
> So, in the absence of any alternative gu
> For my taste the 'FT' glyphs are a bit tall. What do you think of
> reducing the height a bit?
>
It has to be grid-fitted into a 16x16 icon, which is rather universal with
larger sizes scaled up. There is 1 pixel margin on all sides. I could not
convince myself to adjust these margins yet: it i
> withdrawn macro that wasn't intended for external usage
We should drop it from the demos too, shouldn't we?
501 - 600 of 1041 matches
Mail list logo
