> I hope some of these knowledge in comments, probably also alsewhere,
> are copied over before its removal. There are people who want to
> know what Apple/MS does which FreeType does not (yet), even if those
> corners are practically unimportant and/or nobody is doing anything
> about it any ti
> I have found that FT_Get_Char_Index will explicitly return 0 for
> 'missing' characters which is the fix for the issue. I am using
> FT_Load_Char but should that really return a valid construct for an
> "invalid" character?
Why not? Go to a Wikipedia site for a foreign language without proper
> For various fonts it will present the rectangle for a glyph I assume
> it couldn't determine, but there are no errors and even the data is
> still filled in.
If you use OpenType fonts it is common that characters that have no
corresponding glyphs are mapped to glyph index 0, the '.notdef' glyp
> I finally spent enough time on it to have a clue. I wrote up my
> findings in a document:
>
> https://docs.google.com/document/d/1wskYbA-czBt57oH9gEuGf3sWbTx7bfOiEIcDs36-heo
Thanks a lot, this is very good reading.
Werner
>> I've updated my openSUSE box, and I'm now using Qt 5.15.2.
>> However, I still ask you to adjust the meson and cmake build files
>> to request a proper minimum version for Qt (this is not urgent,
>> though).
>
> This has been already done on the `gsoc-2022-chariri-3` branch, see
> commit `6b79
>> Please add code to the meson and cmake build files that checks whether
>> the Qt version you need is installed. If not, make them exit with an
>> error. After you are done you can revert the work-around for older
>> Qt5 versions :-)
>
> OK, I've push the reverted version with check conditio
> As for adaptive layout... I'll set it as a future task with a lower
> priority. I can think of a few locations in the current `ftinspect`
> version where adaptive layout can be used, but honestly, it may cost
> some tome to learn how to implement this in Qt.
OK, no problem.
> BTW, I downloade
Charlie,
I suggest that you have a look at my `ttfautohintGUI` program; it
provides two features that might be interesting for `ftinspect` (what
the program actually does is not of importance).
http://freetype.org/ttfautohint/
* It uses tooltips for documentation.
* It provides two differen
> I've pushed a commit supporting older Qt versions (5.12).
Thanks, but see below.
> But I still recommend upgrading Qt since honestly, I don't know if
> I'll accidentally use more new features. On the other hand, Qt 5
> has ceased to release new "minor" versions, so 5.15 would be the
> last,
[branch gsoc-2022-chariri-2, commit 6a264517f2]
Compilation of 'freetype2-demos' using
```
meson setup meson-build
meson compile -C meson-build
```
fails with
```
../src/ftinspect/widgets/tripletselector.cpp: In member function ‘void
TripletSelector::repopulateFonts()’:
../src/ftinspect/widge
Hello Behdad,
> Any chance the one-line patch below can be applied?
I've applied this as commit b98dd169a1823485e35b3007ce707a6712dcd5251
on May 25th; see
https://lists.nongnu.org/archive/html/freetype-devel/2022-05/msg4.html
Werner
> Two ideas:
And another one :-)
* Assuming that you don't intend to implement a waterfall in vertical
mode, the 'Vertical' checkbox should be greyed out if the
'Waterfall' checkbox is set.
Werner
[please write to freetype-devel by default]
> The CharMap combobox issue is solved, please give it a test. The
> Singular Tab's positioning is fixed as well.
Works now, thanks!
> As for the red square in the waterfall view, I think it is the
> intended behavior because under extreme small fon
>> However, reloading of font should not reset the charmap option
>> either if the charmaps didn't change during the reloading
>> (e.g. when the font isn't changed actually). Line 116, 120~124 and
>> 144~145 are exactly intended to avoid unexpected resetting, but it
>> don't seem to work. I will
> However, what do you prefer for me to prioritize?
>
> * The Hinting Comperator Tab (= `ftdiff`), a new tab parallel to
>singular grid view and continuous view
> * The long, long list of TODO features, and the most wanted
>features seem to be the zoom/scroll/drag operations and
>cli
[commit 94bfed42b7200a9f9ed7437158f5f0332370037c]
>> No, it's not – at least not while using my dark KDE theme. The
>> input field is disabled, yes, but the text colour of 'The quick
>> ...' doesn't change to gray, contrary to other grayed-out items
>> like the 'Next Named Instance' box.
>
> I
>> * What do you think about greying out the text box (holding 'The
>> quick...') if the 'Text Source' field is not 'Text String'?
>
> This is already been done and works at my side. Is it not greying
> out under Linux?
No, it's not – at least not while using my dark KDE theme. The input
field
> 1. Code:
>
> I have pushed the ported font-rs code to the "gsoc-anurag-2022" branch
> (here:
> https://gitlab.freedesktop.org/freetype/freetype/-/tree/gsoc-anurag-2022)
Great, thanks!
> 2. Documentation:
>
> I have started work on improving the existing documentation
> (explanations for func
>> Everything's look OK. Note that the GNU mailing list server has
>> hiccups quite frequently, which means some delay until e-mails are
>> eventually delivered.
>
> The current problem is that, I keep receiving in my Inbox E-Mails
> that I sent. Is this expected behavior?
By default, messages
>> Interesting. Why is that? FreeType only produces 256 levels of
>> opacity; I thought it would be straightforward to map them
>> inversely.
>
> The point was, should I inverse all the colors on the canvas as well
> (grid, outline, points, point numbers)? If not so (only bitmap &
> grid), the
> You mean click onto a single glyph to get info about it?
Yes.
> If so, this would involve mapping from clicked position to glyph
> index - exactly what I didn't consider when implementing "Continuous
> View", which is quite embarrassing.
:-) For me it feels natural to click on a glyph to get
> I'm currently working on non-outline glyphs support. I'll post the
> roadmap later on the GitLab Issue (after taking consideration of
> points mentioned in your feedback).
Thanks.
>> * I use a dark KDE theme; `ftinspect` looks as shown in the
>> attached image. As you can see, the selected
>> Thanks. Now I get the following error:
>
> Now fixed. MSVC is way too lenient...
:-) However, it would be nice if you could ensure that both clang and
gcc builds work fine.
The next bunch of errors is below.
Werner
> Fixed in branch `gsoc-2022-chariri-2`. Using a new branch because I
> rebased to the new `master` which may mess up with the commit hashes
> in the report.
Thanks. Now I get the following error:
FAILED:
src/ftinspect/ftinspect.p/meson-generated_moc_ttsettingscomboboxmodel.cpp.o
ccache c
[274212df5a7812430010e9cc67cbb2a4f5203288, gsoc-2022-chariri]
Hello Charlie,
I've just tried
```
meson setup meson-build
```
and I got
src/ftinspect/meson.build:49:2:
ERROR: File widgets/glyphcontinuous.hpp does not exist.
Please fix.
Werner
> [...] I fell into this trap myself, and while it seems dumb,
> searching online found a few unresolved threads from other poor
> souls who were having this exact issue in the past. [...]
Thanks for the patch; I've added it to the repository (with very minor
amendments).
Werner
> If I set up a parallel personal branch (gsoc-2022-chariri)
> cherry-picking my contributions, while new commits are still being
> merged, would it work? The parallel branch would serve the purpose
> of proof-of-contribution and it will be a logically organized single
> line.
This should work.
>> If you want to submit general changes to FreeType please submit
>> MRs. However, for your ftinspect GSoC stuff you should push to a
>> personal branch (or even branches, if necessary) of the upstream
>> repositories *without* MRs. In your personal branch(es) you can go
>> wild – no need for f
Hello Charlie,
> I'm going to make my first commit for the GSoC.
Great!
> It's a minor change - CMakeLists.txt for ftinspect. I've pushed the
> commit to my forked repo on the GitLab. However, where should I
> create MR to? Should I create a MR from my master branch to the
> master branch of
Hello Tayyab,
> I have been following for quite some time but David is not
> responding. It feels to me like he is not interested in this
> proposal.
David, while still being the spiritus rector behind the scenes, is not
a regular contributor to FreeType any more due to time constraints; if
su
>> [Charlie, please subscribe to the 'freetype-devel' mailing list.]
>
> But I can still manage my subscription status on
> https://lists.nongnu.org/ . Is my subscription accidentally dropped?
Ah, your status was 'moderated' for some unknown reason. Now fixed.
>> I don't know. What would be
[Charlie, please subscribe to the 'freetype-devel' mailing list.]
> Therefore, I'm planning to bring forward the next phase (Part 2 in
> the timeline), which is refactoring the current base.
OK.
> * You're creating a lot of "extra" widgets by inheriting the
>original widgets in Qt. This cr
> My problem is that I don't understand:
> https://github.com/freetype/freetype/blob/c26f0d0d7e1b24863193ab2808f67798456dfc9c/src/sfnt/sfdriver.c#L1054-L1062
>
> In particular, what is
>
>- TT_CONFIG_OPTION_GX_VAR_SUPPORT:
>
> https://github.com/freetype/freetype/blob/c26f0d0d7e1b248631
>> freetype-2.12.1/src/smooth/ftgrays.c: In function 'gray_convert_glyph':
>> freetype-2.12.1/src/smooth/ftgrays.c:1968:20: warning: storing the address
>> of local variable 'buffer' in 'worker_56(D)->ycells' [-Wdangling-pointer=]
>> 1968 | ras.ycells = (PCell*)buffer;
>> |
Hello Hin-Tak,
> Am trying to ugrade my system to fedora 36 (with my
> FontVal-customized backend...) and saw quite a large number of new
> compiler warnings... so I checked my past build logs, and see that a
> few of them were new to 2.11.1 (2.11.0 was clean), and a few more
> added in 2.12.x
> I met an issue in function t42_parse_sfnts, the statement in
> line 692 seem incorrect as below: [...]
What exactly do you mean with 'meeting an issue'? Do you have a font
that produces strange output because of this line?
> size = (FT_ULong)( limit - parser->root.cursor );
>
>
Hello Behdad,
> [...] I also found that it tries to apply variations
> unconditionally. The following patch fixes that to only try
> applying variations if the font has blends set.
Applied, thanks.
> I truly cannot explain the order-of-magnitude difference so far.
I hope that you will be ab
I'm happy to announce that we got two slots for students this year (we
asked for three, but...):
* Anurag Thakur's project is
Integrate FreeType with alternative rendering engines
* Charlie Jiang will work on
Improve FreeType demo programs
I'm very excited about the collaboration, wh
FreeType 2.12.1 has been released.
It is available from
https://savannah.nongnu.org/download/freetype/
or
https://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
En
Hello George,
> I am an individual who would be interested in the project "Integrate
> FreeType with alternative rendering engines" listed on FreeType's
> GSoC page.
Great to hear!
> There were multiple things in the blog post that the entry linked to
> that I found interesting/had questions a
Hello Anurag,
> I am interested in contributing to the project “Integrate FreeType
> with alternative rendering engines” as part of GSOC 2022 and have
> been learning about it for some time.
Great!
> Reading through the mailing list discussions and building on the
> work of other contributors,
> [...] when I looked into the GSoC 2019 project completed by another
> student
> (https://gist.github.com/GeVic/75889ae2728f6dee0a490166ff8e2271), I
> noticed:
>
> 1. He already finished integrating several other tools including
>ftdump, ftstring, ftview and ftlint. Therefore I wonder how
>
>> I'm not familiar with text rendering and font processing, therefore
>> I'm refering to FreeType documentations and other online materials.
>> Are those skills considered as prerequisites before I submit my
>> proposal?
>
> Yes. These are FreeType demos. We’re not really interested in
> Window
>> Good question, I don't know. Revising FreeType's build system is
>> another GSoC project:-)
>
> I saw that project. It will be optimal if he is willing to help us
> out. Unfortunately both Visual Studio and CLion don't play very
> well with MesonBuild. I'm used to use CMake to develop Qt
Hello Charlie,
> I'm interested in contributing to the project "*Improve FreeType
> demo programs*".
Very nice, and welcome!
> 1. My main workspace is running Windows 10 and Visual Studio 2019.
>Therefore the binaries are built on that, using mesonbuild.
>However, I'm facing great diff
> On 3/31/22 11:15, Werner LEMBERG wrote:
>
>> - The internal 'zlib' code has been updated to be in sync with the
>> current 'zlib' version (1.2.11).
>
> zlib 1.2.12 was released earlier this week
Sigh. As mentioned on the 'freetype' lis
FreeType 2.12.0 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
Enjo
> As Werner told, I was able to build freetype on MacOS, GNU/Linux,
> Windows. What is the next step, I need to do?
Try to *understand* FreeType's Makefile structure and get acquainted
to it. While the GSoC project is not very hard by itself, it is
probably hard to explain to non-FreeType-deve
Hello Afrid,
> [...] I would like to contribute to the project *Update FreeType's
> build System.* I am aware of CMake, Meson build systems. As it was
> mentioned that particularly for this project, needs intensive
> contact with mailing list, I would like to know more about the idea
> and also
> A feedback?
Sorry, I haven't had time yet to look at your code. Will do so in the
next few days.
Werner
>> Too bad that Microsoft's PDF driver doesn't strip off tables for
>>embedded bitmaps. Maybe it makes even sense to write a bug report
>>to MS: There shouldn't be any bitmap strikes in fonts part of a PDF.
>
> I can imagine a PDF where someone is using these bitmas in the right
> size, but th
> I expressed myself wrong. I know about bitmaps, but in this file our
> software only needs to render (or get width - depend of scenario) a
> space.
OK, you have convinced me.
> Original producer: /Producer (Microsoft: Print To PDF)
Hmm. Too bad that Microsoft's PDF driver doesn't strip off
> I am attaching PDF with TrueType font, this font only has a space.
> The tt_check_single_notdef function ignores spaces, which removes
> the FT_FACE_FLAG_SCALABLE flag. In the next steps we want to scale
> this font/empty glyph, but unfortunately we get the error that the
> font cannot be scal
>> Adding support for TIFF and JPEG is not much code; it would be
>> configurable in the same way as PNG.
>
> You probably mean libjpeg-turbo and libtiff as external dependencies.
Yes.
> This is a GNU approach.
Yes, and it is a good, modular one.
> Other systems might have an abstraction lay
>> As Werner is working on improving the SBIX table support
>> (https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/139),
>> a topic of compressed images came up. Right now, FreeType depends
>> on libpng to uncompress PNG, but SBIX can have TIFF and JPEG. So I
>> was wondering if
>> > So I'm wondering if they may have opsz in integers.
>>
>> AFAIK, no.
>
> Aha. but he said that removing those lines fixes his issue. I can't
> think of any other reasons so far. but I may be missing something
> else.
Interesting. Would it be possible to get this font privately for
further
> The fields minimum, def, and maximum are 16.16 fractional values for
> TrueType GX and OpenType variation fonts. For Adobe MM fonts, the
> values are integers.
>
> Does this mean those variables are represented as 16.16 fractional
> numbers or integers in some cases?
Correct.
> If so, how ca
> So basically, we need to organize the fields in such a way that they
> reflect their traits. It can be having a prefix describing the
> trait or organizing like the following:
>
> typedef struct ABC {
> struct {
> /* Mutable Properties. */
> } mutable;
>
> struct {
> /* Lazy Pr
Hello Daniel,
>> I'm from the X.org board of directors, and we're going through all
>> the domains that freedesktop.org infrastructure is hosting. One of
>> them is freetype.org, and we got a few questions:
>>
>> - who's the current contact and holder? In case we need that for
>> moving thi
> This proposal aims to take the best of both approaches by
> introducing a new function, `FT_Clone_Face`. [...]
Excellent summary, much appreciated, thanks!
What we are mainly interested in is whether other users would going to
use the proposed API as advertised. If yes, please say so. Othe
> Using `ttx`, I was able to modify the font a bit to produce another
> font that contains 'COLR' v0 and 'SVG' tables – and indeed, it
> doesn't work as expected – (a) SVG should have higher precendence,
> which is not the case, and (b) the `COLR` glyph is shown even if
> FT_LOAD_COLOR is not acti
>> Process terminating with default action of signal 11 (SIGSEGV): dumping core
>> General Protection Fault
>>at 0x429C9D: FT_Done_Face (ftobjs.c:2912)
>>by 0x483061: ftc_face_node_done (ftcmanag.c:272)
>>by 0x482F69: FTC_MruList_New (ftcmru.c:281)
>
> This should be fixed now. Plea
> It is strange that other demos are happy. I am a bit blinded because
> I do not run ftinspect.
Thanks for your fix. However, it doesn't seem to be sufficient (at
least on my openSUSE box); `ftinspect` still crashes. Here is a new
valgrind report.
Werner
==
Hello Tom,
> So I think the thrust of this issue is when people want to build
> outside of cmake, and the corresponding freetype.pc file can't find
> bzip2.pc.
Toshiya-san has fixed this meanwhile in the git repository. Please
check.
> SOme distros have made .pc files for bzip2 via patches to
Alexei,
`qtinspect` immediately crashes. However, if run with `valgrind`, it
does not. I think this is an indication that some of your changes to
not initialize arrays in `src/cache` need to be fixed. Please check.
Below is my valgrind output from current git.
Werner
While walking over open FreeType issues I wondered whether there is a
cmake expert who could fix issue #897, a problem with generating a
potentially invalid `.pc` file because 'bzip2' doesn't come with a
`.pc` file of its own by default:
https://gitlab.freedesktop.org/freetype/freetype/-/issue
> off-topic, but sbix only works reliably on mac -->
> https://github.com/harfbuzz/harfbuzz/issues/2679#issuecomment-1021419864
Ah, I completely forgot this one, thanks for the reminder.
Werner
> please find attached a test COLRv1 + SVG font, containing only one
> color glyph ✍ "WRITING HAND" (U+270D) emoji.
Thanks a lot, this is exactly what I need for testing. The font works
fine with FreeType, it seems (it only shows the SVG output since it
can't render COLR v1 natively).
Using `tt
> In the release announcement, it would be great to improve trust on
> the release material by publishing
>
> - the PGP public key used to sign the archives
> - the digests of the archives
Thanks for the idea. I'll do it the next time.
Werner
> Do you still need such a test font with SVG and COLR in it? I guess,
> we can make one if it's needed.
This would be still very helpful, yes. I think it would be helpful
for for fuzzing, too. A single glyph (besides '.notdef) would be
enough.
>> The question doesn't arise for serious `COLR`
Hello Dominik and Ben,
do you have a (small) test font that contains both a valid SVG and a
COLR table for the same glyph(s)? Otherwise, could you assemble such
a thing? Ideally, the font should come in two flavours (TTF and OTF)
to cover all combinations.
While working on the new SVG support
> While working on the new SVG support in FreeType three questions
> came to my mind.
After some working on the documentation I believe I can now answer two
questions by myself :-) The thing is that for serious handling of
`COLR` you must not use the `FT_LOAD_COLOR` flag at all (which only
provid
Hello Shashank,
> I am Shashank, currently pursuing my masters degree in AI from
> Indian Institute of Technology, Hyderabad. I have some experience
> in C and would love to contribute to your project. I am new to open
> source contributions so I kindly request someone to guide me.
My crysta
>> OK. If necessary, please modify the code! I think the code spoty
>> in question is the right place to avoid auto-hinting for OT-SVG
>> glyphs.
>
> Umm, if I change `cff_slot_load` and `TT_Load_Glyph` so that they
> return errors if an SVG table is found but a glyph isn't, then how
> am I go
>> If I understand this correctly it means that a test for the SVG
>> table is not sufficient. Instead, you have to actually do the call
>> to `driver->clazz->load_glyph`, and if this fails, FreeType should
>> try to load a bitmap font, and if this fails, it should proceed
>> with auto-hinting t
>> > I'm not sure how to add a check that can prevent hinting to be
>> > run for OT-SVG glyphs. Whether or not a glyph index has a
>> > corresponding SVG glyph in the table is determined later on
>> > inside cff_slot_load or TT_Load_Glyph. Any ideas on how to
>> > prevent autohinting from being r
> The reason why the autohinting code seems to get triggered for that
> font is because `ttface->num_locations` is 1
The actual value is 321, the number of normal (i.e., non-SVG) glyphs
in the TrueType font.
> for this font while it's 0 for all other fonts that I had in my test
> collection.
In
> Seems this is a random failure of docker service on the
> gitlab-runner host. For a while it was in a faulted state. I've
> manually restarted the pipeline in my fork, and now it runs fine:
> https://gitlab.freedesktop.org/azamat.hackimov/freetype/-/jobs/17517842.
> You can manually restart fa
> As I suspected, Windows image lacks the recent Root CA from Let's
> Encrypt (famous ISRG Root X1 / IdenTrust DST Root CA X3 issue).
> Normally Windows should automagically update Root CAs during
> invoking the Schanel crypto library, but Python uses OpenSSL, so
> magic does not happen.
Ah, tha
Hello Sneha,
> Currently, the UI of FreeTypes is not very appealing and I feel like it
> needs a change in the website look.
Please define 'not very appealing'. What are the problems, what
should be improved, etc., etc.
What's currently completely missing is support for handheld devices –
do
>> > do you know if Mark would accept to add meson as build system ?
>>
>> Who is Mark?
>
> Mark Adler.
Ah, ok.
> If meson is added in zlib, that would simplify the process
Certainly. I guess submitting a push request makes sense – Mark is
still actively working on zlib.
werner
Hello Vincent,
> do you know if Mark would accept to add meson as build system ?
Who is Mark? And for the Windows CI build we use meson...
Werner
I frequently (but not always) get the following error in Windows
builds of FreeType, as shown in
https://gitlab.freedesktop.org/freetype/freetype/-/jobs/17462980
The problematic part is the following:
```
Downloading zlib patch from
https://wrapdb.mesonbuild.com/v2/zlib_1.2.11-5/get_patch
I've just seen this nice interface:
https://ci.chromium.org/ui/p/chromium/builders/try/linux-blink-rel/66072/overview
Click on the arrow left of the exclamation mark in the red circle.
Very impressive.
Werner
Hello Moazin,
just now I've pushed new branches to the FreeType and FreeType Demo
repositories with my changes.
https://gitlab.freedesktop.org/freetype/freetype/-/tree/wl/freetype-ot-svg-from-scratch-new
https://gitlab.freedesktop.org/freetype/freetype-demos/-/tree/wl/freetype-demos-supp
Hello Srijan,
> Hence, I'd love to connect and contribute to the projects of
> FreeType right away!
Welcome – I guess you are here due to GSoC, right? Then the first
step is to follow the instructions giving on
https://freetype.org/gsoc.html
Werner
> The link of FreeType 2.11.1 on https://freetype.org/ was wrong,
> please have a look.
Thanks, fixed. It might take a while until this gets propagated from
the git repository to 'https://freetype.org'. To check the changes
right now you might visit
https://freetype.gitlab.io/freetype-web/
>> Do you know how to make INSTCTRL no-op anywhere except CVT?
>> Otherwise it is rather strange to reconsider each time TT_RunIns
>> runs under v40.
>
> I think it shouldn't be a no-op but rather cause an error, no?
D'oh. The current OpenType specification is buggy :-)
Werner
Hello Alexei,
> To make `hdmx` easily accessible, I propose the following.
>
> 1) Use internal FT_LOAD_ADVANCE_ONLY in truetype to quickly exit if
> `hdmx` is deemed usable and size matches.
> 2) "quickly" means from tt_loader_init. We will relocate the bulk of
> the `hdmx` code there from comp
FreeType 2.11.1 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
Enjo
> I found a build warning in the latest FreeType source code and
> likely this only happens with the bionic libc used in Android.
>
> Here is the proposed patch for fixing warnings. [...]
Patch applied, thanks!
Werner
[You have again missed to use 'reply to all'. In the future I won't
answer to e-mails from this thread sent to me privately.]
> Not a request: to fix freetype, all of the modules would need a
> static constant returned on a `module.get_formats()` call but
> freetype would also need a function
> [...] What I've done is that I get the values from the tables at the
> CFF/TTF layer while loading the document and leave the rest of the
> calculation of the bearings (and also the vertical advance height
> calculation if it wasn't found in the table) to be done by the
> preset hook on the ren
> https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html?m=1
>
> Discuss. Could be a good thing for the project IMO.
What exactly should be discussed?
Werner
>> Correct. `FT_LOAD_NO_SCALE` is not intended to be directly used
>> for rendering, since rendering always needs a transformation to the
>> output device space.
>
> So when it comes to the TTF/CFF outlines, what would the user do to
> scale the glyph to the device space if it was loaded initiall
Hello Moazin,
> 1. `FT_LOAD_NO_SCALE`: For CFF/TTF outlines, this flag loads the
>outlines, but in font units, if you directly render it by
>`FT_Render_Glyph`, the render functions just assume that the
>points are in 26.6 point format, which isn't the case and thus
>you get a ve
> I am disabling email protection, its just a switch flip anyways. If
> others disagree I will turn it back on.
Thanks.
> Also, @Werner can you confirm if you have full-access to the
> cloudflare account?
I think I have, thanks too.
Werner
> While looking at the site for issues to fix, i noticed Cloudflare
> email "protection" is on, meaning it rewrites emails and basically
> removes them from a persons view if javascript is disabled on a
> browser - not good. [...]
Ah, yes, I agree.
> Is there any way to disable that? There sh
> I have been thinking about this for a while, but it does make some
> sense. Anurag’s post reminds me and leads me to another question:
> why don’t we move the release process to Gitlab?
Basically, I don't object, especially to do the mechanical things.
However, ...
> Not only will it make st
> I would like to request the maintainers to clear any config left on
> the previous hosting platform/any shell scripts used to manage the
> website, since it's all managed by gitlab pages now.
I have just disabled the cron script (to be exececuted every ten
minutes) on my freedesktop.org accoun
201 - 300 of 4490 matches
Mail list logo
