On Thu, May 23, 2024 at 3:16 AM Alexei Podtelezhnikov
wrote:
>
> Hi Hin-Tak,
>
> These macros were never used before. I fixed them. Now I think they
> made the code less readable and I might revert to the old code.
>
> Thanks,
> Alexei
>
> On Wed, May 22, 2024 at 6:
Actually it might be a good idea to stick CC=g++/clang++ as an additional job
in .gitlab-ci.yml ? I mean, it already does gcc and clang.
On Wednesday 22 May 2024 at 23:05:47 BST, Hin-Tak Leung
wrote:
Should be obvious - needs casting from "void *" to "unsigned
Should be obvious - needs casting from "void *" to "unsigned char *" and etc...
Shouldn't be too hard to see yourself with CC=c++ when building...
In file included from
On Friday, 10 May 2024 at 09:03:52 BST, Werner LEMBERG
wrote:
> > [...]
> >
> > But before that, we probably want to get ft2-demos having its own
> > ./configure (or cmake equivalent) first. It is a bit wierd that
> > detection of librsvg happens at freetype's configure (and freetype
On Wednesday 8 May 2024 at 05:09:36 BST, Alexei Podtelezhnikov
wrote:
> On Mon, May 6, 2024 at 2:27 PM Hin-Tak Leung
> wrote:
> >
> > I have set up a repo for the skia ot-svg patch, updated it for skia m125
> > (out two weeks ago; skia-python m12
I have set up a repo for the skia ot-svg patch, updated it for skia m125 (out
two weeks ago; skia-python m124 was released last week and there is a pull for
m125), and set up github CI to build it against current freetype git head.
https://github.com/HinTak/freetype2-demos-skia/
Documentation
Hi,
I have upgraded to fc40 last week, and there has been some breakage of
skia-python against current skia lately, so I thought I'd update and rebuild
the skia-enabled ft2-demos, now ported over to github CI against freetype git
head. (next e-mail). Since skia is c++, requires setting CC=c++.
bind mount (and anything invoking mount) requires root privilege, except for
fusemount and some removable medium use cases - even that is often disabled
based on site policy.
Using proot-me seems to be no better than the original poster's - depending on
a peculiar way of doing things
and we are trying
our best to follow POSIX/Unix standards and it has been successful so
far ;-).
Cheers,
Mohammad
On 5/3/24 12:33 AM, Hin-Tak Leung wrote:
> Hmm, why are you trying to compile an older version of freetype (2.11.x),
>when arch linux ships 2.13.x ?
> Anyway, here is h
Hmm, why are you trying to compile an older version of freetype (2.11.x), when
arch linux ships 2.13.x ?
Anyway, here is how the Arch Linux people build freetype - they use meson
instead of autoconf (PKGBUILD itself is largely a shell script with, divided
into shell script routines):
You mean former (instead of latter), ftinspect already depends on Qt?
I think you may be looking something in the "AppKit" namespace, whichever
language binding you use... for the widgets, windows and buttons.
On Thursday, 2 May 2024 at 16:17:02 BST, Werner LEMBERG
wrote:
> Again the
Quartz seems to have CGBitmapContextCreate/CGBitmapContextCreateImage ... just
reading random bits of Just's python code.
On Thursday, 2 May 2024 at 15:57:47 BST, Alexei Podtelezhnikov
wrote:
Xlib uses XPutImage.
Windows uses SetDIBitsToDevice.
What does macOS use?
Swift is a language and a runtime; python is also a language and a runtime...
objective c is a compiled language, extended c. They all provide binding to the
platform's GUI toolkit. (cocoa/quartz). Swift on Linux doesn't bind to cocoa
(nor x11, I think - not familiar with it). If you are going
Besides what Werner said - name your system. Most of the world has converged
on GNU bash, but Ubuntu/Debian uses dash, some older Solaris used ksh. Some
really old unix system (tru64 came to mind) has genuine BSD sh. You wrote about
lacking the privilege to be root, so I guess you are not
I think Swift runs on Linux also these days, but perhaps without any GUI
bindings. I considered installing it at some point but it is quite large (even
without GUI) binding. Size we are talking about similar to Rust and Java.
Open GL on Mac OS X is on the way out and quite buggy/behind mesa on
(Not official) some of the freetype gsoc ideas are fairly long-term, and if it
isn't done yet, then it is available. Specifically, I am not aware of any build
system changes in the past 12 months.
You are welcomed to come up with your project ideas, not necessarily need to be
on any official
Podtelezhnikov
wrote:
On Jan 22, 2024, at 12:45, Hin-Tak Leung wrote:
FWIW, this seems to duplicate functionality in harfbuzz, and also a mere
subset, for that matter?
On the other hand, the dysfunctional kerning API, which exists, is misleading.
Partial GPOS support to fulfill the API
FWIW, this seems to duplicate functionality in harfbuzz, and also a mere
subset, for that matter? It is rather a dead-end development direction? I think
the question is, at what point do you stop? AFAIK, this kind of functionality
was removed quite intentionally from freetype and moved to
Yes, I think I had an fd gitlab account ages ago but after not using it for a
while it got disabled and I am having problem re-enabling it again. Anyway, I
have never used the fork/pull/merge facility on gitlab with freetype ever, and
it has always been the old-fashion way - how git was
I think I agree with this - the spec should not bend on
limitations/quirks/bugs in freetype. It isn't the role of the spec to recommend
fonts to be built in with special "hints", just because one implementation, in
its current state, can't render satisfactorily without those "hints".
And, we
This is the same as the winding rule concept (overlap once = wounded twice)
... I seem to remember one of them is even-odd and the other is non-zero, and
quite fundamental difference between truetype and cff.
On Tuesday, 19 December 2023 at 13:54:21 GMT, Alexei Podtelezhnikov
wrote:
It is still not exactly clear what you are trying to do, and how/why you are
going about it. Feeetype-py for windows AFAIK bundles the freetype dll,
although there is a not yet merged pull which tries to build the bundled
freetype dll with more
Both comments from Alex are wrong...
freetype-py has its own versioning, it is confusing, but 2.4.0 is current:
https://github.com/rougier/freetype-py/releases
And has its init hook too:
https://github.com/rougier/freetype-py/blob/master/freetype/__init__.py
I think that the python load path
The binary wheels are being built and deployed at the moment.
https://github.com/kyamagu/skia-python/releases/tag/v120.0b5
The combination of OT-SVG on-by-default for freetype and directwrite, and the
option to use freetype to load fonts on non-linux, should imply that OT-SVG
fonts should "just
On Monday, 23 October 2023 at 17:36:09 BST, Werner LEMBERG
wrote:
> > I recently had to extract a TrueType font from a TTC font collection
> > as part of fixing bugs in the podofo library[1].
> In general, FreeType is not the right tool for such operations.
> FreeType is a *rendering*
). I shall do that now and
also put a symlink to m118 too, since it is identical.
On Thursday, 28 September 2023 at 13:30:42 BST, Hin-Tak Leung
wrote:
The answer to the first question, as a whole, is no. Skia people don't
guarantee anything. Skia is always statically linked to google
The answer to the first question, as a whole, is no. Skia people don't
guarantee anything. Skia is always statically linked to google chrome for that
reason; shared library builds are there as is but not really supported. That
said, the ft2-demos skia-port code use very little of skia, and
A few things...
- skia-port.[ch] isn't the only OT-SVG bridge - it is better than
rsvg-port.[ch] (rsvg/cairo-based) in skia's svg processing is more complete.
but rsvg-port.[ch] are already in.
- skia has a 4-6 week release cycle. I started with m116; m117 didn't change
much as far as the
s there a priority?
Best,Goksugoksu.inOn 17 Sep 2023 02:31 +0300, Hin-Tak Leung
, wrote:
I just remember something - the windows' implementation of ANSI / POSIX timing
routines are especially poor -
e.g.https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timege
I just remember something - the windows' implementation of ANSI / POSIX timing
routines are especially poor -
e.g.https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timegettime
So unfortunately if you are trying to measure time on Windows accurately, you
:12 BST, Hin-Tak Leung
wrote:
Hmm, "nanoemoji color font compiler" is maintained by? It is largely for
simplicity - you can try find some colour fonts from other sources which show
the same problems?
On Monday, 4 September 2023 at 13:21:11 BST, Cosimo Lupo
wrote:
s, because there are OT-specific semantics. Can you
please stop referring to these as the "Google OT-SVG", there is nothing
particularly Googley about it. Thank you.
On Mon, Aug 21, 2023 at 5:15 PM Hin-Tak Leung
wrote:
Just put it through:
https://github.com/rougier/freetype-py/blob/ma
On Friday, 25 August 2023 at 05:38:14 BST, Alexei Podtelezhnikov
wrote:
> Infinality (v38) was substituted by v40 in 2.13.1. Anybody requesting
> v38 got v40 instead... and nobody even noticed. That is the whole
> point of the exercise: v40 is perfectly capable and better than just
> good
with a
bundled skia, so you don't have to build it yourself.
The plan is to release skia-python m117 b3, whatever state it is, when upstream
m118 appears (in about two weeks' time...), etc, until about m130 b16, at least.
On Thursday, 27 July 2023 at 00:43:00 BST, Hin-Tak Leung
wrote:
Hi
On Sunday, 20 August 2023 at 18:28:54 BST, Dave Crossland
wrote:
> Since almost all new fonts are vf, I'm no longer seeing ttfautohint in
> common usage, but I don't think it's effected by this.
That's not necessarily true - people with poorer monitors are also likely to be
less
On Friday, 18 August 2023 at 22:27:26 BST, Werner LEMBERG wrote:
> > Are we getting into a situation where ttfautohint is hinting for the
> > (limited) "good enough" light hinting model of recent freetype?
> It's not clear what you are actually asking. ttfautohint is an
> incarnation of
Hi,
Yesterday's opentype font meeting touched upon hinting and ttfautohint briefly.
I see the infinality patch is already gone (next release, 2.13.2 I guess - bits
of it was removed in 2.13.1 already). Question is, does its removal impact the
functionality of ttfautohint? Are we getting into a
On Friday, 18 August 2023 at 00:21:41 BST, Ahmet Göksu
wrote:
> about outliers, i splitted every tests into chuncks that is sized 100. Made
> IQR calculations and calculated average time on valid chunks. you can find
> the result in the attachment also pushed to gitlab.
> also,
On Saturday, 12 August 2023 at 17:17:47 BST, Werner LEMBERG
wrote:
> > It is one of those things I never remember - winding rule of
> > truetype and postscript are different, one is even-odd, the other is
> > non-zero. [...]
> You are on the completely wrong track here. What I'm
It is one of those things I never remember - winding rule of truetype and
postscript are different, one is even-odd, the other is non-zero. That concerns
the number of times a line joining an "interior" (inked) point going to
infinity, how many times it crosses the glyph contour.
Anyway,
people won't
notice the difference or miss anything by moving to 116b2 (hopefully).
On Thursday, 27 July 2023 at 00:43:00 BST, Hin-Tak Leung
wrote:
Hi, it has been a while with any traffic on the create list.
I have had some fun recently with downloading and building skia with ~80MB
newor
patch will land in the building fun repo at some point, to
patch skia with a few extra routines etc to make getting at COLRv1
functionality easier...
On Monday, 24 July 2023 at 09:59:32 BST, Hin-Tak Leung
wrote:
Hi,
The most exciting thing I have done this weekend, is managed to have
Hi,
The most exciting thing I have done this weekend, is managed to have a
procedure/patch-sets to build current skia with max download/clone of about
80MB and max disk usage of about 300MB. Skia takes about 40 minutes to build on
dual-CPU (or about 70 minute on single CPU). Without
On Friday, 21 July 2023 at 07:28:07 BST, Craig White
wrote:
> ...Those would be one-to-one mappings and many-to-one mappings, respectively.
> Would this general solution involve other kinds of GSUB mappings? ...
> Even sticking to just many-to-one and one-to-one mappings, ...
Having too
es I have...)
Pretty-sure some of you want to hear less often from me now :-). I'll update my
system binaries with the 4-hook diff at some point(goes to
FontVal-extras/binary-archive/), and carry on with colrv1.
On Thursday, 20 July 2023 at 15:01:54 BST, Hin-Tak Leung
wrote:
It to
On Wednesday, 19 July 2023 at 05:55:20 BST, Werner LEMBERG
wrote:
> Different colour schemes are supported; the question is about
> defaults. For example, let's assume that a font contains color
> schemes A and B, the latter suitable for (most) color-blind people.
> Let's further
On Thursday, 20 July 2023 at 01:41:51 BST, Alexei Podtelezhnikov
wrote:
> > > Hin-Tak,
> >
> > > This is probably both a spec question & a technical question. What is the
> > > recommendation for COLRv1 when the rendering target media is not capable
> > > of color?
> >
> >
> Alpha
On Thursday, 20 July 2023 at 09:04:09 BST, Brad Neimann
wrote:
> > Perhaps it is easier just to show you what I have - this is already
> > functional and I can even switch COLRv1 palettes in ftgrid
> > (screenshots the usual place).
> …and where is this ‘usual place’? I can’t see
It took less than an hour of quick hack to get rid of librsvg and replace it
with Adobe Native + its cairo backend from Suziki san.
There is a rendering bug filed
ashttps://github.com/adobe/svg-native-viewer/issues/185
I said it is between librsvg and skia.
The code diff is
Perhaps it is easier just to show you what I have - this is already functional
and I can even switch COLRv1 palettes in ftgrid (screenshots the usual place).
Basically it works the same ways as svg hooks: the preset slot hook calculates
the bound boxes, while the render hook actually draws to
Adobe's SVG native is half way between librsvg and skia's svg rendering.
Screenshots of 3 at
https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure
And diff against the skia-port code in the ../svg-native/ directory above, and
a lot more screenshots.
It shouldn't be hard to
On Wednesday, 19 July 2023 at 05:07:42 BST, Werner LEMBERG
wrote:
> >> ... please post a link to the report if you do so :-)
> https://gitlab.gnome.org/GNOME/librsvg/-/issues/997
> By the way, is there any progress whether Adobe's compact SVG native
> viewer library can be used as a
On Wednesday, 19 July 2023 at 15:27:20 BST, Alexei Podtelezhnikov
wrote:
> Hin-Tak,
> This is probably both a spec question & a technical question. What is the
> recommendation for COLRv1 when the rendering target media is not capable of
> color?
> Are you asking about RGB to gray
On Wednesday, 19 July 2023 at 05:42:32 BST, Werner LEMBERG
wrote:
> > How to throw away the bitmap resulting from running
> > FT_Glyph_To_Bitmap(), and replacing it with a new one that may be
> > one pixel large or smaller in width and/or height?
> It's not exactly clear to me what you want
On Wednesday, 19 July 2023 at 05:19:40 BST, Werner LEMBERG
wrote:
> > I’m colour-blind, but not sure I understand what you’re asking
> > here. None of the colour fonts on Google Fonts seem obviously
> > difficult to read for me.
> Let's assume that you can't discern colors A and B, where
it does happen). I don't seem to be
about to create my own bitmap - it always crashes - so my question is exactly
that:
How to throw away the bitmap resulting from running FT_Glyph_To_Bitmap(), and
replacing it with a new one that may be one pixel large or smaller in width
and/or height?
Hi,
This is probably both a spec question & a technical question. What is the
recommendation for COLRv1 when the rendering target media is not capable of
color?
OT-SVG probably has its rules inherited from SVG; or at least, it doesn't feel
too odd to use SVG solely for color output, and
On Monday, 17 July 2023 at 05:46:37 BST, Werner LEMBERG wrote:
> ... please post a link to the report if you do so :-)
https://gitlab.gnome.org/GNOME/librsvg/-/issues/997
Inkscape always shows opaque black. (That's why I assumed that Google folks
shipped inferior SVG table in their COLRv1
On Monday, 17 July 2023 at 05:46:37 BST, Werner LEMBERG
wrote:
> > [...] I seem to have found a problem with the rsvg/cairo-based hook
> > with the Google Nabla color font.
> >
> > [...] I found that rsvg+cairo hook renders it B/W [...]. Strangely
> > enough, with the skia-based
On Monday, 17 July 2023 at 05:52:36 BST, Werner LEMBERG wrote:
> > Btw, anybody done QT6 build of ftinspect lately?
> Well, looking into `src/ftinspect/{meson.build,CMakeLists.txt}` I only
> see build support for Qt5. Apparently, Qt6 support was tested
> experimentally only.
> Charlie,
Missing API - same missingness as Skia's SVG parser before m103, as far as I
can see. (Or maybe I didn't look thorough enough :-)).
Interesting to have another svg library, I guess. Associated with tizen so
probably backed by Samsung, and the non-google/apple mobile industry.
On Monday, 17
On Sunday, 16 July 2023 at 07:02:50 BST, Werner LEMBERG wrote:
> > That fundamentally means it is not possible to switch the renderer
> > hook on a per current glyph level, keeping the current face?
>.I don't think so – who wants that except weird FreeType demo
> programs? :-)
> Moazin,
Btw, anybody done QT6 build of ftinspect lately?When I was writing the
makefile, I had to install some qt5*-devel packages. I did some qt3/qt4 stuff a
long time ago, so I kept those, but uninstalled most of qt5-dev stuff when I
see qt6 being installed as part of half-yearly upgrade. I am on
Yes, the moc location on fedora 38 can be queried with:
pkg-config Qt5Core --variable=host_bins
If this works correctly on other systems, we should set
MOC=`pkg-config Qt5Core --variable=host_bins`/moc
Or put PATH=${PATH}:`pkg-config Qt5Core --variable=host_bins` and MOC=moc ?
I am more inclined
On Sunday, 16 July 2023 at 07:54:11 BST, Brad Neimann
wrote:
> ...Can anyone explain what’s
> happening here? I would expect that, if the diacritic is to be hinted as
> a horizontal bar, that would occur only at the smallest sizes, and would
> equally affect the combining diacritic too.
On Sunday, 16 July 2023 at 07:13:20 BST, Werner LEMBERG wrote:
> > I added a "-s" command line option to both ftview and ftgrid to swap
> > rsvg out with skia and run the same binary twice, one with "-s" and
>.> one without, just to look at them side by side. Fixed the pixel
> positioning
s it a wrong approach? i
remember something about not to using gcc in past mails.
Best,Goksugoksu.inOn 12 Jul 2023 22:17 +0300, Hin-Tak Leung
, wrote:
(Please keep the CC to freetype-devel)
libtool is also heavily in the GNU family, although mainly maintained by the
people at https://sourcewa
on't advertise it, but FontVal-extra/binary-archive
on github have rpm's built for fedora 38 I used myself, and have the fontval
diff patched in etc. I am thinking of rebuilding my system ftview/frgrid with
this patch. If it happens, the rpms will land there.
On Thursday, 13 July 2023 at 04:04
On Friday, 14 July 2023 at 03:53:10 GMT+8, Werner LEMBERG
wrote:
> Well, this is not how Meson support is currently set up in
`freetype-demos`: in `subprojects/freetype.wrap`, HEAD of FreeType's
> git repository is used. This is absolutely necessary while developing
> since we regularly
From: Hin-Tak Leung
Date: Thu, 13 Jul 2023 18:30:05 +0100
Subject: [PATCH] rsvg-port.c: Correct usage of FT_Bool vs gboolean comparison
`TRUE' in this context is from glib headers (glib-2.0/glib/gmacros.h)
imported indirectly from rsvg headers. It should not be used
for comparison with FT_Bool
On Thursday, 13 July 2023 at 22:46:38 GMT+8, Hugh McMaster
wrote:
> If we are going to overhaul the build system, I’ve long wanted to have
> FreeType demos build as a separate package that links against a
> system-installed FreeType library (not the source directory).
I second that! I
dd C++ version check &
pkg-check for Qt5 :-)
Regards,
mpsuzuki
On 2023/07/13 11:30, Hin-Tak Leung wrote:
> Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both
> to revise my makefile-fu, and perhaps as an educational tool for one of the
> gsoc people str
e for saying such an inflexible thing, but,
please reconsider the cross-posting (between the FreeType
developers list and the MPEG-OTSPEC list) for highly-
professional and deep implementation-dependent discussion
specific to FreeType.
Regards,
mpsuzuki
On 2023/07/13 4:43, Hin-Tak Leung wrote:
>
Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both
to revise my makefile-fu, and perhaps as an educational tool for one of the
gsoc people struggling with makefiles.
Here is a bare-minimum sketetal makefile for building ftinspect. It is written
to be minimal, it
:-).
On Wednesday, 12 July 2023 at 07:28:15 BST, Hin-Tak Leung
wrote:
See attached screenshot. Left is skia-based ftview/ftgrid, right is my
system-wide ftview/ftgrid 2.13.0 (based on rsvg/cairo). The default zoom level
for ftgrid seems to have changed between 2.13.0 and 2.13.1 from 4 t
le to binary (even by terminal
commands, manually).
like:
libtool —mode=link ftbench.o -o ftbench
some binary, flag or parameter needed i think.
Thanks,
Goksu
goksu.in
On 12 Jul 2023 6:12 PM +0300, Hin-Tak Leung ,
wrote:
The GNU Make manual is quite useful - and very well-written too. Go and
do
(f),$(LDFLAGS)) $^ -o $@ $(subst
/,$(f),$(FTLIB) $(EFENCE))
tried also this
$(LIBTOOL) --mode=link $(CC) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE))
and this
$(LIBTOOL) --mode=link $(CC) $^ -o $@
Best,Goksugoksu.inOn 12 Jul 2023 5:33 PM +0300, Hin-Tak Leung
, wrote:
On Wednesday, 12 July 2023 at 2
On Wednesday, 12 July 2023 at 21:25:05 GMT+8, Ahmet Göksu
wrote:
> but i am stucked to binary.
$(FTBENCH_BIN): $(OBJ_DIR)/ftbench.$(SO)
$(LIBTOOL) --mode=link $(CC) $(subst /,$(f),$(LDFLAGS)) $^ -o $@ $(subst
/,$(f),$(FTLIB) $(EFENCE))
> i am trying to do it same way in the
On Tuesday, 11 July 2023 at 17:27:02 GMT+8, suzuki toshiya
wrote:
> If somebody wants to try to make autotools to support the building
> of Qt5-based ftinspect, new configure should be added to freetype-demos,
> to check the availability of the extra libraries for ftinspect?
> Or, such check
On Monday, 10 July 2023 at 20:05:58 GMT+8, Hugh McMaster
wrote:
> I've been preparing an update to the Debian package of FreeType and
> realised ftinspect is limited to the meson build system only. Debian,
> by default, has always used autotools.
> There are three build systems currently
On Sunday, 9 July 2023 at 05:17:55 BST, Werner LEMBERG wrote:
> >> Hmm, what exactly do you suggest? `FT_LibraryRec` is an internal
> >> structure not exposed to the public, so it could be changed easily
> >> without any backward compatibility issues.
> >
> > Exactly as what I wrote - if a
Hiya - found a gem: https://github.com/JetBrains/skia-pack/releases
They have m110 - lightly patched (they seems to have 16 patches on top, mostly
making font rasterization settings changeable on-the-fly, I think). Static
libraries plus headers. Seems to be for the purpose of using Skia with
On Saturday, 8 July 2023 at 12:12:17 GMT+8, Werner LEMBERG
wrote:
> > One thing I'd like to suggest, if FreeType 3 is ever happening, is
>.> for the DebugHook to move a bit earlier in the Library struct, and
> > especially before any of the variable/adjustable sized
> > sub-structures.
On Saturday, 8 July 2023 at 12:36:45 GMT+8, Werner LEMBERG
wrote:
> > If the Freetype folks want to port to freetype2-demos, and add the
> > missing renderNode() to support all OT-SVG (I mean Google OT-SVG
> > fonts...) with a different svg rendering engine than rsvg, they can
> >
On Saturday, 8 July 2023 at 19:35:09 GMT+8, Devesh Sharma (M20AIE233)
wrote:
> I reviewed the pygame source and it seems their "freetype" interface is
> missing harfbuzz objects internally, thus, when pygame-freetype passes
> requests to FT, the FT-Face do not have valid hb_* object
I think I have finished this venture for now. Just pushed a
"ot-svg-draw-skia.py" to freetype-py/examples. The top of the file has block of
comments:
Limitation:
Skia-python bundles with Skia m87 (at time of writing this).
Skia m88 is first version where SkSVG* is considered no longer
Argh, sorry, small mistake in the one for freetype2 . Here is the correct
version. I am sure you know why/how the mistake happened :-), if you try to
apply the older one in that 3.
On Friday, 7 July 2023 at 20:34:38 BST, Hin-Tak Leung
wrote:
Hi Werner,
3 patches, one for freetype2
stage of FontVal, with dual freetype and microsoft backends.
Hin-Tak
From 1aecf30b9ff9ef75a7a3cb1957a0c452ac92da74 Mon Sep 17 00:00:00 2001
From: Hin-Tak Leung
Date: Fri, 7 Jul 2023 19:24:48 +0100
Subject: [PATCH] * src/truetype/ttgload.c (TT_Hint_Glyph): More mostly
cosmetic update
Hi,
I set up both freetype2 and ft2-demos for multiple remotes and track both gnu
savannah and gitlab in both. For most parts freetype2 to stay in sync (I think
occasionally one stays behind the other for a day or two), but ft2-demos on
savannah is a couple of months behind gitlab now. Is that
On Thursday, 6 July 2023 at 13:48:52 GMT+8, suzuki toshiya
wrote:
> Are there any stable distributions of the
> prebuilt Skia binary, especially for Linux?
> The skia-python package has its own Skia
> binary (plus libbz2, libfreetype, libfontconfig,
> libpng, and libuuid).
Toshiya Kun,
n.microsoft.com/en-us/typography/opentype/spec/svg#glyph-identifiers
and do not include viewbox or width/height. We assume units to be interpreted
as advised in
https://learn.microsoft.com/en-us/typography/opentype/spec/svg#coordinate-systems-and-glyph-metrics.
Cheers, Rod S.
On Wed, Ju
the 3rd most recent commit on freetype2-demos (as
of now). You didn't look.
On Thursday, 6 July 2023 at 06:43:35 GMT+8, Hin-Tak Leung
wrote:
Actually Adobe/Mozilla OT-SVG fonts do *not* return EM, EM but something like
a few hundred, a few hundred.
The bug fix in freetyp
mos commit log, as I
suggested. It isn't that hard to find.
On Thursday, 6 July 2023 at 06:36:49 GMT+8, Hin-Tak Leung
wrote:
It is the result from the "intrinsic dimensions" routine - (there is a
routine of that sort of name in both rsvg and skia). It returns some larger
nu
commit log, as I
suggested. It isn't that hard to find.
On Thursday, 6 July 2023 at 06:36:49 GMT+8, Hin-Tak Leung
wrote:
It is the result from the "intrinsic dimensions" routine - (there is a
routine of that sort of name in both rsvg and skia). It returns some larger
nu
ear enough?
On Wednesday, 5 July 2023 at 22:00:54 GMT+8, Cosimo Lupo
wrote:
I have no idea what you're talking about. Please, clarify what this difference
is supposed to be, otherwise this is just spreading rumors.
On Wed, Jul 5, 2023 at 2:33 PM Hin-Tak Leung
wrote:
On Wednesday, 5 July 202
On Wednesday, 5 July 2023 at 20:49:42 GMT+8, Hin-Tak Leung
wrote:
> On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo
wrote:
> > Hin-Tak, what do you mean by "Google OT-SVG fonts"? They're only one
> > OT-SVG format.
> Yes and no. I don't hav
On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo
wrote:
> Hin-Tak, what do you mean by "Google OT-SVG fonts"? They're only one OT-SVG
> format.
Yes and no. I don't have that many OT-SVG fonts - 3 from Adobe/Mozilla sources,
and the rest (more than 2 and less than 10) from Google
21:58:10 GMT+8, Hin-Tak Leung
wrote:
On Tuesday, 4 July 2023 at 21:30:56 GMT+8, Dominik Röttsches
wrote:
> ... I don't think it would be the right architectural choice to redundantly
> repeat these concepts inside FreeType itself. Even more so, as fast
> compositing
Not really a python guy myself either, but I know enough python & freetype to
be trusted with commit access to freetype-py (I think I wrote about half of
their bundled examples. A few years ago when I decided I wanted to learn
pycairo, I rewrote all their existing examples from PIL+numpy to
is outside start_glyph_id and end_glyph_id ?
I don't feel strongly either way, but removing 25 lines, and a large "if ...
then ..." makes it easier to read.
Hin-Tak
On Friday, 30 June 2023 at 01:43:51 BST, Hin-Tak Leung
wrote:
...
I think I'll prepare a patch for removing r
1 - 100 of 392 matches
Mail list logo
