seems well-suited for
future-proofing our project.
Best,
Goksu
goksu.in
On May 2, 2024 at 11:17 +0300, suzuki toshiya ,
wrote:
Dear Ahmet,
The development of native GUI application for macOS have 3 choices:
1) Use C and Carbon framework (now obsoleted)
2) Objective-C and Cocoa framework
3) Swift
assessment and prefer to use Swift. It seems well-suited for
future-proofing our project.
Best,
Goksu
goksu.in
On May 2, 2024 at 11:17 +0300, suzuki toshiya ,
wrote:
Dear Ahmet,
The development of native GUI application for macOS have 3 choices:
1) Use C and Carbon framework (now obsoleted)
2
On May 2, 2024 at 03:56 +0300, suzuki toshiya ,
wrote:
Dear Ahmet,
Congratulation! I'm glad to find another macOS contributor in
FreeType.
Please could you provide the updated estimation of the schedule,
with new goal (native graphics backend for macOS, without X11)?
The filed schedule dated on April
Dear Ahmet,
Congratulation! I'm glad to find another macOS contributor in
FreeType.
Please could you provide the updated estimation of the schedule,
with new goal (native graphics backend for macOS, without X11)?
The filed schedule dated on April 2nd was written for older goal
(an improvement
Dear Werner,
I'm quite sorry for bothering you - I've drafted a quick update
of gsoc.html to notice FreeType project is absent in GSoC 2024.
https://gitlab.freedesktop.org/freetype/freetype-web/-/merge_requests/14
Please could you check?
Regards,
mpsuzuki
On 2024/02/22 15:37, suzuki toshiya
Dear Akhilesh,
Please find the discussion after Nitish's similar post:
https://lists.nongnu.org/archive/html/freetype-devel/2024-02/msg0.html
Regards,
mpsuzuki
On 2024/02/23 3:00, Akhilesh yadav wrote:
Hello,
I hope this message finds you well. I noticed that Free Type is participating
organisation, with a link to the 2023
projects webpage. Should this perhaps be changed?
Regards,
Brad
On 22/2/24 17:10, suzuki toshiya wrote:
Dear Nitish,
I'm sorry, Werner and me are hard to participate to GSoC 2024.
I've not heard from Alexei whether he can or he will, but I
guess the FreeType
Dear Nitish,
I'm sorry, Werner and me are hard to participate to GSoC 2024.
I've not heard from Alexei whether he can or he will, but I
guess the FreeType project would be unable to have a project
in GSoC 2024.
--
I don't know any existing modern communication channels for
young people, like
Insufficient information.
* no information of your platform. it looks like as if it were Ubuntu, but no
detailed version.
* no information on compiler, libc, etc etc.
* no information what you're compiling. it looks like as if you were going to
compile splashutils (I don't know what it is),
4:20, suzuki toshiya wrote:
I would try to let AX_HAVE_QT() macro to find appropriate set:
https://www.gnu.org/software/autoconf-archive/ax_have_qt.html<https://www.gnu.org/software/autoconf-archive/ax_have_qt.html>
In the case of Debian (and Ubuntu), qtchooser might be the unified
interface
.
Regards,
mpsuzuki
On 2023/07/13 16:24, suzuki toshiya wrote:
Thanks, using same macro with ttfautohint would be easier for future
developers, I would use it.
Regards,
mpsuzuki
On 2023/07/13 15:28, Werner LEMBERG wrote:
I would try to let AX_HAVE_QT() macro to find appropriate set:
https://w
Thanks, using same macro with ttfautohint would be easier for future
developers, I would use it.
Regards,
mpsuzuki
On 2023/07/13 15:28, Werner LEMBERG wrote:
I would try to let AX_HAVE_QT() macro to find appropriate set:
https://www.gnu.org/software/autoconf-archive/ax_have_qt.html
An
2023 at 04:04:54 BST, suzuki toshiya
wrote:
Good, I was just trying to update configure.raw to add 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
Good, I was just trying to update configure.raw to add 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
Dear Hin-Tak,
As one of the contributors of the FreeType and a person
who had once struggled with Skia, I'm very happy to hear
your progress report about the Skia-based backend of OT-SVG
for FreeType.
But I'm slightly questionable whether the subscribers of
MPEG-OTSPEC are enjoying samely.
Hi,
In the conventional workflow, the source tree of the FreeType2 library
has "./configure", but freetype-demos does not have. Just starting
"make" with existing Makefile under "freetype-demos" carries the
configured values from freetype directory. The meson for the ftinspect
wants to confirm
Oops! I'm quite sorry, I will take a look.
Regards,
mpsuzuki
On 2023/07/08 14:51, Werner LEMBERG wrote:
Toshiya-san,
Hin-Tak reports the following:
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
Hi Hin-Tak,
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).
Once, I was involved in developing SVG Native
Viewer, which has the backend to Skia.
Just a few minutes ago, I could not download anything by Firefox either
(fallbacked to bigsearcher.com page), but now I can download. There might be
some networking issue. Could you please retry?
Regards,
mpsuzuki
On 2023/06/22 16:11, Sergey via FreeType users wrote:
Hi!
This page
Hi,
- Don't call `gcc` directly! You should rather use `$(CC)` (or
probably `$(CCexe)`, I'm not sure right now).
In my understanding, $(CC) can be a cross compiler (e.g. building
Win32 binary on Linux platform), but $(CCexe) is a native compiler
to build "apinames".
The compiler to
Sorry, it's too late. Please consider GSoC 2024 and check the schedule.
Regards,
mpsuzuki
BTW, IIT Advanced (The
https://en.wikipedia.org/wiki/Joint_Entrance_Examination_%E2%80%93_Advanced?)
rank may be difficult for most non-Indian developers to assess whether it is
high or low. Developing
uki
P.S.
Personally I'm interested in the enhancement of t1cid to
accept the "incrementally-defined" CIDFontType0 font file,
which uses /GlyphDirectory and includes no binary section.
But I have to start from making a font data which GS and
genuine PostScript interpreter can accept
Dear Werner,
Ah, I need more time to propose deprecating or removing
the incremental loading feature in the t1cid driver.
But there is room for improvement in this feature's
documentation (or a tutorial). Just I've written to
the ghostscript-devel mailing list and asked whether
GhostScript has
loading feature of t1cid is helpful to render the PostScript
document using the incremental definition of the CIDFontType 0 dictionary.
If anybody knows a practical use case, please let me know.
Regards,
mpsuzuki
On 2023/04/27 21:40, suzuki toshiya wrote:
Hi,
Recently, Alex gave me an idea to
Hi,
Recently, Alex gave me an idea to improve FT_Get_CID_From_Glyph_Index() API for
CID-keyed font Type 0 (FontType 9, the most traditional CID-keyed font using
PostScript Type1 CharStrings) by adding a fallback to CID=0 for the cases that
the requested GID points to a broken entry providing
old values with new freetype or some
other suggestion.
Thanks,
Ankit Jain
-Original Message-
From: suzuki toshiya
Sent: Wednesday, April 26, 2023 7:51 PM
To: freetype@nongnu.org
Cc: Jain, Ankit
Subject: Re: Need Help!!Getting Different glyph_locations in freetype 2.0.9 and
2.10.0
The difference might be FT_Long* versus FT_Byte*.
Regards,
mpsuzuki
On 2023/04/26 22:15, Jain, Ankit wrote:
Hi,
I need help in knowing how we are getting different glyph_locations in freetype
version 2.0.9 and 2.10.0.
I understand both are very different version initially we were using 2.0.9
stream offsets
could not load a glyph for CID=3
cid_load_glyph: invalid glyph stream offsets
issue.
Regards,
mpsuzuki
On 2023/04/21 16:42, suzuki toshiya wrote:
Dear Alexei,
Excuse me; please let me ask your background to scan
all CIDs. Is it a confirmation of the existence of
the glyph
In my opinion, only validated CIDs are interesting. Therefore,
FT_Get_CID_From_Glyph_Index is confusing to me. It looks like it is useful for
CFF only but not for Type 1. It looks like the we need different approaches:
FT_Load for t1cid and FT_Get_CID for CFF.
OK. Yet I've not checked what
2023 at 12:47 AM suzuki toshiya
wrote:
Dear Alexei, Werner,
Here is reworked version, which assumes
"no zig-zag mapping is found by FT_Get_CID_From_Glyph_Index()".
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/commit/453de7aa3f9ccd54824ab3468c5a3b91507a86a9
(
http
os-mps-wip/-/commits/mr-ftdump-print-cid-ros-assume-order
)
Regards,
mpsuzuki
On 2023/04/20 12:46, suzuki toshiya wrote:
Dear Alexei,
Umm, TN#5092 is a document in the world of pure CID-keyed font,
so it does not care about the mapping between the CID and
TrueType (or CFF) GID, so
Dear Alexei,
Umm, TN#5092 is a document in the world of pure CID-keyed font,
so it does not care about the mapping between the CID and
TrueType (or CFF) GID, so I'm unsure if it is a solid footstone
to exclude the unordered CIDs.
For example, "GB1 represents the first version of the ordering
Dear Alex,
I agree that bitshift is too complicated. If the glyphs are sorted by
CID, you might not need the temporary storage if you keep track of the
previous CID and some format string tricks. I can work on that later
by adopting the lines 676-707 (if the CIDs are sorted indeed).
Indeed.
Dear Werner, Alex,
Thank you for positive comment. I fixed my broken comment by Werner's advice.
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...2bf378a1
BTW, if the 64kByte array to check CID availability can be
reduced to a 64kBit (= 8kByte for most
Here is the 3rd revision.
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...228f50f0
The execution "ftdump -c" for OpenType/CFF fonts with "holes" in
the implemented CIDs, like Hiragino fonts on macOS, generates
the output ending with:
cally).
I tested it with both of raw CID-keyed font (like WadaGo-Bold), and
OpenType/CFF.
Regards,
mpsuzuki
On 2023/04/16 22:11, suzuki toshiya wrote:
Thank you very much for positive comment - Indeed, yet I've not considered and
tested with real CID fonts! I should rework.
Showing a string
Thank you very much for positive comment - Indeed, yet I've not considered and
tested with real CID fonts! I should rework.
Showing a string type value after the numerical value might be strange.
In conventional PostScript CID fonts, ROS is usually identified as a string like Adobe-Japan1-4,
Hi all,
FreeType has an API to retrieve the CID registry, ordering, and supplement;
FT_Get_CID_Registry_Ordering_Supplement(), but ftdump does not use it.
In traditional usecases of CIDKeyedFont 0 and 2, we don't have to use
FreeType to obtain ROS information, because they are often written in
Hi,
In the recent Xcode (a genuine SDK for macOS) by Apple, the command "gcc" is an
alias of clang, there is no real GNU C compiler.
Although I've not checked whether its behaviour can be changed by its invocation name (the case which clang is invoked
as "clang", and the case which clang is
Hi,
Please try the released tarball of 2.6.5, instead of the git snapshot. If you
really really want to try the git snapshot for 2.6.5, you should gather the
versions when 2.6.5 was developed. According to
https://gitlab.freedesktop.org/freetype/freetype/-/blob/VER-2-6-5/autogen.sh ,
://www.rasterman.com/files/wp2.avi
but i don't think you will switch to the EFL :-)
regards
Vincent Torri
On Thu, Jul 28, 2022 at 8:02 AM suzuki toshiya
wrote:
Dear Werner, Charlie,
In the case of Ubuntu, the versions of Qt are following.
18.04LTS (until April 2023): 5.9.5
20.04LTS (until
Dear Werner, Charlie,
In the case of Ubuntu, the versions of Qt are following.
18.04LTS (until April 2023): 5.9.5
20.04LTS (until April 2025): 5.12.8
21.10: 5.12.2
22.04LTS (until April 2027): 5.15.3
Kinetic: 5.15.4
I think supporting Qt 5.12 is helpful for lazy late adapters like me :-),
but
Dear Liu Kunpeng,
Yes, at least I received your post through the list, I hope many people
received - but yet I don't have sufficient time to review the code, I apologize
sincerely.
Please could you allow me to ask a question before reviewing the code...?
FreeType2 has a functions like
Hi,
The Skin Tone modifier is working as a combining character,
so it must be handled at the level higher than FreeType.
FreeType does not return the image of "À" (U+00C0) from
the sequence "A" + "`" (U+0041, U+0300) , even if the
specified font has a precomposed glyph which is accessible
from
Dear tcll5...@tutanota.com
Basically I support Werner's opinion.
I'm afraid that your plan might something like:
step 1) getting the human-readable "supported font file format" list from
FreeType, instead of the module names in FreeType.
step 2) check whether the list can cover the file which
+1
Also I hope if Balakrishna-san changes the subject to the current issue.
I think current issue is unrelated with the crap in the TTF names.
Regards,
mpsuzuki
On 2021/10/25 16:44, Werner LEMBERG wrote:
We want to create fonts using pixelsize of the order of 14, which
would eventually be
Hi,
According to
ld: warning: ignoring file /usr/local/Cellar/libpng/1.6.37/lib/libpng16.dylib,
building for macOS-arm64 but attempting to link with file built for macOS-x86_64
The dylib in your celler seems to be built for x86_64, however I'm not sure
because I'm unfamiliar with the error
Please try "ftdump -n" to dump all entries in the name table.
Regards,
mpsuzuki
On 2021/09/01 21:09, virtual_wor...@gmx.de wrote:
Hi,
I have a (originally Chinese) TrueType font here which works well in my
freetype2-based application except one thing: I do not get the original,
Chinese name
Hi all,
Sorry for posting about my homework in 6 months ago.
During the fix for the issue 1078
https://gitlab.freedesktop.org/freetype/freetype/-/issues/1087
, I added a tweak skipping the randomization "tag"
of the family names of the fonts embedded in PDF.
They might even be broken but have zero maintenance cost.
+1
On 2021/08/06 0:00, Alexei Podtelezhnikov wrote:
Also, makefiles for DOS are present too
FreeDOS 1.3 RC4 released 3 May 2021
- Amiga: Discontinued in 1996
- Atari: Discontinued in 1992, latest console Atari VCS runs on a Linux
Dear Sarthak,
Is it possible for you to write a small external program producing a difference
from 2 images (rendered by FreeType)?
Regards,
mpsuzuki
On 2021/05/23 19:44, Sarthak Bhardwaj wrote:
Hello,
I was a little confused about, What file should I modify in the FreeType source
to
Oh, sorry for my poor wording.
What exactly do you mean with a 'more general framework'?
If my memory is correct, HarfBuzz was started as the one of the infrastructure
for the Pango.
When it was started, there were other non-HarfBuzz OpenType drivers, like Qt,
like ICU, etc. Maybe there
Dear Werner, Lawrence,
As a quick fix, I want to propose the additional item to FAQ.
Q: How to implement Asian vertical writing text by FreeType 2? I heard it had
been available before OpenType.
A: FreeType 2 does not support it. Before OpenType, the text renderers did many
non-systematic
The words are a bit harsh but I have no objection ;-)
On 2021/05/16 18:03, Lawrence D'Oliveiro wrote:
On Sun, 16 May 2021 17:31:17 +0900, suzuki toshiya wrote:
Yet I don't have a good answer to a person saying "I don't care
the right-to-left scripts, or the complex glyph shaping like va
oordination system (I mistook the
origin of the coordination system as the lower left point of the glyph
bounding box). Yes, the half of AdvanceWidth is OK.
Regards,
mpsuzuki
On 2021/05/16 12:01, suzuki toshiya wrote:
Hi all,
I got a response from the original questioner, and forward it to the
list (with per
Dear Werner, Lawrence,
Sorry, please let me change the Subject of the discussion...
I feel a sympathy with the impression "often we receive the questions
looking for the complex text layout features in FreeType itself",
and the impression might make some experts tired.
The expected way would
: Sat, 15 May 2021 19:51:07 +
From: Harold Hallikainen
To: suzuki toshiya
Sorry about the repeat! I hit send instead of save draft. Here's more of
the message.
Thank you for the excellent information! I am working with the Society of
Motion Picture and Television Engineers to try to improve
Dear Mr. Hallikainen,
On 2021/05/15 4:47, Harold Hallikainen wrote:
I am trying to understand how font files are used when writing vertically
(such as for Japanese text). I'm pretty new to this, so please excuse my
ignorance.
Thanks, but I suggest, please do not try to understand it
Dear Sarthak,
It seems that you think as - the FreeType is a huge software which the compiler
generates so many warnings, like uninitialized variable, passing the
inappropriate typed values, etc etc, and some of them are related with the
rasterization results. It is not. Even if you try to
Dear Anshuman,
Please check the official site as the first step to obtain the developers info:
https://www.freetype.org/developer.html
Regards,
mpsuzuki
On 2021/03/16 4:38, Anshuman Singh wrote:
Greetings,
I am an Engineering student from India and my coding interests lie primarily in
C.
I
Dear Utkarsh,
(sorry for that I slipped to follow FIFO rule)
Please check the official site as the first step to obtain the developers info:
https://www.freetype.org/developer.html
Regards,
mpsuzuki
On 2021/03/16 1:16, UTKARSH CHAUHAN wrote:
Hello,
I am Utkarsh Chauhan doing btech in
is PDLCJH+OCR-A font.
This is incremental font build of OCR-A font. Free type flags it as tricky.
BR,
Justyna
-Original Message-
From: suzuki toshiya
Sent: Friday, February 12, 2021 2:06 AM
To: Werner LEMBERG ; Justyna Wawrzynska
; Roy Tam
Cc: freetype-devel@nongnu.org
Subject: [EXTERNAL] Re
Dear Werner, Justyna and Roy,
"DLC" was introduced by the request from Mr. Roy Tam,
https://gitlab.freedesktop.org/freetype/freetype/-/commit/0ed9fef032641c30d0398d98a01b69eca1c15224
The assumed font file*s* were dlctt-m7.ttf and dftt-f5.ttf. Revisiting the changeset, using
"DLC" prefix in
Dear Rob,
Excuse me, could you provide more info about how a Blink
engine sets the rendering options for FreeType when it
finds geometricPrecision CSS property?
The majority of this mailing list may know nothing about
the internal behaviour of HTML rendering engines, and
might be unable to hard
Dear Werner, Anuj,
Werner LEMBERG wrote:
>> Also, I can see **Message not available* *after my emails in the
>> freetype-devel archives.
>
> AFAICS, this is a pure accident. The (automatically) deleted messages
> are spam, I reckon.
>
>> Am I doing something wrong?
>
> No, I don't think so.
Dear Werner,
Werner LEMBERG wrote:
>> Oh, I see the value to be stored is in a range [-1.0, 1.0].
>> I want to hear the comments from other developers :-),
>> whether the initial implementation should be FT_F2Dot14 (16bit)
>> or float (32bit, at least).
>
> Well, we have dropped 16bit support
>
> But, for now I think the storing part can be postponed until we have compared
> the
> accuracy. If there isn't a much difference in the accuracy of floats vs
> integers, then
> we can simply use 8 bits per pixel and store them as something like PNG.
> What do yo
I'm gonna do
> as Suzuki suggested
> and use floats for my initial draft and later without floats.
> And I'm not gonna focus on the saving part because the user can always do a
> conversion.
>
> Also, can I directly use *float* or use FT_Fixed?
>
> Thanks,
>
> Anuj
>
Dear Anuj,
I agree with Werner's comment.
It might be uncomfortable for you to leave an untested question, something
like "if I use a floating point calculation, the result could be better?".
Please use a floating point in your initial draft (if you want),
and let's discuss about the trade-off
am
most comfortable with it. But if it is necessary I will switch to Linux.
Do you use existing project file in the source tree? Or, do you use CMake?
Yes, I use cmake.
On Wed, May 6, 2020 at 11:08 AM suzuki toshiya
mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
Dear Anuj,
I was wondering if I could tweak th
ng else I should use,
> please let me know so that I can learn that in the meantime.
>
> Thanks,
> Anuj
>
> On Tue, May 5, 2020 at 10:32 AM suzuki toshiya
> mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
> Dear Anuj,
>
>> Should I call you Suzuki or Sir
Dear Anuj,
> Should I call you Suzuki or Sir Suzuki ? Which do you prefer?
"Suzuki" is sufficient! Please don't mind about the honorifics, I'm not a native
(or good) English user :-).
> I have a lot of questions and things to understand about the workflow, so can
> I ask them here only or is
Hello Anuj!
I'm suzuki toshiya, the one of your mentors. I'm glad to have a chance to help
your effort of the distance field.
I'm really old man who slipped to catch the wave of the recent e-communications
like twitter, Slack, Discord etc., and my organization is sometimes filtering
The circular dependency is a headache, but I don't think the
reconsideration of the building system is good place to discuss
the simplification of the dependency between FreeType and harfbuzz.
In my understanding, the features of harfbuzz used by FreeType are
very small subset, the classification
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
Dear Moazin,
Please browse the attached SVG: which paints a big blue square (1024 x 1024),
and clip small circle at the center of it (r=64). How do you evaluate the
bitmap_left and bitmap_top? bitmap_left is 512 - 64 = 448? Or, bitmap_left is 0?
Moazin Khatri wrote:
> `Resvg' works with two
Moazin Khatri wrote:
>> BTW, how resvg calculate the bitmap_left properties?
>
> It doesn't. But we can do it using it. For the sake of this explanation
> assume that no scaling is to be performed. We firstly use `resvg' to get a
> tight bounding box around the `inked' part. It will return us a
>If all of them have such, I would discuss such API is acceptable for SVG
>Native Viewer.
I meant, I would discuss whether such API is acceptable for SVG Native Viewer.
Regards,
mpsuzuki
On 2019/06/14 19:05, suzuki toshiya wrote:
> Oh, I should add a few more.
>
>> I'll
have such, I
would discuss such API is acceptable for SVG Native Viewer.
Regards,
mpsuzuki
On 2019/06/14 18:44, suzuki toshiya wrote:
> Dear Moazin,
>
> On 2019/06/14 17:27, Moazin Khatri wrote:
>> For the sake of this explanation please assume that we are only talking
>> a
Dear Moazin,
On 2019/06/14 17:27, Moazin Khatri wrote:
> For the sake of this explanation please assume that we are only talking about
> the SVG documents which only contain one glyph and the whole document is
> supposed to be rendered.
OK!
> [...] I want to know how they are required for
Sorry for lated response.
Werner LEMBERG wrote:
>> 1. Get the pixel data of the whole SVG doc [...]
>> 2. Get the bounding box of the whole doc (or the particular node) in
>>SVG coordinates. [...]
> OK. Toshiya-san and/or Moazin, what about svgnative?
The SVG document object in SVG Native
Dear Moazin,
Thank you for writing the detailed report. Please let me comment 2 points (no
need to update the week 1).
* if the hyperlink to the commit on git repository (like
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=GSoC-2019-moazin=1fa8fe65
) is added, it helps the
Dear Vincent,
Vincent Torri wrote:
>> * the supported elements
>> I think the elements supported by this loader are defined by
>> TAG_DEF macro, thus, , , , , ,
>> , , , and, , , ,
>> are supported. Am I understanding correctly?
>
> yes
Good!
>> * input: xml support
>> If I can spot the
ed to rewrite whole of elf_gfx_xxx() to fit FreeType2,
simply I would respond "oh, too big, please modularize the
part just to support SVG, I would reconsider after seeing it".
Is it easy for EFL expert?
Regards,
mpsuzuki
Vincent Torri wrote:
> On Tue, May 21, 2019 at 6:00 PM suzu
Hi Vincent, Alexei,
On 2019/05/21 22:04, Alexei Podtelezhnikov wrote:
On Tue, May 21, 2019 at 5:35 AM Vincent Torri wrote:
as I have said, in our project, we parse ourselves the svg and use
freetype renderer directly for the rendering. we do not depend on any
external library
I noticed.
Hi,
Checking the feature range of libexpat, I found there are many
overescaped characters looking like "lt;".
It's very hard for me to translate into the appropriate format
in my brain on the fly, so I filed a pull request to fix them.
https://github.com/libexpat/libexpat.github.io/pull/15
In
Dear Moazin,
Wow, great! It would be very meaningful for you to have your own handaxe to
enter the jungle of unfamiliar softwares, because you can understand the
behaviour of your own handaxe completely. Although I've just taken a glance on
your code, I'm sure it's very clean and no need to have
Hi,
My forked repository of SVG Native Viewer
https://github.com/mpsuzuki/svg-native-viewer
, for the development of Cairo backend, has 2 important branches;
one is master, which is not changed from Adobe's original master branch,
another is cairo branch, which is my work-in-progress branch.
Dear Behdad,
Alexei wrote:
> Whatever external SVG renderer you choose, please use FT_Renderer facility to
> hook it up with FreeType instead of creating a set of SVG specific functions:
> an SVG glyph should be tagged as FT_GLYPH_FORMAT_SVG, which is then picked up
> by the dedicated SVG
Dear kind people giving the information on yet another SVG rendering software,
I'm sorry for that I ask for more detailed introduction, because I'm unsure
whether you're just trying to complete a list of SVG rendering softwares
(or softwares which has its own SVG renderer), or, you (strongly)
Dear Moazin,
> What's the status of your Cairo based rendering port? Is it as complete as
the Skia based rendering port? If both are complete, which one would you prefer to
be set as the default one for use with FreeType? and why?
It's ready to render an SVG to other surfaces (now
Dear Moazin,
The current status of my document is like this:
https://github.com/mpsuzuki/svg-native-viewer/blob/cairo-cpp11/README.md
Dirk told me that current Skia backend is designed for m70.
Also, maybe by some accident, Skia backend is forcibly disabled
if the platform detected by cmake is
; now. I can also relate it to Werner's SVG Global and Local initialization.
Basically, Werner just explained to me how we will be plugging modules in. Everything is clear and
in perspective now.
The terminology of "staying/non-staying" is totally fine to me.
Thank you,
Moazin
On Fri, May
Dear Moazin,
On 2019/05/09 21:13, Moazin Khatri wrote:
> Thank you for taking the time to write so much. It's really helpful.
My pleasure!
> I already know about how callbacks in languages like JS and Python work and I
am also familiar with how function pointers can be used to implement
Dear Werner,
On 2019/05/09 14:47, Werner LEMBERG wrote:
at least, I hope that this won't happen.
Me too!!!
Regards,
mpsuzuki
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Dear Behdad,
On 2019/05/09 14:18, Werner LEMBERG wrote:
Now, some would claim that that's exactly what is allowed in
OpenType. Again, that's what we will be discussing to make happen.
As it happens, there is no relationship between OpenType and SVG
Native.
OK.
Thank you for reminding that,
so done with your Cairo
based rendering port. I know how abstractions like these can be written in C++
via the use of Virtual Functions. But I am not sure how collaboration by
callbacks work or even if it's the same idea. I apologize in advance if I have
got some bit, or all of it wrong. Please ex
Dear Moazin, Alexei,
In my understanding, Sylvain's idea is much different from
the draft schedule of GSoC project of Moazin: I think Moazin
was going to combine some well-known & tested existing SVG
renderer, not going to write yet another SVG renderer.
Doing it might require big change of the
nking libsvgtiny is better than callback system, please
let me know.
Regards,
mpsuzuki
sylvain.bertr...@gmail.com wrote:
> On Wed, May 08, 2019 at 12:12:50PM +0000, suzuki toshiya wrote:
>> As far as I can remember, libsvgtiny was not discussed in the thread for
>> SVG-OT support. I didn't
Dear Sylvain,
As far as I can remember, libsvgtiny was not discussed in the thread for
SVG-OT support. I didn't know the exist of libsvgtiny, I must thank you
for giving the information.
But I want to know, you're already familiar with libsvgtiny and you suggest
as the libsvgtiny is the best
1 - 100 of 480 matches
Mail list logo
