Re: Bug report: Allow CFF based OT fonts with missing map table

[suzuki toshiya]

Dear Adam, Derek,

Adam, thank you for reminding that SFNT-wrapped PostScript fonts
on Apple platforms, it sounds reasonable attitude to handle such
incorrectly(?) embedded CFF font.

Derek, my understanding of current situation is:

1) currently FreeType simply raises an error for "head + CFF"
stream without special information. Even if a FreeType client
is capable to process such stream, the client has to catch all
errors and re-investigate the content of the stream. It is
"duplicating" of the font parsing.

2) the option best for the PDF rendering is "dealing with
head + CFF stream as simple CFF stream, ignoring head table".

3) another option better than current is "raising special
error indicating 'CFF is included, but other essential
tables for CFF OpenType are missing' and let the FreeType
client decide how deal such special case.

Is it correct?

I would try to make an artificial example by adding "head"
table to its internal CFF streams, to investigate how existing
PDF viewers handle such. I would ask how such PDF set the
font descriptor metadata to "head + CFF" stream in later.

I'm quite sorry for that I'm too busy to recover my PDF
playground in this month, I hope this issue is not immediate
to be resolved within a few days.

Regards,
mpsuzuki

On 2024/06/06 4:40, Adam Twardoch (List) wrote:



My own focus is on PDF files. The PDF spec says that fonts declared as
OpenType should be OpenType, and the files I'm looking at violate the
spec. (PDF also supports standalone CFF fonts, so it's relatively
little extra work for me to pull the CFF blob out of these bogus
"OpenType" fonts, and handle it as a CFF font.)

Oh yes, you're right there. However, this is a very general problem. Even though OpenType 
is a Microsoft trademark, Microsoft had done a very poor job in explaining/defining what 
is and what ISN'T an "OpenType font".

Windows had been announcing OpenType fonts with a glyf table but without a DSIG table as 
"TrueType" for many years, even though TrueType is an Apple trademark. So many end-users 
for a long time associated CFF-based OpenType with "OpenType".

And PDF has its own notion of font format "branding", and then there's a 
question of how certain apps like Acrobat present these.

I lost count of the different variants of fonts that "can exist" in a PDF a log 
time ago. I guess a Type42 with a variable CFF2 table is also theoretically possible :) 
Or with just CBDT, without glyf and CFFx.

One thing for sure: on "desktop", certain fonts work out they don't, but they need to be kind of 
"complete". But PDF has this flurry of "partial font resources" which makes it 
extra-complex.

A.

Re: Bug report: Allow CFF based OT fonts with missing map table

[suzuki toshiya]

Dear Derek,

Thank you very much for the info, I was thinking that some
old versions of free software made (or converted) such, but
it seems to be my misunderstanding.

Although I cannot reproduce such PDFs immediately, I think
your request is reasonable.

(I would join the thread following to Adam's post)

Regards,
mpsuzuki

On 2024/06/06 3:58, Derek B. Noonburg wrote:

On Wed, 5 Jun 2024 10:37:16 +0900
suzuki toshiya  wrote:


Just curious, is it possible for you to guess the workflow how such
PDFs were made? Any legacy softwares which we cannot obtain anymore
might be used?


 From the PDF metadata in the two PDF files:

Creator:Adobe InDesign CS4 (6.0.5)
Producer:   Adobe PDF Library 9.0

Creator:Adobe InDesign CS5 (7.0.3)
Producer:   Adobe PDF Library 9.9

I should mention that PDF metadata is somewhat unreliable -- it's quite
possible that the files were modified by some other software, without
changing the metadata.

The first one has both 8-bit and 16-bit CFF fonts embedded in
SFNT/OpenType wrappers, with no other tables.

The second one has just 8-bit fonts, which have 'CFF ' and 'cmap'
tables (and no other tables).

- Derek

Re: ["freetype-devel] Re: Bug report: Allow CFF based OT fonts with missing map table

[suzuki toshiya]

Dear Derek,

Just curious, is it possible for you to guess the workflow how such PDFs were 
made?
Any legacy softwares which we cannot obtain anymore might be used?

Regards,
mpsuzuki

On 2024/06/05 7:36, Derek B. Noonburg wrote:

On Fri, 31 May 2024 22:57:30 -0400
Alexei Podtelezhnikov  wrote:


Derek,

On Fri, May 31, 2024 at 2:23 PM Derek B. Noonburg
 wrote:

For what it's worth, I've encountered the same problem in a few PDF
files. In all the cases I've seen, the OpenType file contains just
the 'CFF ' table. My code checks for a missing 'head' table, and in
that case it extracts the CFF blob and handles it as a CFF (not
OpenType) font.

I haven't run into a font that has 'head' and 'CFF ', but not
'cmap'. If that's what you have, it would be a problem for my code,
too.


Please leave a comment at
https://gitlab.freedesktop.org/freetype/freetype/-/issues/1278
If you can attach an example PDF file with such font. It'd be even
better if you proposed an MR.


I only have a couple example files, and they were both received from
customers under NDA, unfortunately. I can extract a font if you're
interested, but I don't think that will really prove anything to you.

It looks like some software (my sample files are ~10 years old) decided
to wrap a CFF font into an sfnt structure, with the single 'CFF '
table, and call it an OpenType font. I see a lot of dodgy fonts in PDF
files; I imagine you have similar stories as a FreeType maintainer...

For the record, I don't consider this particular case a FreeType bug,
but rather a bug in the PDF file. I added the workaround in my Xpdf code
long ago.

- Derek

Re: which language you would use for X11-less macOS graphic framework?

[suzuki toshiya]

Thank you very much for good introduction of PyObjC. Your comment "(Swift) is quite 
large" is about Swift on Linux? or both of macOS and Linux?

In my understanding, the basic idea of Ahmet's GSoC 2024 is a rewriting of 
freetype-demos/graph/mac to catch up with the latest macOS, not an introduction 
of new nice FreeType demo programs written in scripting language.

freetype-demos/graph is a source tree for an object file with portable frontend 
(to be called by C) and platform-dependent backend, like X11, Win32, OS2 and 
BeOS. It's hard for me to think about a C object file which can call PyObjC 
internally, although it might be possible.

If somebody wants to have a Python-based toolkit to develop new nice FreeType 
demo programs, it's good, but for such requirements, using softwares with 
platform dependencies like PyObjC, is not the best. PyGTK+ or PyQt might be 
better, I think. Am I missing some points?

Regards,
mpsuzuki

On 2024/05/02 18:38, Hin-Tak Leung wrote:

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 Linux. 
You'll find accelerated graphics works on Linux but not on Mac OS X. (There are 
two existing bugs on skia-python specific to Mac OS X).

Metal is what Apple offers instead of Open GL. There is a feature request (I 
filed it to remind myself...) to switch on Metal support on Mac OS X for 
skia-python since Open GL is lacking.

Before you dive into Swift, considering watching some of Just van Rossum 's 
videos on YouTube for inspirations. Just is a font designer who also happens to 
be brother of Guido (inventor of Python). Just uses Mac OS as most graphics 
designer people do, and you would be amazed what you can do with Python 
GUI-wise on Mac OS, if your brother happens to be the most knowledgeable person 
about Python in the world :-) ... and check out Just's various software on 
github too after you check out the videos.

I think Just uses pyobjc (python binding to objective c), which is bunded on 
mac os x's shipped Python. But, have a look at what Just uses lately; he may 
have some swift stuff too. Anyway, he is Mac OS-based, and his software works 
are open-source and mostly about fonts, so you just find plenty to take 
inspiration on. (I don't think he subscribes to freetype-devel, but I could be 
wrong...)


On Thursday, 2 May 2024 at 09:59:52 BST, Ahmet Göksu  wrote:


Thank you for your guidance.

I agree with your 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) Objective-C and Cocoa framework
3) Swift

I think 2) or 3) are (still) reasonable options, but 1) is not anymore.
I'm unfamiliar with a market trend for Apple products, but sometimes
I hear a few people (working for iOS softwares) promoting Swift as
Swift is in, and Objective-C is out.

Also, there would be alternative approach, like Qt, to keep from playing
with Apple-specific technologies.

Do you have any preference?

Regards,
mpsuzuki

On 2024/05/02 14:30, Ahmet Göksu wrote:
Hi Suzuki,

Thank you, I am so excited to work with you!

The new goal is Native Graphics Backend for FreeType Demos on macOS.
I have updated on the GSoC website but the proposal file is unable to change.

Here you can find my proposal in the attachments.

Best,
Goksu
goksu.in
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 2nd was written for older goal
(an improvement of ftbench and related).

Regards,
mpsuzuki

On 2024/05/02 4:31, Ahmet Göksu wrote:
Hello!
Its Ahmet Goksu, last years GSoC contributor on ftbench.
This year, I will be contributing development graphics backend natively on 
macOS without X11.

Its so exciting to be here again!

here are my infos to connect:

https://www.linkedin.com/in/ahmetgoksu/
https://github.com/goeksu
https://resume.goksu.in

Best,
Goksu
goksu.in

Re: which language you would use for X11-less macOS graphic framework?

[suzuki toshiya]

Good to hear that you have your own preference!
I would prepare Swift environment in my side :-)

Regards,
mpsuzuki

P.S.
SVG Native Viewer has a small demo written in
Objective-C with Cocoa framework.

On 2024/05/02 17:59, Ahmet Göksu wrote:

Thank you for your guidance.

I agree with your 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) Objective-C and Cocoa framework
3) Swift

I think 2) or 3) are (still) reasonable options, but 1) is not anymore.
I'm unfamiliar with a market trend for Apple products, but sometimes
I hear a few people (working for iOS softwares) promoting Swift as
Swift is in, and Objective-C is out.

Also, there would be alternative approach, like Qt, to keep from playing
with Apple-specific technologies.

Do you have any preference?

Regards,
mpsuzuki

On 2024/05/02 14:30, Ahmet Göksu wrote:
Hi Suzuki,

Thank you, I am so excited to work with you!

The new goal is Native Graphics Backend for FreeType Demos on macOS.
I have updated on the GSoC website but the proposal file is unable to change.

Here you can find my proposal in the attachments.

Best,
Goksu
goksu.in
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 2nd was written for older goal
(an improvement of ftbench and related).

Regards,
mpsuzuki

On 2024/05/02 4:31, Ahmet Göksu wrote:
Hello!
Its Ahmet Goksu, last years GSoC contributor on ftbench.
This year, I will be contributing development graphics backend natively on 
macOS without X11.

Its so exciting to be here again!

here are my infos to connect:

https://www.linkedin.com/in/ahmetgoksu/
https://github.com/goeksu
https://resume.goksu.in

Best,
Goksu
goksu.in

which language you would use for X11-less macOS graphic framework?

[suzuki toshiya]

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

I think 2) or 3) are (still) reasonable options, but 1) is not anymore.
I'm unfamiliar with a market trend for Apple products, but sometimes
I hear a few people (working for iOS softwares) promoting Swift as
Swift is in, and Objective-C is out.

Also, there would be alternative approach, like Qt, to keep from playing
with Apple-specific technologies.

Do you have any preference?

Regards,
mpsuzuki

On 2024/05/02 14:30, Ahmet Göksu wrote:

Hi Suzuki,

Thank you, I am so excited to work with you!

The new goal is Native Graphics Backend for FreeType Demos on macOS.
I have updated on the GSoC website but the proposal file is unable to change.

Here you can find my proposal in the attachments.

Best,
Goksu
goksu.in
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 2nd was written for older goal
(an improvement of ftbench and related).

Regards,
mpsuzuki

On 2024/05/02 4:31, Ahmet Göksu wrote:
Hello!
Its Ahmet Goksu, last years GSoC contributor on ftbench.
This year, I will be contributing development graphics backend natively on 
macOS without X11.

Its so exciting to be here again!

here are my infos to connect:

https://www.linkedin.com/in/ahmetgoksu/
https://github.com/goeksu
https://resume.goksu.in

Best,
Goksu
goksu.in

Re: Hello Again

[suzuki toshiya]

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 of ftbench and related).

Regards,
mpsuzuki

On 2024/05/02 4:31, Ahmet Göksu wrote:

Hello!
Its Ahmet Goksu, last years GSoC contributor on ftbench.
This year, I will be contributing development graphics backend natively on 
macOS without X11.

Its so exciting to be here again!

here are my infos to connect:

https://www.linkedin.com/in/ahmetgoksu/
https://github.com/goeksu
https://resume.goksu.in

Best,
Goksu
goksu.in

Re: Question regarding gSoc 2024

[suzuki toshiya]

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 wrote:

Dear Brad,

Thank you for reminding that. I would take a look,
we should not the potential contributors confused...

Regards,
mpsuzuki

On 2024/02/22 15:24, Brad Neimann wrote:

Hi Suzuki,

This email prompted me to check the official GSoC website. It still
lists FreeType as a 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 project would be unable to have a project
in GSoC 2024.

--

I don't know any existing modern communication channels for
young people, like Discord or Slack. Do you know any existing
channel which you want the developers to check the discussion?

Regards,
mpsuzuki


On 2024/02/22 8:10, Nitish Jha wrote:

Hello everyone,

I'm Nitish, a computer science student from India. I'm eager to
contribute to FreeType for Google Summer of Code 2024, and I have a
few questions.

As I was exploring the idea list, I noticed that the build system
project was listed as an idea for GSoC 23. I'm interested in this
project, but I'm uncertain if the ideas listed on
https://freetype.org/gsoc.html
are intended for GSoC 24. At the top of the page, it states, "The
FreeType project participates in Google Summer of Code 2023. Here is
our list of possible projects." If these ideas are not for GSoC 24,
could you please direct me to where I can find the ideas for GSoC 24?

Additionally, I'm curious if there are any communication channels
like Discord or Slack available for FreeType, where contributors can
discuss project ideas and collaborate effectively.

Thank you for your assistance.

Re: GSoC 2024 idea list is not released.

[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 
in GSoC 2024, but the idea list for 2024 has not been released yet. Could you 
please provide some insight into this? I am keen on contributing and have the 
capability to propose my own project idea if necessary. Moreover, I am 
confident in my ability to work on the project with minimal guidance from a 
mentor.
If this approach aligns with your expectations, please let me know.

Thank you,
Akhilesh

Re: Question regarding gSoc 2024

[suzuki toshiya]

Dear Brad,

Thank you for reminding that. I would take a look,
we should not the potential contributors confused...

Regards,
mpsuzuki

On 2024/02/22 15:24, Brad Neimann wrote:

Hi Suzuki,

This email prompted me to check the official GSoC website. It still
lists FreeType as a 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 project would be unable to have a project
in GSoC 2024.

--

I don't know any existing modern communication channels for
young people, like Discord or Slack. Do you know any existing
channel which you want the developers to check the discussion?

Regards,
mpsuzuki


On 2024/02/22 8:10, Nitish Jha wrote:

Hello everyone,

I'm Nitish, a computer science student from India. I'm eager to
contribute to FreeType for Google Summer of Code 2024, and I have a
few questions.

As I was exploring the idea list, I noticed that the build system
project was listed as an idea for GSoC 23. I'm interested in this
project, but I'm uncertain if the ideas listed on
https://freetype.org/gsoc.html
are intended for GSoC 24. At the top of the page, it states, "The
FreeType project participates in Google Summer of Code 2023. Here is
our list of possible projects." If these ideas are not for GSoC 24,
could you please direct me to where I can find the ideas for GSoC 24?

Additionally, I'm curious if there are any communication channels
like Discord or Slack available for FreeType, where contributors can
discuss project ideas and collaborate effectively.

Thank you for your assistance.

Re: Question regarding gSoc 2024

[suzuki toshiya]

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 Discord or Slack. Do you know any existing
channel which you want the developers to check the discussion?

Regards,
mpsuzuki


On 2024/02/22 8:10, Nitish Jha wrote:

Hello everyone,

I'm Nitish, a computer science student from India. I'm eager to contribute to 
FreeType for Google Summer of Code 2024, and I have a few questions.

As I was exploring the idea list, I noticed that the build system project was listed as 
an idea for GSoC 23. I'm interested in this project, but I'm uncertain if the ideas 
listed on https://freetype.org/gsoc.html are intended for GSoC 24. At the top of the 
page, it states, "The FreeType project participates in Google Summer of Code 2023. 
Here is our list of possible projects." If these ideas are not for GSoC 24, could 
you please direct me to where I can find the ideas for GSoC 24?

Additionally, I'm curious if there are any communication channels like Discord 
or Slack available for FreeType, where contributors can discuss project ideas 
and collaborate effectively.

Thank you for your assistance.

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[suzuki toshiya]

The pkg-config interface should take care of everything easily. Debian and 
Ubuntu have the relevant qt5 pkg-config files. Other distributions should too.


Does pkg-config give the information for the pathname of moc?
(the original question by Hin-Tak was asking about the
appropriate path to use moc command)

In my understanding, pkg-config is primarily designed to
provide the information to compile & link the libraries,
not designed to provide the information about the binary
executable commands.

Regards,
mpsuzuki



On 2023/07/13 23:31, Hugh McMaster wrote:

On Thu, 13 Jul 2023 at 14: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 to switch 4, 5, and maybe 6 in future. It seems that
AX_HAVE_QT() does not check it, because the last update of AX_HAVE_QT
was 2014 X-p.

The pkg-config interface should take care of everything easily. Debian and 
Ubuntu have the relevant qt5 pkg-config files. Other distributions should too.

Re: skeletal makefile for ftinspect

[suzuki toshiya]

My first experiment changes both of freetype and freetype-demos.

(1) configure.raw is changed to generate qt5.mk under builds/unix/

https://gitlab.freedesktop.org/mpsuzuki/freetype-mps-wip/-/compare/master...wip-autotool-ftinspect

(2) Hin-Tak's ftinspect.mk is updated to include freetype-demos/Makefile and 
qt5.mk.

https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/master...wip-autotool-ftinspect

By using VPATH, I could unify several rules into simple one.

Now I'm testing with Ubuntu 22.04.2 LTS, "make -f ftinspect.mk bin/ftinspect"
can link ftinspect.

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://www.gnu.org/software/autoconf-archive/ax_have_qt.html


An alternative to that may be autotroll

https://github.com/tsuna/autotroll

that is used in ttfautohint.


  Werner

Re: skeletal makefile for ftinspect

[suzuki toshiya]

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 alternative to that may be autotroll

   https://github.com/tsuna/autotroll

that is used in ttfautohint.


 Werner

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[suzuki toshiya]

I would try to let AX_HAVE_QT() macro to find appropriate set:
https://www.gnu.org/software/autoconf-archive/ax_have_qt.html

In the case of Debian (and Ubuntu), qtchooser might be the unified
interface to switch 4, 5, and maybe 6 in future. It seems that
AX_HAVE_QT() does not check it, because the last update of AX_HAVE_QT
was 2014 X-p.

Regards,
mpsuzuki

On 2023/07/13 12:19, Hin-Tak Leung wrote:

Besides the obvious (LDFLAGS and CXXFLAGS), I wonder what's correct way to 
detect the qt moc tool? It is

/usr/bin/moc-qt5
/usr/lib64/qt5/bin/moc
/usr/lib64/qt5/bin/moc-qt5

on my system (fedora 38). They are all the same. "/usr/lib64/qt5/bin/moc" is probably 
canonical, instead of "/usr/bin/moc-qt5" I put down in ftinspect.mk . Because

/usr/lib64/qt-3.3/bin/moc
/usr/lib64/qt4/bin/moc
/usr/lib64/qt5/bin/moc

are the other versions I have.

On Thursday, 13 July 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 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 builds, and the resulting binary seems to work, but since I 
have never used ftinspect, I don't know if the result does or does not work 
correctly.

Do "make -f ftinspect.mk", and if it finds all the QT5 bits on your system (a few 
variables towards the top, edit them yourself), it should just build ftinspect. There is a 
"make -f ftinpect.mk clean" target to clean up too.

The fragment is written with the idea that it can be eventually loadable by another. 
Current ft2-demo already do such for "./graph/rules.mk".

- ideally it should be "include"d somewhere in the middle of the main Makefile, 
like graph/rules.mk, and inherit the values of some of the variables (*CFLAGS).
- adjusting paths (adds in some  $(OBJ_DIR2)) and libtool adaptation (change 
the explicit $(CXX) comple/link actions with libtool $(COMPILE) abtractions).
- remove the "clean" target and merge its work with the main one.

I'd be interested to know if the build binary is broken, or seems to do the 
job, either way.

Have fun adapting it...




On Monday, 10 July 2023 at 13:05:58 BST, Hugh McMaster 
mailto:hugh.mcmas...@outlook.com>> 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 available for use in FreeType:
autotools, cmake and meson. As I understand past discussions,
autotools is the default (and fully supported).

If ftinspect and, potentially, other software is not going to be built
via autotools, is there a case to move to another build system?

Hugh

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[suzuki toshiya]

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 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 builds, and the resulting binary seems to work, but since I 
have never used ftinspect, I don't know if the result does or does not work 
correctly.

Do "make -f ftinspect.mk", and if it finds all the QT5 bits on your system (a few 
variables towards the top, edit them yourself), it should just build ftinspect. There is a 
"make -f ftinpect.mk clean" target to clean up too.

The fragment is written with the idea that it can be eventually loadable by another. 
Current ft2-demo already do such for "./graph/rules.mk".

- ideally it should be "include"d somewhere in the middle of the main Makefile, 
like graph/rules.mk, and inherit the values of some of the variables (*CFLAGS).
- adjusting paths (adds in some  $(OBJ_DIR2)) and libtool adaptation (change 
the explicit $(CXX) comple/link actions with libtool $(COMPILE) abtractions).
- remove the "clean" target and merge its work with the main one.

I'd be interested to know if the build binary is broken, or seems to do the 
job, either way.

Have fun adapting it...




On Monday, 10 July 2023 at 13:05:58 BST, 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 available for use in FreeType:
autotools, cmake and meson. As I understand past discussions,
autotools is the default (and fully supported).

If ftinspect and, potentially, other software is not going to be built
via autotools, is there a case to move to another build system?

Hugh

Re: [MPEG-OTSPEC] the actual skia based ft2-demo ot-svg renderer hook code diff (Re: Success - Re: Skia-based ot-svg renderer hook to freetype)

[suzuki toshiya]

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.


Maybe some people in MPEG-OTSPEC have an interest in
"How many open implementations for OT-SVG are working?",
"What kind of new features in OT-SVG are expected?" or
"When the support of OT-SVG would be enabled by default,
or would it be easily configurable?". For such people,
your posting would be very useful. But the people interested
in the detailed comparison between the rsvg-backend and skia-
backend might not be the majority of the subscribers of
MPEG-OTSPEC.


I apologize 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:


Here it is, the actuall code diff for adding skia as a ot-svg renderer hook to freetype, 
as an alternative to rsvg/cairo. There is a new file "README.skia". I fixed the 
color change and the intermittent crash, so as far as I know the only thing is that it is 
occasionally 1-pixel off compared to rsvg/cairo.

This can be somewhat corrected by changing these two lines:

 x = bounds.left();  -> floor(bounds.left());
 y = bounds.top();  -> floor(boulds.left());

I am not convinced that skia is entirey wrong, actually; the equivalent rsvg 
location has some comments on doubts about rounding.

I thought of switching the hooks dynamically (between 3, rsvg_hook, skia_hook, 
and a new null_hook), but running init of one hook , switch in the middle and 
run the free of another hook is dangerous. So this is still done as a 
build-time change. Otherwise it would be great to switch dynamically to 
investigate the 1-pixel-difference problem.

For now, if somebody else wants to give this a try, especially a mac user or a 
windows user, and/or somebody want to build skia (I am lazy and just downloaded 
a not-too-old pre-built binaries), I like to hear about 1st-hand experience on 
that too.

The rest, please have a thought how to  switch the hook dynamically, without 
crashing

will probably post this up at
https://github.com/HinTak/harfbuzz-python-demos/ under a new directory 
"skia-adventure" and write there. Thanks for reading this far :-).









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 to 6?

There are 3 issues I see

- the first one is of course the color - seems to be a rgba vs bgra difference? 
i.e. the Alpha channel is the same, but red and blue swapped.
- 2nd one is not very noticeable on ftview but more on ftgrid - the glyph is 
shifted down by one pixel. Probably a rounding error somewhere.
- I have intermitent crashes from 'include/core/SkRefCnt.h:72: fatal error: 
"assert(this->getRefCnt() > 0)" ' . Prove I don't know Skia well enough yet. ( 
That's one week of learning Skia ...)

On the way also learns a few things - this is based on m110 . I see that even 
with main (close to m116), one of the headers I am using have changed location.

I tried updating skia-python 's bundled skia from m87 to m88 - just 1 
milestone, or roughly 4 weeks, to get a feel of how easy/hard it is. The main 
reason is that m88 is the first where the SVGDOM class is declared 
non-experimental. So I expect the SVG related headers to move. But the actual 
diff is close to about 1000 lines, took me a whole day. (by comparison, the 
fontval diff is a little over 4000 lines, and took 3 years). The amount of 
changes in skia per milestone is just alarming. That explains why nobody wants 
to ship skia shared libraries, and why skia-python is stuck at m87 for 2 years. 
Skia is just contantly changing from milestone to milstone.

That said, I think somebody should update skia-python's bundled skia from m87 
to m98 (COLRv1) and perhaps even m103 (OT-SVG). Google folks?

One milestone is about 1000 lines of code difference and a whole day,  I reckon 
it will take somebody working full time for 2 months to update skia-python to 
current-ish. (116 - 87 = 29 working days..., by the time one gets to m116, 
m117/m118 would be out...). If google folks are not moving a finger, and 
somebody else wants to fund me to tackle this, please feel free to get in touch.


I'll tidy the diff up and send it to freetype-devel at some point. At the 
moment it is just replacing all contents of rsvg-port.{c,h}. with

-#ifdef HAVE_LIBRSVG
+#ifdef HAVE_SKIA
...

-  SVG_RendererHooks  rsvg_hooks = { NULL, NULL, NULL, NULL };
+  SVG_RendererHooks  

Re: Future of autotools

[suzuki toshiya]

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 additional libraries, like Qt5 (you can find the
declaration of the dependency in src/ftinspect/meson.build).

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 should be added to existing freetype/configure, even
if libfreetype itself has no dependency with them?

Regards,
mpsuzuki


On 2023/07/11 1:10, Werner LEMBERG wrote:



If ftinspect and, potentially, other software is not going to be
built via autotools, is there a case to move to another build
system?


Well, yes.  Meson will eventually become the main tool for building
FreeType, I think (or rather, it definitely won't become CMake as the
default).  However, cleaning up the build system was/is a GSoC
project, so nobody else touched it in earnest.  In particular, I am
not a specialist for Meson; additionally, Meson itself is still quite
a moving target.


That's a bit unsatisfactory. Personally I only use the autotools/make
to build. Also as far as I know, last I heard there is(was?) a bug of
ttdebug being mis-built by meson - it is missing a -DUNIX or something
of that sort to control the command buffering.


Yep, https://gitlab.freedesktop.org/freetype/freetype-demos/-/issues/24


I sort of feel like raising it from time to time when the GSoC
students are updating the build system "have a look at fixing that
too..." but ultimately it sounds like dumping uninteresting/tedious
work on young people.


It seems so, unfortunately.


I think Werner would respond at some point writing "patches welcome"
for building ftinspect with autotools :-).


You are reading my mind :-)


 Werner

Re: Savannah ft2-demos repo no longer getting updated?

[suzuki toshiya]

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 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 intentional or oversight?  I assume it is just
oversight since freetype2 stays in sync more or less, and it is one
of those things that only needs a one-off set up and works forever
afterwards.


It seems that you have accidentally committed to Savannah instead of
freedesktop.org!  The last few commits starting from May 5th and 6th
are not present in our main repository.

   https://git.savannah.gnu.org/cgit/freetype/freetype2-demos.git/log/

Please fix that.  I guess this will also enable the mirroring bot
again.


 Werner

Any prebuilt binary of Skia is widely distributed? (Re: Skia-based ot-svg renderer hook to freetype (Re: Scheduling Zoom meeting to discuss new proposals and AHG recommendations)

[suzuki toshiya]

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.
Checking the availability and compatibility
of the Skia was a difficult problem. To test
the features, I had to build the Skia binary
by myself for testing, and it was too hard to
incorporate into the CI testing because I don't
believe in the reliability of a huge homegrown
binary, and building the Skia binary consumes
so long time for the CI platforms.

In addition, even if there is an individual
Skia package in some Linux distributions,
maybe the Chromium browser would not use it
- Chromium binary may merge the Skia into
its binary, and there is no separate library.

The skin-python can wrap up such issues, but
I wonder whether the API of the prebuilt Skia
binary in the PIP package is stable. And even
if it is stable, I'm still wondering whether
it is a good idea to link the binary content
of the PIP package from the external (non-PIP)
binaries. Are there any applications providing
the Skia library as an individual component?

Regards,
mpsuzuki

On 2023/07/05 3:14, Hin-Tak Leung wrote:

(Cross-posted to freetype-devel)

It seems that skia itself has all the rsvg equivalent to implement the ot-svg 
renderer callback hooks in freetype, but skia-python is missing the python 
equivalent of SKSVGDOM::renderNode() . This means that if I re-write the 
rsvg-based python svgrender hooks with skia-python, it would only work with 
Adobe/Mozilla OT-SVG fonts, but not Google OT-SVG fonts (until skia-python 
improves).

I think I'll give it a go and try to put an example out under freetype-py/examples (probably will 
call it "ot-svg-example-skia.py", after the other "ot-svg-example.py") . 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 
fish it out of freetype-py/examples ... :-).

On Tuesday, 4 July 2023 at 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 
and gradient implementations require time and effort to make them reasonably 
fast.



It isn't repeating these concepts in Freetype. Currently, in one (actually two, 
c and python) implementation, Freetype farms off rendering of OT-SVG glyphs to 
rsvg, which in turn is cairo-based, to do the actual rendering. FreeType just 
provides a plug-in system which allows an external library to do the rendering. 
Basically Freetype gives out the glyph svg outlines etc, and the external 
library fill in the extent and the actual buffer of a rendered bitmap. This 
allows any freetype-based applications to use OT-SVG fonts.
___
mpeg-otspec mailing list
mpeg-ots...@lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec

Re: ftbench update: make integrated

[suzuki toshiya]

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 build libfreetype is $(CC), thus, using $(CC) would
be safer option (in above example, using $(CCexe) may try to build
Linux binary executable from Win32 binary library).

Regards,
mpsuzuki


On 2023/06/15 0:42, Werner LEMBERG wrote:


Helo Ahmet,



I want to inform about last update about ftbench.


Thanks!


fonts are in their own directory but 5 fonts takes
really much time.


Please give more details.  What do you consider as 'really much time'?
You can adjust the number of loops used in `ftbench` with command-line
options, so it's not clear to me where exactly the problem lies.


2) does the html file satisfy the needs?


Please post a sample to this list for all the people who are not going
to compile your branch.


3) i am planning to move to develop and integrating cmake and
meson.  is there anything forgotten so far?


I don't think so.

Here is a list of things that I noticed while inspecting your code.

* `testing.mk`

   - Why `$(BASELINES)` and not `$(BASELINE)`?  Are you going to
 support more than a single baseline?  If yes, how shall this
 work'?

 But maybe this is just a misunderstanding of what I call a
 'baseline': This is the status of the repository (i.e., a certain
 commit) that is known to work, and that gets compared against some
 new code (usually in a git branch), checking for differences.

   - Using `pkg-config` is a bad idea: You are essentially compiling
 against another installed FreeType version, which is definitely a
 no-go.  The tests must be executed with the uninstalled, just
 compiled version of the library.

   - `freetype.mk` already defines `$(PYTHON)`.  Don't override this!
 If necessary you might add a test for python 3.

   - Please look up the GNU make manual and check the section on
 order-only prerequisites – this is what you should use for the
 rules to create directories.

   - Don't call `gcc` directly!  You should rather use `$(CC)` (or
 probably `$(CCexe)`, I'm not sure right now).

   - AFAICS, compilation outside the source tree still doesn't work.
 You have to use `$(OBJ_DIR)` and friends.

   - Don't call `rm` directly.  You should rather use `$(RM)`.


1) benchmark is running by only one font. i have total 5 but takes
too long.  how many should benchmark work with and should i
subset fonts to smaller pieces (like 50 glyphs)?


You should define a make variable to hold default command-line
arguments for `ftbench`, and which can be overridden while calling
`make`.


2) does the html file satisfy the needs?


I don't know yet :-)


3) i am planning to move to develop and integrating cmake and meson.
is there anything forgotten so far?


Perhaps it makes more sense to make the default build work as it
should before handling cmake and meson...


 Werner

Re: Interested in GSOC

[suzuki toshiya]

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 and publishing small software or patches to showcase 
your excellent capabilities might be a good idea.

On 2023/05/06 3:55, 68 Abhishek wrote:

Respected Sir / Mam
I am Abhishek and I am in my 1st year of my engineering and I am studying in 
University Institute of engineering and Technology (MDU) I Scored 5697 Rank in 
IIT Advanced . I read an article on your website Google Summer of Code and I am 
interested in your organisation and I want to join as a student .
Thanks and Regards

Re: any small software to test the incremental loading feature?

[suzuki toshiya]

Hi,

The GhostScript developers replied, "GS had never used it,
and you can assume that the GS will not use it in the future."

https://ghostscript.com/pipermail/gs-devel/2023-May/010673.html

In addition, I found that the current t1cid driver requires
a trailing section of the binary data quoted by
"%%BeginData ... (Binary)... StartData %%EndData" structure
(see cidparse.c), which is a binary stream of the offset
tables and the glyph data.

The font dictionary created in the PostScript language space,
by the incremental definition (specified in PLRM), does not
have such a section (it uses the /GlyphDirectory array or
dictionary). So if we had a nice PostScript interpreter trying
to pass an incrementally-defined font dictionary to FreeType
as a completed stream, current FreeType could not accept it.

I cannot conclude that the incremental loading feature of
t1cid is solely for PostScript's incremental definition. But
disabling it by the default configuration may have little
impact on the existing clients.

After the improvement of FT_Get_CID_From_Glyph_Index() for
t1cid, I would make another MR to document the change and
disable it by default.

Regards,
mpsuzuki

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.

On 2023/04/30 17:07, suzuki toshiya wrote:

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 never been used and will never use.

If they never use it, it may be possible to define our
use case to clarify what we tested. Even if we decide
to remove it in the future release, the "disabled-by-default"
might be an appropriate next step.

Anyway, for the improvement of FT_Get_CID_From_Glyph_Index(),
I understand that there would be no urgent requirement to
modify the part of the incremental loading. It is helpful
information for me.

Regards,
mpsuzuki

On 2023/04/29 22:48, Werner LEMBERG wrote:



* In summary, the current GhostScript will never use the incremental
loading feature in the t1cid driver of FreeType.  In addition, I'm
questioning whether the incremental loading feature of t1cid is
helpful to render the PostScript document using the incremental
definition of the CIDFontType 0 dictionary.


Thanks for your detailed analysis!  This sounds as if you favor the
removal of the code.  In case that is true: What about mentioning in
the `CHANGES` file that incremental loading gets removed from the
`t1cid` driver after the next release?


  Werner

Re: any small software to test the incremental loading feature?

[suzuki toshiya]

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 never been used and will never use.

If they never use it, it may be possible to define our
use case to clarify what we tested. Even if we decide
to remove it in the future release, the "disabled-by-default"
might be an appropriate next step.

Anyway, for the improvement of FT_Get_CID_From_Glyph_Index(),
I understand that there would be no urgent requirement to
modify the part of the incremental loading. It is helpful
information for me.

Regards,
mpsuzuki

On 2023/04/29 22:48, Werner LEMBERG wrote:



* In summary, the current GhostScript will never use the incremental
   loading feature in the t1cid driver of FreeType.  In addition, I'm
   questioning whether the incremental loading feature of t1cid is
   helpful to render the PostScript document using the incremental
   definition of the CIDFontType 0 dictionary.


Thanks for your detailed analysis!  This sounds as if you favor the
removal of the code.  In case that is true: What about mentioning in
the `CHANGES` file that incremental loading gets removed from the
`t1cid` driver after the next release?


 Werner

Re: any small software to test the incremental loading feature?

[suzuki toshiya]

Hi,

Finally, I concluded that GhostScript never uses the incremental loading 
feature in cid_glyph_load(). The mechanism is below.

* The incremental loading of CIDFontType 0 (a.k.a. FontType 9) is described in PostScript language 
reference pp.352-356 and pp.375-377. In the "incremental loading" ("incremental 
definition," in PLRM terminology), the PostScript interpreter pushes the Type1 CharString 
glyph data for a specific glyph to the GlyphDirectory dictionary or array in the FontType9 
dictionary. There is no particular operator to do such an operation; regular PostScript operation 
would do.

* Because the procedure to insert the Type1 CharString glyph data is implemented by a regular 
PostScript program, we could not assume its representation (in the original PostScript document) is 
sufficiently raw & straightforward like that for Adobe Type Manager. For example, the part 
inserting the "一" glyph description is below (1200 is the CID for "一", in 
Adobe-Japan1 system):

%ADOBeginSubsetFont: IXYEVX+WadaGo-Bold-90msp-RKSJ-H-Identity-H AddGlyphs
Adobe_CoolType_Utility begin ct_MakeOCF begin
%ADOt1write: (1.0.24)
ct_GlyphDirProcs begin/IXYEVX+WadaGo-Bold-90msp-RKSJ-H 1 GetGlyphDirectory
1200 <041C60D8A8C9B5EE310DFF523C01B442319EB5152EBC5E42B2C8288176
4C52> |
!
end
end end
%ADOEndSubsetFont
reset_gvm
/IXYEVX+WadaGo-Bold-90msp-RKSJ-H-Identity-H findfont (snip)

Here, "Adobe_CoolType_Utility", "ct_MakeOCF", "ct_GlyphDIrProcs", "|", "!", and 
"reset_gvm" is the macro operators defined in the PostScript program named "Adobe CoolType Utility." It might be popular, but it 
is not a practical idea to make FreeType understand these operators directly.

* Therefore, we should let the PostScript interpreter reconstruct the CIDFontType 0 
dictionary without the help of FreeType. Does the PostScript interpreter need the 
incremental loading feature for CIDFontType 0? The PostScript interpreter already 
has the subset & self-standing font dictionary.

* The procedure in GhostScript is below.

1) A GS-specific operator, ".type9mapcid," extracts the Type1 CharString for a specified 
CID from a selected CIDFontType 0 dictionary. Its internal is described in zfcid0.c. This operator 
works with the font dictionary loaded on the PostScript language space, not only with the 
disk-resident font file. The "incrementally updated" font object is already in the 
PostScript language space. Its implementation is a function ztype9mapcid(), which is written fully 
in C and can be invoked from C language space if the PostScript language context is correctly 
specified.

2) zFAPIBuildGlyph9() is invoked to execute "show" or other operations to have 
an outline of a specified glyph in a specified font. zFAPIBuildGlyph9() invokes 
ztype9mapcid() from its C language space and retrieves the Type1 CharString to be 
rendered, with no help of FreeType.

3) How does GhostScript use FreeType to render the retrieved Type1 CharString? 
GhostScript makes a Type1 (not Type9) PostScript font on the memory (which 
includes some properties and subroutines taken from the FDArray) and passes it 
to FreeType (type1 driver, not t1cid driver). GhostScript provides its glyph 
description data by the callback function of FreeType's incremental loading 
feature (t1gload.c::T1_Parse_Glyph_And_Get_Char_String()) dynamically. 
Therefore, there is no need to repeat FT_Open_Face() for this synthesized Type1 
font when GS replaces the glyph description data. If you check FT_Load_Glyph() 
argument, you can find the glyph_index in its argument is always 0.

* In summary, the current GhostScript will never use the incremental loading 
feature in the t1cid driver of FreeType. In addition, I'm questioning whether 
the incremental 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 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 no glyph data. 
cid_load_glyph() can catch such an error but cannot stop the Type1 CharString 
rendering after successful loading. Therefore, using cid_load_glyph() for 
validating CID is too expensive; FT_Get_CID_From_Glyph_Index() is interested in 
the presence of the glyph data but has little interest in its rasterization 
result. For simple checking of the presence of the glyph data, I propose to 
separate the glyph data loading part of cid_load_glyph() as 2 helper functions; 
one is for incremental loading, another is a traditional 

any small software to test the incremental loading feature?

[suzuki toshiya]

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 no glyph data. 
cid_load_glyph() can catch such an error but cannot stop the Type1 CharString 
rendering after successful loading. Therefore, using cid_load_glyph() for 
validating CID is too expensive; FT_Get_CID_From_Glyph_Index() is interested in 
the presence of the glyph data but has little interest in its rasterization 
result. For simple checking of the presence of the glyph data, I propose to 
separate the glyph data loading part of cid_load_glyph() as 2 helper functions; 
one is for incremental loading, another is a traditional disk-resident font 
file. I drafted a few patches:

https://gitlab.freedesktop.org/mpsuzuki/freetype-mps-wip/-/compare/master...wip-t1cid-separate-loaders-of-fd-offsets?from_project_id=11053=false

But I need a good testing tool to check the possible regression for the 
incremental loading. One of the most straightforward ideas would be using 
GhostScript and some PostScript data generated by legacy printer drivers (which 
can emit the per-glyph Type1 CharString and embed it to the output but cannot 
make a self-standing CID-keyed font like that in PDF). But it is too big 
software. I wish there were smaller - no need to render seriously - testing 
tools. I tried to find something in the mailing list archive around 2002 
Jun-Jul (when the main trunk merged the incremental loading feature, 22 years 
ago!), but I could not find anything. Please let me know if anybody can 
remember how the developers tested in those days.

Nothing to say; I've already tried GhostScript. But GhostScript uses 
t1_load_glyph instead of cid_load_glyph.

The client of FreeType's incremental loading feature.
https://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=base/fapi_ft.c;hb=HEAD

The emitter of the font stream for the FreeType.
https://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=base/write_t1.c;hb=HEAD

There is an emitter of the incremental downloading font dictionary for 
PostScript Type1 font, write_t1.c written by Graham Asher himself), but there 
is no emitter for Type9 font (CIDFontType0 font).

Regards,
mpsuzuki

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

Just I filed a merge request

https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/277

about


cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=1
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=2
cid_load_glyph: invalid glyph 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 description for a given CID instead of
the declaration of the CID, as fontconfig does?

Currently, my patch cares only FT_Face->num_glyphs
for the face loaded by the t1cid driver. Do you
concern as "the num_glyphs is no more than the
declaration, there is no guarantee that the user
can get a glyph image of the CID within the range
0...FT_Face->num_glyph, FT_Load_Glyph() test is reliable"?

If so, the testing code might be like this:

https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/mr-ftdump-print-cid-ros-assume-order...ftdump-validate-all-cid?from_project_id=20389

When I execute it to sample CID-keyed fonts
(on O'Reilly's website) and other OpenType/CFF,
it is slow but acceptable as an optional feature.

But the problem I found is that the sample CID-keyed
fonts have many unimplemented CIDs; the font declares
them, but FreeType fails to load their glyph
instructions. If the FreeType library is built
with the FT_TRACE option, these sample CID-keyed
fonts on O'Reilly website generate many warnings, like:

/CIDSystemInfo dictionary
 Registry:Adobe
 Ordering:Japan1
 Supplement:  1

 Implemented CIDs:
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=1
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=2
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=3
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=4
(...)
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=8355
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=8356
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=8357
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=8358
   0,422,425-500,629,633-740,780-7477,7479-7554,8229-8263,8284-8285

Regards,
mpsuzuki

On 2023/04/21 5:08, Alexei Podtelezhnikov wrote:

Hi Suzuki,

Using these fonts
(https://resources.oreilly.com/examples/9781565922242/tree/master/adobe/samples)
I learned that FT_Load_Glyph interprets the glyph_index as CID. Could
you scan the CID range directly using FT_LOAD_NO_SCALE? Or, is this
still too slow?

Thanks
Alexei

On Thu, Apr 20, 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

( 
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-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 I'm unsure if it is a solid footstone
to exclude the unordered CIDs.
For example, "GB1 represents the first version of the ordering
based on the Chinese GB 2312-80 character set" describes
"how CID numbers are assigned to the characters? It is based
on the order of GB 2312-80", it might be independent with
the internal of CID-keyed font.

But anyway, yet I have no concrete example to justify my
concern about "zig-zag" mapping between GID and CID.

OK, so I propose - I'll rework my patch based on the assumption
"the larger GID is mapped to the larger CID, no zig-zag
mapping from GID to CID", to avoid 64kByte array allocation.
Then, when ftdump receives a font breaking this assumption,
ftdump aborts with an error, and indicates an email address
(or website?) to report the issue. Is it acceptable workaround?

Regards,
mpsuzuki

On 2023/04/20 11:08, Alexei Podtelezhnikov wrote:

Dear Suzuki,


Indeed. If GID-CIDs are already sorted, it's easy to dump the
available CIDs in a compressed syntax. Although I have no sample
font including unsorted CIDs, I'm unsure whether it is required
in some specifications.


The order of CIDs is in "registry, *ordering*, and supplement". Also
it is mentioned in the specs (5092): "A character collection consists
of an ordered set of all characters". I think we can rely on that.

If there is a CID to glyph index mapping in each file, why doesn't
FreeTyope generate a cmap?

Thanks,
Alexei

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

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 would happen when I try to convert
O'Reilly's old CID fonts to CFF or OpenType/CFF, but I can understand
your confusion about t1cid's FT_Get_CID_From_Glyph_Index().


Do you know where I can find some CFF CID-fonts?


Umm, it's good and difficult question. Adobe released Source Han family in 
OpenType/CFF formats.

https://github.com/adobe-fonts/source-han-sans/tree/release
https://github.com/adobe-fonts/source-han-serif/tree/release/

but I heard their ROSs are "Adobe-Identity-0" (not the traditional Adobe-CNS1, 
etc),
they give no information what kind of the glyphs are included, and no 
information
whether their glyph sets are same with other fonts marked as "Adobe-Identity-0".
The experts in this project might have regarded the declaration of glyph set by
ROS is legacy technology.

There are reworked versions of Source Hans, named "HaranoAji", to emulate
traditional Adobe-Japan1 etc, but the project owner explains "cover
Adobe-Japan1-6 all, but cover Adobe-Japan1-7 partially".

https://github.com/trueroad/HaranoAjiFonts (Adobe-Japan1)
https://github.com/trueroad/HaranoAjiFontsCN (Adobe-GB1)
https://github.com/trueroad/HaranoAjiFontsTW (Adobe-CNS1)
https://github.com/trueroad/HaranoAjiFontsKR (Adobe-KR)
https://github.com/trueroad/HaranoAjiFontsK1 (Adobe-Korea1)

Regards,
mpsuzuki

On 2023/04/22 0:48, Alexei Podtelezhnikov wrote:

Suzuki,


Currently, my patch cares only FT_Face->num_glyphs
for the face loaded by the t1cid driver. Do you
concern as "the num_glyphs is no more than the
declaration, there is no guarantee that the user
can get a glyph image of the CID within the range
0...FT_Face->num_glyph, FT_Load_Glyph() test is reliable?


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.

Do you know where I can find some CFF CID-fonts?

Alexei

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

Dear Alexei,

Excuse me; please let me ask your background to scan
all CIDs. Is it a confirmation of the existence of
the glyph description for a given CID instead of
the declaration of the CID, as fontconfig does?

Currently, my patch cares only FT_Face->num_glyphs
for the face loaded by the t1cid driver. Do you
concern as "the num_glyphs is no more than the
declaration, there is no guarantee that the user
can get a glyph image of the CID within the range
0...FT_Face->num_glyph, FT_Load_Glyph() test is reliable"?

If so, the testing code might be like this:

https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/mr-ftdump-print-cid-ros-assume-order...ftdump-validate-all-cid?from_project_id=20389

When I execute it to sample CID-keyed fonts
(on O'Reilly's website) and other OpenType/CFF,
it is slow but acceptable as an optional feature.

But the problem I found is that the sample CID-keyed
fonts have many unimplemented CIDs; the font declares
them, but FreeType fails to load their glyph
instructions. If the FreeType library is built
with the FT_TRACE option, these sample CID-keyed
fonts on O'Reilly website generate many warnings, like:

/CIDSystemInfo dictionary
   Registry:Adobe
   Ordering:Japan1
   Supplement:  1

   Implemented CIDs:
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=1
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=2
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=3
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=4
(...)
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=8355
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=8356
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=8357
cid_load_glyph: invalid glyph stream offsets
could not load a glyph for CID=8358
 0,422,425-500,629,633-740,780-7477,7479-7554,8229-8263,8284-8285

Regards,
mpsuzuki

On 2023/04/21 5:08, Alexei Podtelezhnikov wrote:

Hi Suzuki,

Using these fonts
(https://resources.oreilly.com/examples/9781565922242/tree/master/adobe/samples)
I learned that FT_Load_Glyph interprets the glyph_index as CID. Could
you scan the CID range directly using FT_LOAD_NO_SCALE? Or, is this
still too slow?

Thanks
Alexei

On Thu, Apr 20, 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

( 
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-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 I'm unsure if it is a solid footstone
to exclude the unordered CIDs.
For example, "GB1 represents the first version of the ordering
based on the Chinese GB 2312-80 character set" describes
"how CID numbers are assigned to the characters? It is based
on the order of GB 2312-80", it might be independent with
the internal of CID-keyed font.

But anyway, yet I have no concrete example to justify my
concern about "zig-zag" mapping between GID and CID.

OK, so I propose - I'll rework my patch based on the assumption
"the larger GID is mapped to the larger CID, no zig-zag
mapping from GID to CID", to avoid 64kByte array allocation.
Then, when ftdump receives a font breaking this assumption,
ftdump aborts with an error, and indicates an email address
(or website?) to report the issue. Is it acceptable workaround?

Regards,
mpsuzuki

On 2023/04/20 11:08, Alexei Podtelezhnikov wrote:

Dear Suzuki,


Indeed. If GID-CIDs are already sorted, it's easy to dump the
available CIDs in a compressed syntax. Although I have no sample
font including unsorted CIDs, I'm unsure whether it is required
in some specifications.


The order of CIDs is in "registry, *ordering*, and supplement". Also
it is mentioned in the specs (5092): "A character collection consists
of an ordered set of all characters". I think we can rely on that.

If there is a CID to glyph index mapping in each file, why doesn't
FreeTyope generate a cmap?

Thanks,
Alexei

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

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

( 
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-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 I'm unsure if it is a solid footstone
to exclude the unordered CIDs.
For example, "GB1 represents the first version of the ordering
based on the Chinese GB 2312-80 character set" describes
"how CID numbers are assigned to the characters? It is based
on the order of GB 2312-80", it might be independent with
the internal of CID-keyed font.

But anyway, yet I have no concrete example to justify my
concern about "zig-zag" mapping between GID and CID.

OK, so I propose - I'll rework my patch based on the assumption
"the larger GID is mapped to the larger CID, no zig-zag
mapping from GID to CID", to avoid 64kByte array allocation.
Then, when ftdump receives a font breaking this assumption,
ftdump aborts with an error, and indicates an email address
(or website?) to report the issue. Is it acceptable workaround?

Regards,
mpsuzuki

On 2023/04/20 11:08, Alexei Podtelezhnikov wrote:

Dear Suzuki,


Indeed. If GID-CIDs are already sorted, it's easy to dump the
available CIDs in a compressed syntax. Although I have no sample
font including unsorted CIDs, I'm unsure whether it is required
in some specifications.


The order of CIDs is in "registry, *ordering*, and supplement". Also
it is mentioned in the specs (5092): "A character collection consists
of an ordered set of all characters". I think we can rely on that.

If there is a CID to glyph index mapping in each file, why doesn't
FreeTyope generate a cmap?

Thanks,
Alexei

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

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
based on the Chinese GB 2312-80 character set" describes
"how CID numbers are assigned to the characters? It is based
on the order of GB 2312-80", it might be independent with
the internal of CID-keyed font.

But anyway, yet I have no concrete example to justify my
concern about "zig-zag" mapping between GID and CID.

OK, so I propose - I'll rework my patch based on the assumption
"the larger GID is mapped to the larger CID, no zig-zag
mapping from GID to CID", to avoid 64kByte array allocation.
Then, when ftdump receives a font breaking this assumption,
ftdump aborts with an error, and indicates an email address
(or website?) to report the issue. Is it acceptable workaround?

Regards,
mpsuzuki

On 2023/04/20 11:08, Alexei Podtelezhnikov wrote:

Dear Suzuki,


Indeed. If GID-CIDs are already sorted, it's easy to dump the
available CIDs in a compressed syntax. Although I have no sample
font including unsorted CIDs, I'm unsure whether it is required
in some specifications.


The order of CIDs is in "registry, *ordering*, and supplement". Also
it is mentioned in the specs (5092): "A character collection consists
of an ordered set of all characters". I think we can rely on that.

If there is a CID to glyph index mapping in each file, why doesn't
FreeTyope generate a cmap?

Thanks,
Alexei

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

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. If GID-CIDs are already sorted, it's easy to dump the
available CIDs in a compressed syntax. Although I have no sample
font including unsorted CIDs, I'm unsure whether it is required
in some specifications.

Anyway, I'm very happy to hear the negative comment on 64kBit array.
I would submit my MR based on 64kByte array, and commit it. I think
freetype-demos has no CI mechanism yet... Right?

Regards,
mpsuzuki


P.S.
Yet I have not checked in detail, Apple's TrueType spec has a "gcid"
table which is a simple array of CID (to be retrieved by a gid). I'm
interested in whether it can be included in a conventional TrueType
using glyf table (instead of OpenType/CFF). Currently, most fonts
supporting CID are PostScript-based fonts (t1cid or cff or OpenType/CFF),
so the glyphs are already sorted by their CIDs. If it is possible to
have a TrueType font including both of glyf and gcid, the glyphs would
be ordered not by CID but by Unicode.

On 2023/04/19 11:26, Alexei Podtelezhnikov wrote:

Dear Suzuki


BTW, if the 64kByte array to check CID availability can be
reduced to a 64kBit (= 8kByte for most architecture) array
by a bitshift calculation, is it the way to go?


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).

Thanks,
Alexei

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

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 architecture) array
by a bitshift calculation, is it the way to go?

I think FreeType2 had already dropped the 16-bit platforms,
so the allocation of 64kByte array is not so critical.
But if it is expected, it is possible.

https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...6172c94b

(the difference of 64kByte code and 8kByte code is: 
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/commit/6172c94b )

How do you think about? I feel it is too complicated.

Regards,
mpsuzuki

On 2023/04/18 22:01, Alexei Podtelezhnikov wrote:



The execution "ftdump -c" for OpenType/CFF fonts with "holes" in the
implemented CIDs, like Hiragino fonts on macOS, generates the output
ending with:

--
(...Charmap printout...),2f9de,2f9df,2f9f4

/CIDSystemInfo dictionary
   Registry:Adobe
   Ordering:Japan1
   Supplement:  7

   Implemented CIDs:
 0-20316,21072-21074,21371,21558,21722,21933,22920,23058,23059
--


The execution for real CID-keyed font generates the output ending
with:

--
(font type entries...)
   underline_thickness: 0

/CIDSystemInfo dictionary
   Registry:Adobe
   Ordering:Japan1
   Supplement:  1

   Implemented CIDs:
 0-8359
--

Is this what you expected?


This looks very nice, thanks!

Minor issue in a comment:

   * setup 64k-bytes array to scan all CIDs

should be

   * set up 64kByte array to scan all CIDs


Werner


I like this too. Please commit.

Alexei

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

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:

--
(...Charmap printout...),2f9de,2f9df,2f9f4

/CIDSystemInfo dictionary
   Registry:Adobe
   Ordering:Japan1
   Supplement:  7

   Implemented CIDs:
 0-20316,21072-21074,21371,21558,21722,21933,22920,23058,23059
--


The execution for real CID-keyed font generates the output ending
with:

--
(font type entries...)
   underline_thickness: 0

/CIDSystemInfo dictionary
   Registry:Adobe
   Ordering:Japan1
   Supplement:  1

   Implemented CIDs:
 0-8359
--

Is this what you expected?

Regards,
mpsuzuki


On 2023/04/17 23:07, Alexei Podtelezhnikov wrote:


Here is the 2nd revision,

https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...c0267c89

To dump the ROS info, it needs "-n" option, as it is needed to dump /FontInfo 
dictionary.
For the similarity with /FontInfo dumping, the syntax of the output is changed.

You certainly have a lot more experience with CID-keyed fonts. From my quick 
reading, they do not have CMap, which is provided separately. CIDinfo gives a 
clue which CMap is to be used. Therefore, it seems best to show this under 
Print_Charmaps. You might even consider  verbose (-c) output with added 
FT_Get_CID_From_Glyph_Index output dump.

Alexei

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

Here is the 2nd revision,

https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...c0267c89

To dump the ROS info, it needs "-n" option, as it is needed to dump /FontInfo 
dictionary.
For the similarity with /FontInfo dumping, the syntax of the output is changed.

However, I didn't write a function named as Print_CIDFontInfo_Dictionary() but 
wrote
a function named Print_ROS_From_Face(), because I didn't want to expose the 
variables
to store registry, ordering, and supplement in its caller side, and ROS info 
can be
found in non-CID-keyed font (in theoretically).

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 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, where 
"Adobe" is the registry name (stored as a string), "CNS1" is the ordering (stored as a 
string), and "4" is the supplement level (stored as an integer), like:

/CIDSystemInfo 3 dict dup begin
   /Registry (Adobe)  def
   /Ordering (Japan1) def
   /Supplement 1 def
end def

In my experience, I've never seen a font including a hypen in the strings of 
Registry and Ordering, so there might be few serious requirements to show R/O/S 
separately.

Regards,
mpsuzuki

On 2023/04/16 20:30, Alexei Podtelezhnikov wrote:



ftdump is not a font debugger,
but it would be much more helpful if it can dump the ROS info from
OpenType/CFF.


I actually think that FreeType demos are the best font debugging tools out 
there.


My preliminary patch is
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/commit/aa425196385b6639616b18291c7aa3a6d865a760

Does such a feature in ftdump make sense? I hope to hear your comments.


This is great but please consider other output options. I am not familiar with 
ROS. The CID fonts without charmaps might need this instead. Or is this a name? 
It is a bit strange right after numeric metrics.

Alexei

Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

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, where 
"Adobe" is the registry name (stored as a string), "CNS1" is the ordering (stored as a 
string), and "4" is the supplement level (stored as an integer), like:

/CIDSystemInfo 3 dict dup begin
  /Registry (Adobe)  def
  /Ordering (Japan1) def
  /Supplement 1 def
end def

In my experience, I've never seen a font including a hypen in the strings of 
Registry and Ordering, so there might be few serious requirements to show R/O/S 
separately.

Regards,
mpsuzuki

On 2023/04/16 20:30, Alexei Podtelezhnikov wrote:



ftdump is not a font debugger,
but it would be much more helpful if it can dump the ROS info from
OpenType/CFF.


I actually think that FreeType demos are the best font debugging tools out 
there.


My preliminary patch is
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/commit/aa425196385b6639616b18291c7aa3a6d865a760

Does such a feature in ftdump make sense? I hope to hear your comments.


This is great but please consider other output options. I am not familiar with 
ROS. The CID fonts without charmaps might need this instead. Or is this a name? 
It is a bit strange right after numeric metrics.

Alexei

ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

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
the plain text part at the beginning of the font files. Also, the number
of glyphs is sufficiently informative to guess the ROS of the font file.

Recently I found that the max glyph index in maxp of some OpenType/CFF
is different from any of the defined Adobe specs (maybe their coverages are
subsets of the defined glyph collection). ftdump is not a font debugger,
but it would be much more helpful if it can dump the ROS info from
OpenType/CFF.

My preliminary patch is
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/commit/aa425196385b6639616b18291c7aa3a6d865a760

Does such a feature in ftdump make sense? I hope to hear your comments.

Regards,
mpsuzuki

gitlab CI for macOS, both of "autotool gcc" & "autotool clang" are required?

[suzuki toshiya]

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 invoked as "gcc"), I'm afraid that the current 2 jobs in 
"macos autotool" and "macos autotool clang" have no essential difference. Considering the 
gitlab.freedesktop.org CI jobs for macOS often have long queue in comparison with for Linux or for Windows, should we 
drop one job from these 2?

--

Another idea is an introduction of "autotool gcc" to use real GNU C compiler, 
by installing gcc by homebrew, but there are 2 headaches.

1) the macos instance on gitlab.freedesktop.org has a several manual installations in /usr/local, without the 
help of homebrew. The root privilege is needed to overwrite them, but the homebrew prohibits to be executed as 
root. For detail, please find the log how "brew install gcc" fails at  
https://gitlab.freedesktop.org/mpsuzuki/freetype-mps-wip/-/jobs/31170940#L476 . Therefore, we have to introduce a 
dirty workaround. In my preliminary draft, make homebrew try to install xz, and ignore its return code (failure), 
and gather the list of the files & directories to be overwritten, and execute "sudo chmod ugo+w" to 
the listed files. I feel it is quite ugly (I cannot guarantee the stability of the error message format of 
homebrew, so the stability of the error message parsing technique is quite suspicious), but slightly safer than 
"sudo chmod ugo+w /usr/local/*".


2) homebrew provides a meta-package "gcc", which (might) install the latest version of gcc, but the 
installed gcc command has a version suffix, like, gcc-12, gcc-11, ... Therefore, we have to introduce a dirty 
workaround. In my preliminary draft, after the installation of "gcc", parse the output of the 
command "brew list --version gcc" and obtain the version suffix. As far as their versioning rule is 
gcc-${gcc_major_version_integer}, it would work, I hope.

I filed preliminary patch at: 
https://gitlab.freedesktop.org/mpsuzuki/freetype-mps-wip/-/commit/674246b4d4bd80afa5b0e3dd0079d133248d7bd2
 , but still I'm unsure whether it's worthful to spend the CI resource of 
freedesktop.org.

Regards,
mpsuzuki

P.S.
(*) Please do not ask to use the installation to the non-default directory, 
like, /opt/homebrew or ${HOME}/homebrew etc. As you know, gcc has many 
hardwired directory information, so the installation to the non-default 
directory requires the full build of the gcc itself. Spending much CPU time to 
build gcc before freetype is clearly bad decision. Providing a prebuilt gcc 
binary in the non-default directory independently from homebrew would be 
better, but who would care for the result by such homegrown gcc binary?

Re: [Freetype-devel] Compiling old version (2.6.5) of FreeType

[suzuki toshiya]

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 , 
automake 1.10.1, libtool 2.2.4 and autoconf 2.62. Although I don't have a nice 
crystal ball, I guess your autoconf is too new to handle the files written for 
2.62.

Regards,
mpsuzuki

On 2022/09/01 16:55, Anurag Thakur wrote:

Hello Werner, Alexei

I tried compiling FreeType version 2.6.5 to benchmark it against the current 
`master`, but faced some issues since it is a pretty old version.

I checked out the VER-2-6-5 tag on the repo and ran autogen.sh, which resulted 
in:


generating `configure.ac'
running `aclocal -I . --force'
running `libtoolize --force --copy --install'
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './config.guess'
libtoolize: copying file './config.sub'
libtoolize: copying file './install-sh'
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
running `autoconf --force'
configure.ac:99: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:99: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:99: the top level


Simply running configure and make seemed to work but then there were 
compilation errors in freetype-demos.

I tried checking out a ~2016 commit but couldn't really get it to compile.


Version 2.6.5 is important because the original font-rs post is from 2016, 
which used 2.6.5 as the benchmark for comparison.

The aim is to run FreeType 2.6.5 for benchmarking. Any help regarding this 
would be appreciated.

Regards,
Anurag

Re: Qt5 versions in Ubuntu (Re: [Freetype-devel] Re: compilation of `ftinspect` fails)

[suzuki toshiya]

Sorry, I think for GSoC 2022, it's too late to propose such radical change 
which replaces Qt by EFL.

Also I'm afraid that the number of the volunteers who can maintain the 
softwares dependent with EFL is much smaller than those with Qt.

Regards,
mpsuzuki

On 2022/07/28 15:33, Vincent Torri wrote:

hello

you should have used the EFL toolkit

  * C code
  * no problem with versions
  * separate C logic from UI (with one C code, you can have several UI,
like one for desktop, one for smartphone, etc...)

examples of EFL usage:
https://www.calaos.fr/download/misc/videos/calaos_04.ogv
http://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 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 Charlie, please don't spend much time for them. As Werner comments,
notification "your Qt is too old to build ftinspect" is sufficient goal
for GSoC project.

Regards,
mpsuzuki

On 2022/07/28 14:27, Werner LEMBERG wrote:



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 conditions in CMake and
Meson scripts to the `gsoc-2022-chariri-3` branch (open a new branch
in case you want to still use Qt 5.12 to checkout my progress).


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).


Let me know if the old `gsoc-2022-chariri-2` (containing the 5.12
workaround) is no longer needed.


I don't need it, thanks.


  Werner

Qt5 versions in Ubuntu (Re: [Freetype-devel] Re: compilation of `ftinspect` fails)

[suzuki toshiya]

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 Charlie, please don't spend much time for them. As Werner comments,
notification "your Qt is too old to build ftinspect" is sufficient goal
for GSoC project.

Regards,
mpsuzuki

On 2022/07/28 14:27, Werner LEMBERG wrote:



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 conditions in CMake and
Meson scripts to the `gsoc-2022-chariri-3` branch (open a new branch
in case you want to still use Qt 5.12 to checkout my progress).


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).


Let me know if the old `gsoc-2022-chariri-2` (containing the 5.12
workaround) is no longer needed.


I don't need it, thanks.


 Werner

Re: [Freetype-devel] Did you received this email ? //This is source code of TSIT Improved

[suzuki toshiya]

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 FT_Outline_Embolden() and FT_Outline_Transform() 
to synthesize an embolden glyph and a slanted glyph from existing glyph data. 
What was the insufficient point in these functions for you and motivated you to 
develop your patch?

Regards,
mpsuzuki

On 2022/03/18 11:08, 柳鲲鹏 wrote:

A feedback?

--
发件人：柳鲲鹏 
发送时间：2022年3月14日(星期一) 08:49
收件人：freetype-devel 
抄　送：王斌 
主　题：This is source code of TSIT Improved

Hi, FreeType:
 We are Taishan IT, a Chinese compoany. We are using FreeType and we had 
improved some features:
1, For font italic, now can give and value.
2, For font line, now can be thicker or bolder by weight.
3, New type for font italic. Chinese language has a Top To Bottom text 
direction, and the font italic is top to bottom.

 We hope to meet those code at next version. And we are working hard to 
improve bitmap features. We hope to open source this year.

We has a open source on github :
https://github.com/tsitcn/freetype-taishan-improved

Attach files are:
1, source code improved by tsit.
2, Image for Font italic, chinese font italic mode, and the italic value is 
0.35(default is 0.20).
3, Image for Font line (thicker or bolder).

Best Regards.

Liu Kunpeng(TSIT)

Re: [Freetype-devel] Re: listing the supported file formats

[suzuki toshiya]

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 you're going to load, 
*before* passing it to the FreeType.

My (and maybe Werner's) position is against the step 2. Without invoking the FreeType, or any other 
detailed font driver, it is unreliable to determine whether the font file is really supported by 
the FreeType. I concern (and maybe Werner concerns too) that you may think as "it's very easy, 
because what I would do is strncasecmp() with the suffix of the filename". It is 
misunderstanding. Most traditional fonts for PostScript, and many legacy fonts for macOS do not 
have the suffix, and their contents are not always same (some are only bitmap, some are TrueType, 
some are TrueType format but without outline, some are Type1, some are CFF, etc etc). We cannot 
identify their file formats without passing them to real font driver. Also, how do you distinguish 
which color font format is used in given "xxx.ttf" file? There are at least 3 variants 
(embedded PNG, Microsoft's COLR, and OT-SVG). Also Apple's specification allows more variants.

I'm not against if you write your own wrapper functions to get the human-readable 
"supported font file format", but requesting it in the FreeType API would not 
be welcomed, because it would be an addition of unreliable feature.

However, I can sympathize the feeling "oh, so, should I pass all files to FreeType? 
to find which file is correctly supported? it sounds expensive". If it's the key 
issue, I suggest to consider using fontconfig library, which caches the tested results 
for the files in the specified locations, and you don't have to repeat the checking 
process.

Regards,
mpsuzuki

On 2021/11/22 5:03, Werner LEMBERG wrote:


[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 for `FT_Get_Supported_formats()`
which could return a hashed (removing doubles) string array split by
0s as polled from the modules.

however since this isn't available (and is too late now to consider
without a major revision), the best I could potentially do would be
to poll the available modules and associate local metadata for
everything known about the modules (unless I can do better) at init
time.


It would be possible to add such a function without big difficulties.
However, I don't see any benefit in doing so.


I don't really need to know the modules specific to each format just
the total amount of expected formats specifically that could
potentially be shared between modules.

basically it helps at preventing the processing of garbage data in a
local fonts/ directory ;) (an extra layer of cope for stupidity)


I don't understand why you need that.  FreeType gets continuously
tested by fuzzing engines; it is very robust and can digest (and
correctly reject) non-font files.  IMHO, such an additional layer is
not necessary.


 Werner

Re: [EXTERNAL] Re: Problem with flagging font as 'tricky'

[suzuki toshiya]

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.

https://gitlab.freedesktop.org/freetype/freetype/-/commit/2b3ccd6e266cc74740ee6157b643a0c409c5df64

At present, it skips the heading uppercase 6 letters
with "+" delimiter, this syntax was defined by PDF
Reference.

There might be some poorly designed implementations
using some digits in the randomization tag, like,
"123456+Courier" or "123ABC+Helvetica". Current tweak
does not take them as the randomization tag. If you
have some PDFs including such incorrect randomization
tag, please let me know.

Regards,
mpsuzuki

On 2021/02/13 3:18, Werner LEMBERG wrote:



[Justyna] To be more precise, my case is PDLCJH+OCR-A font.  This is
incremental font build of OCR-A font.


The correct term is not 'incremental font' but 'subsetted font': The
PDF generator takes your input font and omits all glyphs not necessary
in the output file, thus creating a subset of the original font.


FreeType flags it as tricky.


Indeed, this is not good.


[Toshiya] Revisiting the changeset, using "DLC" prefix in the deny
list is slightly too greedy idea to catch all Dynalab fonts, I feel.


I agree.  Additionally, it seems that FreeType finds 'DLC' incorrectly
in the middle of a font name...


 Werner

Re: [Freetype-devel] Re: Drop makefiles for obsolete platforms

[suzuki toshiya]

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 based OS

- BeOS: Discontinued somewhere around 2002

- OS/2: Discontinued in 2001

- Symbian: Discontinued in 2012


They might even be broken but have zero maintenance cost.

Re: [Freetype-devel] Difference in rendering

[suzuki toshiya]

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 produce a small but noticeable difference in rendering. Please share your 
suggestions

thanks
Sarthak Bhardwaj

Re: [Freetype-devel] Re: Develop a test framework for checking FreeType's rendering output - GSoC Project

[suzuki toshiya]

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 extract something from the 
compiler warning messages, most of them are not related with the difference in 
the rasterization results between version X and version Y, although some of 
them can be related with the software vulnerabilities.

The assumed testing framework is basically for the minimization of the regression of the rasterized image, not the "code 
quality" or "secure coding" itself. If the "code quality" or "secure coding" is at the highest 
priority, what we need is more generic inspector, instead of the FreeType-specific framework. The assumed "testing" in 
the GSoC theme is basically the rasterization results.

Regards,
mpsuzuki

On 2021/03/22 4:22, sarthak bhardwaj wrote:

hello werner,
I think I could be explained earlier in detail from my side, sorry for that if 
I am not getting it wrong, In this project( as far I have observed) the 
sequence should be like that -


   *   firstly we need to set up continuous integration services compatible 
with GitLab.
   *   After setting up we need to add compilation and some desired 
functionality tests to our code, along with these services we can use a custom 
test harness(It is a collection of software and test data configured to test a 
program unit by running it under varying conditions and monitoring its behavior 
and outputs. ... Test harnesses allow for the automation of tests.) to check 
for compile errors.


This is my opinion about it, I might be wrong, Please correct me if I have 
misunderstood the thing, and do suggest your opinion about this

Thanks in advance :)
Sarthak Bhardwaj

Re: [Freetype-devel] Information about Code Base

[suzuki toshiya]

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 am excited to explore more about the project idea - 'Add a ‘capability 
database’ to FreeType's auto-hinter'. and contribute to it.

I wish if someone can guide me about where to start or if there is already a 
codebase, where can I find it? Also, Which git repository hosting device 
Freetype uses - Github or GitLab?

Looking forward to your response.
Sincerely By
Anshuman Singh

Re: [Freetype-devel] Regarding Gsoc idea

[suzuki toshiya]

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 Computer Science and Engineering from 
India.I want to contribute in the topic Add a ‘capability database’ to 
FreeType's auto-hinter.
I have understand what the problem demands.
So can you please tell me to where I can find the API and source code for this 
problem?
As I am not getting these.
Please reply soon
Thank you

Re: [EXTERNAL] Re: Problem with flagging font as 'tricky'

[suzuki toshiya]

Ahh... Werner, is it considerable idea for FreeType to add a hardwired 
assumption to recognize the randomization prefix of the fonts embedded in PDF?

Regards,
mpsuzuki

On 2021/02/12 17:31, Justyna Wawrzynska wrote:

Hi Werner,

Thank you for quick response. To be more precise, my case 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: Problem with flagging font as 'tricky'

Dear Werner, Justyna and Roy,

"DLC" was introduced by the request from Mr. Roy Tam,

https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgitlab.freedesktop.org%2Ffreetype%2Ffreetype%2F-%2Fcommit%2F0ed9fef032641c30d0398d98a01b69eca1c15224__%3B!!GXa4NB5MBjHR!GhS45UM8ehm31_wdZY6W6qbgdu5gKwZRk5MJ738vZwccn05k2yyj_H-xn3c1sjyGMskkFKv2UNMC%24data=04%7C01%7Cjustyna.wawrzynska%40bluecrestinc.com%7C7cda724ec08348f84e2b08d8cef26873%7C8310f036fe8d4702a1e0177e9320227c%7C0%7C0%7C637486887837571500%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=gnyl5InB9EGayRRkEtGJHTH3h1GFVohpDlEuqXtULQ8%3Dreserved=0

The assumed font file*s* were dlctt-m7.ttf and dftt-f5.ttf. Revisiting the changeset, using 
"DLC" prefix in the deny list is slightly too greedy idea to catch all Dynalab fonts, I 
feel. Also it could be slightly odd to understand the situation as "2 different fonts produced 
by same company have same family name", because it means that the customer cannot use these 2 
fonts at the same time. Mr. Roy, do you have more detailed info to identify the fonts precisely?

Regards,
mpsuzuki

On 2021/02/12 1:44, Werner LEMBERG wrote:


Hello Justyna,



Before flagging the font as 'tricky' you are checking its name and
comparing it with the trick_names table defined in ttobjs.c file.
This causes that some fonts which aren't tricky are also flagged and
as a result we can't use autohinting on it.


What names are you talking about?


The main problem cause the fonts having prefixes in its names (like
incremental fonts) and "DLC" in the trick_names table.  Is there any
chance to change this method or even change the "DLC" to "DLCMing"
and "DLCFong"?


Certainly.  The more details you give on the font names you are going
to use (or which are already used by you), the finer we can adjust the
filter.


  Werner



This email message may contain confidential, proprietary and/or privileged 
information. It is intended only for the use of the intended recipient(s). If 
you have received it in error, please immediately advise the sender by reply 
email and then delete this message. No one other than the intended recipient 
may disclose, copy, distribute or use the information contained in this message.

Re: Problem with flagging font as 'tricky'

[suzuki toshiya]

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 the deny list is slightly too greedy idea to catch all Dynalab fonts, I 
feel. Also it could be slightly odd to understand the situation as "2 different fonts produced 
by same company have same family name", because it means that the customer cannot use these 2 
fonts at the same time. Mr. Roy, do you have more detailed info to identify the fonts precisely?

Regards,
mpsuzuki

On 2021/02/12 1:44, Werner LEMBERG wrote:


Hello Justyna,



Before flagging the font as 'tricky' you are checking its name and
comparing it with the trick_names table defined in ttobjs.c file.
This causes that some fonts which aren't tricky are also flagged and
as a result we can't use autohinting on it.


What names are you talking about?


The main problem cause the fonts having prefixes in its names (like
incremental fonts) and "DLC" in the trick_names table.  Is there any
chance to change this method or even change the "DLC" to "DLCMing"
and "DLCFong"?


Certainly.  The more details you give on the font names you are going
to use (or which are already used by you), the finer we can adjust the
filter.


 Werner

off-topic: *message not available* in mail archive (Re: [Freetype-devel] Re: GSOC - Distance Fields)

[suzuki toshiya]

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.

Maybe *message not available* is caused by my participation to the
thread. My university uses Microsoft Offic365 email service which
rewrites the message-id during the forwarding. Thus, all emails
I receive via my personal server have non-original message-id.
For example, previous email from Werner in my mailbox has the
message-id:
"352bdea20f334d3a95b38fef4b7a1...@osapr01mb4306.jpnprd01.prod.outlook.com".

Clearly it is different from the original message-id which the
mail-archive server have. When I reply to this mail, the mail-archiver
thinks as "oh, the mail from mpsuzuki refers unknown email message-id,
it could be a private exchanged mail? make an entry stating unavailability".

If anybody had similar problem and resolved by some workaround,
please let me know.

Regards,
mpsuzuki

Re: [Freetype-devel] Re: GSOC - Distance Fields

[suzuki toshiya]

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 already, so it's only a question
> about storage size.

Ah, I think you mean 16bit "platform" are dropped.

>>> 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 you think
>>> about this?
>> If the Distance Fields should be stored as an image (PNG, or
>> something like that), I want to withdraw my shallow idea.  XML and
>> JSON are not the best options to store the image (using dataURL and
>> base64 bitstream? what a stupid idea!), please ignore that.
> 
> What exactly do you mean with 'stored as something like PNG'?  Is this
> the output that FreeType returns to the calling application?  Or is
> this a temporary storage within FreeType?  In both cases I'm not sure
> that this is the best solution, since compression and decompression
> costs a lot of time.

My understanding is that Anuj is planning to store the rasterized-then-
blurred glyph images as the extra TrueType table, aslike sbix table.
I slipped to think about the size of the memory buffer to store these
data. I'm not in full understanding about "how to use that".

>  What 'image' dimensions are we talking about?
> Usually, Freetype glyph bitmaps are very small, and compressing them
> would be a complete waste of time.

Ah, the (assumed/estimated) number of the pixels should be discussed
for first... Anuj, please give us some informations.

Regards,
mpsuzuki

Re: [Freetype-devel] Re: GSOC - Distance Fields

[suzuki toshiya]

Dear Anuj,

Anuj Verma wrote:
> Hello Suzuki,
> 
>> There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit) and FT_Fixed 
>> (16Dot16, 32bit).
> 
> I think using FT_F2Dot14 will be a good option because the signed distance 
> field will have a range [-1.0, 1.0].
> But for now I'll stick with *float* as you suggested.

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).

>> BTW, the most biggest trade-off in your mind is the size
>> of extra table (in TrueType font file) to store Distance
>> Fields info? Or, the speed to calculate the Distance Fields
>> info?
> 
> Usually distance fields are stored as an image (e.g. 
> https://i.imgur.com/ruWAhT3.png<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.imgur.com%2FruWAhT3.png=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274580651=RrQmOFVtQxKnZ1EqlM22%2FKmXaREcx9LZStidy0Tcg%2BE%3D=0>).
> And since each pixel in the distance field is the distance to the nearest 
> edge/outline there
> can be more than 255 values. So, in this case the trade-off can be the 
> accuracy of the distance.
> But, on the other hand, I think 255 values might be enough because they are 
> interpolated if a
> point lies between two.

I see.

> 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 you think about this?

If the Distance Fields should be stored as an image (PNG, or
something like that), I want to withdraw my shallow idea. XML
and JSON are not the best options to store the image (using
dataURL and base64 bitstream? what a stupid idea!), please
ignore that.

There is a possibility that JPEG makes better compression
ratio. But I think using PNG is better choice for FreeType2,
because recent ready-made binaries of FreeType2 on many
GNU/Linux platforms (and on maOS and Windows?) have a
dependency to libPNG already (to support bitmap emoji fonts).
Adding new dependency to libJPEG is not the best.

Regards,
mpsuzuki


Anuj Verma wrote:
> Hello Suzuki,
> 
>> There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit) and FT_Fixed 
>> (16Dot16, 32bit).
> 
> I think using FT_F2Dot14 will be a good option because the signed distance 
> field will have a range [-1.0, 1.0].
> But for now I'll stick with *float* as you suggested.
> 
>> BTW, the most biggest trade-off in your mind is the size
>> of extra table (in TrueType font file) to store Distance
>> Fields info? Or, the speed to calculate the Distance Fields
>> info?
> 
> Usually distance fields are stored as an image (e.g. 
> https://i.imgur.com/ruWAhT3.png<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.imgur.com%2FruWAhT3.png=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274580651=RrQmOFVtQxKnZ1EqlM22%2FKmXaREcx9LZStidy0Tcg%2BE%3D=0>).
> And since each pixel in the distance field is the distance to the nearest 
> edge/outline there
> can be more than 255 values. So, in this case the trade-off can be the 
> accuracy of the distance.
> But, on the other hand, I think 255 values might be enough because they are 
> interpolated if a
> point lies between two.
> 
>> *This is just my idea without deep thinking*, XML or JSON
>> (or, compressed version of them) would be considerable option
>> to store the data, during the development of the initial
>> draft, because it is easy for them to change the data
>> format, insert or remove some extra data. Also it would be
>> easy for external programs to extract or manipulate.
> 
> This is interesting, I haven't thought about storing them as XML or JSON.
> This option can be good if the parsing time is less than the generation time,
> otherwise the external application can directly generate the distance field.
> We can also store them in some format which support floating point (e.g. hdr)
> 
> 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 you think about this?
> 
> Thanks,
> 
> Anuj
> 
> On Wed, May 13, 2020 at 9:03 AM suzuki toshiya 
> mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
> Dear Anuj,
> 
> I think you 

Re: [Freetype-devel] Re: GSOC - Distance Fields

[suzuki toshiya]

Dear Anuj,

I think you can use *float* directly in the initial draft.

When we merge the implementation using the float type into
the official public release, we should discuss the design.

There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit)
and FT_Fixed (16Dot16, 32bit). But yet we don't know which
is the most appropriate for your Distance Fields project,
or we need another type, thus starting with direct usage
of float would be safer to keep the all possibilities.

BTW, the most biggest trade-off in your mind is the size
of extra table (in TrueType font file) to store Distance
Fields info? Or, the speed to calculate the Distance Fields
info?

*This is just my idea without deep thinking*, XML or JSON
(or, compressed version of them) would be considerable option
to store the data, during the development of the initial
draft, because it is easy for them to change the data
format, insert or remove some extra data. Also it would be
easy for external programs to extract or manipulate.

Regards,
mpsuzuki

Anuj Verma wrote:
> Thank you all for the comments.
> 
> I too agree with Werner.
> I think comparing both the types seems to be a good option, So, 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
> 
> 
> On Wed, May 13, 2020 at 5:47 AM suzuki toshiya 
> mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
> 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 with the implementation
> with no floating point, in later.
> 
> Regards,
> mpsuzuki
> 
> On 2020/05/13 6:14, Alexei Podtelezhnikov wrote:
>> I'll just add references below.
>>
>> On Tue, May 12, 2020 at 4:15 PM Werner LEMBERG 
>> mailto:w...@gnu.org>> wrote:
>>>> I can't decide which format to use for storing the SDF(signed
>>>> distance fields).  I think using floating-point values (fixed-point
>>>> in this case) for generation will be more accurate than using
>>>> integer, but then saving the SDF to a file will require a
>>>> conversion.
>> The basic types are described here:
>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.htmldata=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871sdata=%2FVbt%2BfNz6x24eJNK9ag1PDhZXz49rS4b64fcmMJ2G9A%3Dreserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.html=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C9a456680ca6040e37eeb08d7f6dfe807%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249313838205364=QZPY8mNjaJMiznsZrP%2F%2Fx%2FspNjSR7NVrA5Mro4kslrA%3D=0>
>> The computations are described here:
>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.htmldata=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871sdata=T%2BQR9KKVWo%2BEI4Lqr5vFkgguWHV8xm8BB3USWcaQ8iY%3Dreserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.html=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C9a456680ca6040e37eeb08d7f6dfe807%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249313838215316=RB7tz2dCaDs2XpjYZP6tu%2Bt7j%2Fqqn%2B1d7yDYz6dRnb4%3D=0>
>> Saving files is not of FreeType's business. We just return data.
>>
>>> The basic question is whether the accuracy is really needed.
>>> Currently, FreeType doesn't use floating-point arithmetics.
>>> Personally, I would favour a solution without floats, but maybe there
>>> are good reasons for using them.
>>
> 
> 

Re: [Freetype-devel] Re: GSOC - Distance Fields

[suzuki toshiya]

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 with the implementation
with no floating point, in later.

Regards,
mpsuzuki

On 2020/05/13 6:14, Alexei Podtelezhnikov wrote:

I'll just add references below.

On Tue, May 12, 2020 at 4:15 PM Werner LEMBERG  wrote:

I can't decide which format to use for storing the SDF(signed
distance fields).  I think using floating-point values (fixed-point
in this case) for generation will be more accurate than using
integer, but then saving the SDF to a file will require a
conversion.


The basic types are described here:
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.htmldata=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871sdata=%2FVbt%2BfNz6x24eJNK9ag1PDhZXz49rS4b64fcmMJ2G9A%3Dreserved=0
The computations are described here:
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.htmldata=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871sdata=T%2BQR9KKVWo%2BEI4Lqr5vFkgguWHV8xm8BB3USWcaQ8iY%3Dreserved=0
Saving files is not of FreeType's business. We just return data.


The basic question is whether the accuracy is really needed.
Currently, FreeType doesn't use floating-point arithmetics.
Personally, I would favour a solution without floats, but maybe there
are good reasons for using them.

Re: [Freetype-devel] Re: GSOC

[suzuki toshiya]

Dear Anuj,

Oh! I apologize my misunderstanding of the term "timeline".


Sorry for the confusion, I actually wanted to ask about the schedule that I 
have written in my proposal.
For example I have written that by 26th June I will finish the bitmap 
implementation. Although I'm sure
that it won't take more than 26 days but in case it takes more than that or 
less, then is it possible to tweak the schedule?


Yes, please change the schedule in that case. Please inform us if you find some 
difficulties which you need more time for the implementation.

Regards,
mpsuzuki

On 2020/05/06 15:06, ANUJ VERMA wrote:

I was wondering if I could tweak the timeline a little bit? I will follow it as 
much as I can, but just in case I am running late or early.



Please don't mind about the timezone difference, and please keep your best 
timezone.
Both of your mentors (I and Alexei) are living in different timezone,
and even if you could follow my timezone, it does not guarantee the 
minimization of
the delay in the communication (the mentors are not full-time worker for 
FreeType).


Sorry for the confusion, I actually wanted to ask about the schedule that I 
have written in my proposal.
For example I have written that by 26th June I will finish the bitmap 
implementation. Although I'm sure
that it won't take more than 26 days but in case it takes more than that or 
less, then is it possible to tweak the schedule?


Does your computer have sufficient storage to install "Windows Subsystem for 
Linux" ?


I do have linux installed alongside windows (dual boot). But I mostly use Linux 
for testing cross platform applications or writing code specific to Linux.
It's just that I have used Visual Studio since I started programming and I 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 the timeline a little bit? I will follow it as 
much as I can, but just in case I am running late or early.


Please don't mind about the timezone difference, and please keep your best 
timezone.
Both of your mentors (I and Alexei) are living in different timezone,
and even if you could follow my timezone, it does not guarantee the 
minimization of
the delay in the communication (the mentors are not full-time worker for 
FreeType).


I mostly use Visual Studio on Windows 10 for development but if there is 
something else I should use, please let me know so that I can learn that in the 
meantime.


Does your computer have sufficient storage to install "Windows Subsystem for
Linux" ?
There are many FreeType developers working with Unix-like systems, so having an
access
to some GNU/Linux system (no need to stick to WSL. some virtual machine, some
separated
machine etc would work) would be good.

BTW, if your daily development is Visual Studio, how do you build FreeType on
your system?
Do you use existing project file in the source tree? Or, do you use CMake?

Regards,
mpsuzuki

ANUJ VERMA wrote:

Hello Suzuki,

I was wondering if I could tweak the timeline a little bit? I will follow it as 
much as I can, but just in case I am running late or early.
And is there a set of tools I should use. I mostly use Visual Studio on Windows 
10 for development but if there is something 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><mailto:mpsuz...@hiroshima-u.ac.jp<mailto:mpsuz...@hiroshima-u.ac.jp>>>
 wrote:
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 there a separate mailing list for that ?


I guess, other GSoC students might have similar questions in the early phase, so
please let's start here. When our discussion is sufficiently specific to the
distance fields, let's move to somewhere else. But, if you want to have some
non-public e-mail list (and non-public archive?), please let me know. I would
try to find something.

Regards,
mpsuzuki

ANUJ VERMA wrote:

Hello,
Should I call you Suzuki or Sir Suzuki ? Which do you prefer?
Thanks for the quick response.


So the most stable communication for me is still e-mail, or, the issues & 
discussions in github- (or gitlab- etc) systems. What is your favorite?

I don't really have a favorite yet, but I do like e-mail and since we are 
located in different time zones I think e-mail would be the best option.
I have a lot of questions and things to understand about the workflow, so can I 
ask them here only or is there a separate mailing list for that ?

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC

[suzuki toshiya]

Dear Anuj,

> I was wondering if I could tweak the timeline a little bit? I will follow it 
> as much as I can, but just in case I am running late or early.

Please don't mind about the timezone difference, and please keep your best 
timezone.
Both of your mentors (I and Alexei) are living in different timezone,
and even if you could follow my timezone, it does not guarantee the 
minimization of
the delay in the communication (the mentors are not full-time worker for 
FreeType).

> I mostly use Visual Studio on Windows 10 for development but if there is 
> something else I should use, please let me know so that I can learn that in 
> the meantime.

Does your computer have sufficient storage to install "Windows Subsystem for
Linux" ?
There are many FreeType developers working with Unix-like systems, so having an
access
to some GNU/Linux system (no need to stick to WSL. some virtual machine, some
separated
machine etc would work) would be good.

BTW, if your daily development is Visual Studio, how do you build FreeType on
your system?
Do you use existing project file in the source tree? Or, do you use CMake?

Regards,
mpsuzuki

ANUJ VERMA wrote:
> Hello Suzuki,
> 
> I was wondering if I could tweak the timeline a little bit? I will follow it 
> as much as I can, but just in case I am running late or early.
> And is there a set of tools I should use. I mostly use Visual Studio on 
> Windows 10 for development but if there is something 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 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 there a separate mailing list for that ?
> 
> I guess, other GSoC students might have similar questions in the early phase, 
> so
> please let's start here. When our discussion is sufficiently specific to the
> distance fields, let's move to somewhere else. But, if you want to have some
> non-public e-mail list (and non-public archive?), please let me know. I would
> try to find something.
> 
> Regards,
> mpsuzuki
> 
> ANUJ VERMA wrote:
>> Hello,
>> Should I call you Suzuki or Sir Suzuki ? Which do you prefer?
>> Thanks for the quick response.
>>
>>> So the most stable communication for me is still e-mail, or, the issues & 
>>> discussions in github- (or gitlab- etc) systems. What is your favorite?
>> I don't really have a favorite yet, but I do like e-mail and since we are 
>> located in different time zones I think e-mail would be the best option.
>> I have a lot of questions and things to understand about the workflow, so 
>> can I ask them here only or is there a separate mailing list for that ?
>>
>> Thanks,
>> Anuj
>>
>>
> 

Re: [Freetype-devel] Re: GSOC

[suzuki toshiya]

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 there a separate mailing list for that ?

I guess, other GSoC students might have similar questions in the early phase, so
please let's start here. When our discussion is sufficiently specific to the
distance fields, let's move to somewhere else. But, if you want to have some
non-public e-mail list (and non-public archive?), please let me know. I would
try to find something.

Regards,
mpsuzuki

ANUJ VERMA wrote:
> Hello,
> Should I call you Suzuki or Sir Suzuki ? Which do you prefer?
> Thanks for the quick response.
> 
>> So the most stable communication for me is still e-mail, or, the issues & 
>> discussions in github- (or gitlab- etc) systems. What is your favorite?
> 
> I don't really have a favorite yet, but I do like e-mail and since we are 
> located in different time zones I think e-mail would be the best option.
> I have a lot of questions and things to understand about the workflow, so can 
> I ask them here only or is there a separate mailing list for that ?
> 
> Thanks,
> Anuj
> 
> 

Re: [Freetype-devel] Re: GSOC

[suzuki toshiya]

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 
ports for IRC. So the most stable communication for me is still e-mail, or, the 
issues & discussions in github- (or gitlab- etc) systems. What is your favorite?

Regards,
mpsuzuki

On 2020/05/05 11:48, ANUJ VERMA wrote:

Hello all,
I received the mail regarding my GSoC 2020 acceptance today and I'd like to 
thank you all for giving me this opportunity. I also want to thank my mentors 
Suzuki Toshiya and  Alexei Podtelezhnikov. I am really excited to work with you 
all and integrate distance fields to freetype.
I also have the same question as Greg regarding an IRC or Discord channel or 
any other way in which you communicate.

Again, Thank you very much for letting me be a part of the organization.

Anuj

Re: [Freetype-devel] Re: Build system considerations

[suzuki toshiya]

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 of character encoding, script
and language. Although I sympathize with the circular dependency
problem, it would not be good idea to cloning them into FreeType
source code, because of the different time-frames between FreeType
and Unicode related features of harfbuzz (or Unicode itself).

Some meta-building system would be the easiest way to avoid the
manual and repeated building of FreeType and harfbuzz, aslike some
GNU toolchains (binutils + gcc + gdb) ?

Regards,
mpsuzuki

P.S.
But, I'm interested in the decision under a situation: if harfbuzz
requires libstdc++, should we care the dependency of FreeType?


Vincent Torri wrote:
> On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG  wrote:
>>
>>> currently, to have harfbuzz support, freetype must be compiled
>>> without hb support, then build hb with freetype support, then
>>> freetype with hb.
>>>
>>> it would be nice to remove this circular dependency
>> AFAIK, this would only be possible by splitting either HarfBuzz or
>> FreeType into two packages, and this won't happen.
> 
> or moving/coying some functions from freetype to hb, or conversely  ?
> 
> Vincent Torri
> 
> 

Re: [Freetype-devel] Re: Build system considerations

[suzuki toshiya]

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 the shared and static libraries.

I feel similar impression with GN and Ninja combination,
from my small experience to build Chromium and Skia.

Is there any recommended alternative? Or, should we accept
the "modern" situation where we have to execute twice to build
shared and static libraries?

Regards,
mpsuzuki

P.S.
Welcome back Turner! I'm very happy to hear from you again!!



Alexei Podtelezhnikov wrote:
> On Wed, Apr 29, 2020 at 8:34 PM David Turner  wrote:
>> Starting a thread here to discuss potential build system improvements for 
>> FreeType.
>>
>> The current FreeType 2 build system has many flaws. To its credit, it was 
>> designed in a very different time, when things like CMake / Meson / Ninja/ 
>> Maven / GN / Bazel didn't even exist, when Autotools was considered the best 
>> system to configure your build (ah!), and GNU Make 3.81 was considered new 
>> and bleeding edge, and didn't necessarily exist for all platforms. I'm not 
>> even sure pkg-config was available on all Linux distros until quite a long 
>> time. As I said ... very different times.
> 
> Most serious projects I have encountered so far use ./configure; make.
> It is the libtool that annoys me. They refused to implement
> -fvisibiity=hidden  when I asked. They said that libtool was current
> when building shared libraries was hard, which is actually true. Let's
> just get rid of libtool as whatever it does for us is quite minimal.
> 
> Alexei
> 
> 

Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

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 graphic backends, `cairo' and `qt', so it would be 
> interesting to look at how they calculate the bounding box. From a quick 
> look, it looks like they use some recursive mechanism to calculate the 
> bounding box of each element and then expanding it with every iteration until 
> the final bounding box is calculated.

Yes, yes, it is good starting point for the implementers.

If we focus to the simple SVG consists from path objects (path, polygon,
polyline, ellipse, rectangle etc etc), the task is already completed. It would
not be so difficult in SVG Native Viewer, I hope.

But, if we want the renderer to calculate the bitmap_left of attached SVG as
448, instead of 0, finding a boundingbox without real drawing becomes difficult
task. If we deal a SVG including the raster image with alpha channel (and if we
hope as the transparent pixel in embedded image should be dealt as un-inked), it
would become more harder.

I confirmed that resvg_get_image_bbox() evaluates bitmap_left of the attached
SVG as 0 (the returned bbox is 1024 x 1024, instead of 64 x 64).
And, I confirmed that even cairo_recording_surface_ink_extents() evaluates the
bitmap_left as 0, either! Sigh.

Regards,
mpsuzuki

P.S.
I attached a program I used for the confirmation (it's a modified version of
resvg's example.c, to avoid GTK+).
#include 
#include 
#include 
#include 

static resvg_render_tree *tree = NULL;
static resvg_options opt;

void
draw_cb (const char *path)
{
if (!tree || !path)
return;

cairo_rectangle_t docExtents = { 0, 0, 0, 0 };
resvg_rect viewBox = resvg_get_image_viewbox(tree);
docExtents.x = viewBox.x;
docExtents.y = viewBox.y;
docExtents.width = viewBox.width;
docExtents.height = viewBox.height;
cairo_surface_t* cairoSurface = cairo_recording_surface_create( CAIRO_CONTENT_COLOR_ALPHA,  );
cairo_t* cr = cairo_create( cairoSurface );

resvg_size svgSize = { viewBox.width, viewBox.height };
resvg_cairo_render_to_canvas(tree, , svgSize, cr);
cairo_destroy( cr );

cairo_surface_write_to_png( cairoSurface, path );

double x0, y0, w, h;
cairo_recording_surface_ink_extents( cairoSurface, , , , );
printf("cairo-ink-extent: {%f, %f, %f, %f}\n", x0, y0, w, h);

cairo_surface_destroy( cairoSurface );
}


void
print_bbox()
{
resvg_rect viewBox = resvg_get_image_viewbox(tree);
 
printf("viewBox: {%f, %f, %f, %f}\n", viewBox.x, viewBox.y, viewBox.width, viewBox.height);


resvg_rect boundingBox;
resvg_get_image_bbox(tree, );

printf("boundingBox: {%f, %f, %f, %f}\n", boundingBox.x, boundingBox.y, boundingBox.width, boundingBox.height);
}


void
parse_doc (const char *path)
{
resvg_init_options();
opt.path = path;
opt.font_family = "Liberation Sans";
opt.languages = "en";

int err = resvg_parse_tree_from_file(path, , );
if (err != RESVG_OK) {
fprintf(stderr, "Error id: %i\n", err);
abort();
}
}

int
main(int argc, char **argv)
{
if (argc < 3)
   abort();

parse_doc(argv[1]);
print_bbox();
draw_cb(argv[2]);
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

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 rectangle (x, 
> y, width and height). Once we know this, we can use this `width' and `height' 
> to create a `cairo surface'. Once that is done, we can use `cairo translate' 
> to shift the coordinate system so that the origin is at the top-left corner 
> of this rectangle. This will ensure that we only get a tight box rendered 
> with no redundant space. Now, we can use the `x' and `y' of this bounding box 
> to calculate `bitmap_left' and `bitmap_top'. The x can directly tell us 
> `bitmap_left' and similarly `bitmap_top' won't be much hard to calculate, 
> just simple arithmetic.

Ummm. At present, I cannot find anything corresponding to
cairo_recording_surface_ink_extents(), in Qt and Skia. I remember SkPath has
something similar for a path object, but I cannot find in QPainter or SkCanvas.
So, if there is serious requirement to calculate bitmap_left and bitmap_top and
remove the surrounding un-inked pixels from the image in the buffer, such pixel
data manipulation is recommended to be done in the side of FT X-(. Nothing to
say, expanded pixel data must be stored in the side of FT, so what we should
consider is: a) scanning the pixel data is too heavy work for the font
rasterizer? b) cropping the inked part from a rasterized data and copy to
another heap is too heavy work for the font rasterizer?.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

>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 look into how CFF glyphs behave, I am unaware of that at the moment. 
>> But if CFF glyphs also keep the positioning information in 
>> `slot->bitmap.buffer' by putting in empty pixels, then that is a possibility 
>> too.
> 
> It's not so hard for CFF or TrueType rasterizers to calculate bitmap_left and 
> bitmap_top, because these rasterizers operate with the pixel data to be 
> filled, directly.
> 
> But I'm questionable whether we can expect all scalable graphic frameworks 
> should have such feature. If we are focused to the path objects, it would be 
> easy, but considering about the clipping feature, I feel it's complicated 
> works.
> 
> Just I've checked Cairo, and I found cairo_recording_surface_ink_extents() to 
> get x0, y0, width, height of boundingbox of inked area. It would be 
> definitely useful. I would check Skia, CoreGraphics and Qt. If all of them 
> 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 
>>> 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 SVG-OT.
>>>
>>> Imagine we are using FreeType to render an apostrophe ` ' ` using a TTF 
>>> font like `lucida'. What FreeType would do in this case is return a very 
>>> small bitmap in `slot->bitmap.buffer' containing very little pixel data and 
>>> it will also give us `bitmap_left' and `bitmap_top' which will tell us how 
>>> to position the newly returned pixel data in a drawing context. In case of 
>>> an apostrophe it is supposed to be pulled up. In case of a comma ` , ` it 
>>> will be pulled down. I THINK this information is given by `bitmap_left' and 
>>> `bitmap_top'. Correct me please if I have got this concept wrong. Assuming 
>>> I have got this correct, I can reach the conclusion that FreeType renders a 
>>> glyph in the tightest bounding box possible (with no redundant white space) 
>>> and gives the positioning information using `bitmap_left' and `bitmap_top'.
>>
>> Thank you for detailed explanation. My understanding is exactly same.
>>
>>> If the above conclusion is correct, let me now discuss how SVG glyphs are 
>>> placed. I am attaching the a rendered SVG document for the apostrophe 
>>> character. In this image, the bottom left corner is (0, 0) of the SVG 
>>> coordinate system, bottom right corner is (1000, 0), and top left is (0, 
>>> -1000). According to the specs the base line is at y = 0. The information 
>>> about where to place this glyph is already encapsulated in the document.
>>
>> OK.
>>
>>> If we want to make FreeType behave with SVG glyphs in exactly the same way 
>>> that it behaves with TTF scalable glyphs, we must render only the tightest 
>>> bounding box around the glyph (with no redundant white space), and provide 
>>> `bitmap_left' and `bitmap_top' separately to our clients (the program that 
>>> is using FreeType for rendering SVG glyphs). To do this, firstly we need a 
>>> glyph rendered in the tightest box.
>>
>> Mmm, please let me ask a question. It is true that there are many un-inked 
>> pixel around apostrophe glyph. But, do we need to exclude surrounding 
>> un-inkeds pixel when we put some SVG glyph into slot->bitmap.buffer? If we 
>> pass an image with surrounding un-inked pixels to slot->bitmap.buffer, what 
>> kind of the troubles would happen?
>>
>>> This is possible only if you know the bounding box in SVG coordinates, 
>>> (`resvg` just added a function that tells this) and then you can do `cairo` 
>>> translation transformation to exactly get the useful pixel data and nothing 
>>> else. With the bounding box information (its x, y, width and height) you 
>>> can also calculate the `bitmap_left' and `bitmap_top' needed.
>>
>> I understand. Because you think as we should remove the surrounding un-inked 
>> pixels before passing a glyph image to slot->bitmap.buffer, you want to 
>> obtain bitmap_left and bitmap_top, to picku

Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

Oh, I should add a few more.

> I'll look into how CFF glyphs behave, I am unaware of that at the moment. But 
> if CFF glyphs also keep the positioning information in `slot->bitmap.buffer' 
> by putting in empty pixels, then that is a possibility too.

It's not so hard for CFF or TrueType rasterizers to calculate bitmap_left and 
bitmap_top, because these rasterizers operate with the pixel data to be filled, 
directly.

But I'm questionable whether we can expect all scalable graphic frameworks 
should have such feature. If we are focused to the path objects, it would be 
easy, but considering about the clipping feature, I feel it's complicated works.

Just I've checked Cairo, and I found cairo_recording_surface_ink_extents() to 
get x0, y0, width, height of boundingbox of inked area. It would be definitely 
useful. I would check Skia, CoreGraphics and Qt. If all of them 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 
>> 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 SVG-OT.
>>
>> Imagine we are using FreeType to render an apostrophe ` ' ` using a TTF font 
>> like `lucida'. What FreeType would do in this case is return a very small 
>> bitmap in `slot->bitmap.buffer' containing very little pixel data and it 
>> will also give us `bitmap_left' and `bitmap_top' which will tell us how to 
>> position the newly returned pixel data in a drawing context. In case of an 
>> apostrophe it is supposed to be pulled up. In case of a comma ` , ` it will 
>> be pulled down. I THINK this information is given by `bitmap_left' and 
>> `bitmap_top'. Correct me please if I have got this concept wrong. Assuming I 
>> have got this correct, I can reach the conclusion that FreeType renders a 
>> glyph in the tightest bounding box possible (with no redundant white space) 
>> and gives the positioning information using `bitmap_left' and `bitmap_top'.
> 
> Thank you for detailed explanation. My understanding is exactly same.
> 
>> If the above conclusion is correct, let me now discuss how SVG glyphs are 
>> placed. I am attaching the a rendered SVG document for the apostrophe 
>> character. In this image, the bottom left corner is (0, 0) of the SVG 
>> coordinate system, bottom right corner is (1000, 0), and top left is (0, 
>> -1000). According to the specs the base line is at y = 0. The information 
>> about where to place this glyph is already encapsulated in the document.
> 
> OK.
> 
>> If we want to make FreeType behave with SVG glyphs in exactly the same way 
>> that it behaves with TTF scalable glyphs, we must render only the tightest 
>> bounding box around the glyph (with no redundant white space), and provide 
>> `bitmap_left' and `bitmap_top' separately to our clients (the program that 
>> is using FreeType for rendering SVG glyphs). To do this, firstly we need a 
>> glyph rendered in the tightest box.
> 
> Mmm, please let me ask a question. It is true that there are many un-inked 
> pixel around apostrophe glyph. But, do we need to exclude surrounding 
> un-inkeds pixel when we put some SVG glyph into slot->bitmap.buffer? If we 
> pass an image with surrounding un-inked pixels to slot->bitmap.buffer, what 
> kind of the troubles would happen?
> 
>> This is possible only if you know the bounding box in SVG coordinates, 
>> (`resvg` just added a function that tells this) and then you can do `cairo` 
>> translation transformation to exactly get the useful pixel data and nothing 
>> else. With the bounding box information (its x, y, width and height) you can 
>> also calculate the `bitmap_left' and `bitmap_top' needed.
> 
> I understand. Because you think as we should remove the surrounding un-inked 
> pixels before passing a glyph image to slot->bitmap.buffer, you want to 
> obtain bitmap_left and bitmap_top, to pickup the inked part of the rasterized 
> result.
> Maybe your concern is "even if having surrounding un-inked pixel does not 
> cause serious problem, it means that the client would receive different 
> metrics information for same glyph ID, depending whether the glyph is 
> TrueType or SVG". Yes, it might be slightly confusing... I should think more 
> about it.
> 
> BTW, how resvg calculate the bitmap_left properties?
> 
> Regards,
> mpsuzuki
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

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 SVG-OT.
> 
> Imagine we are using FreeType to render an apostrophe ` ' ` using a TTF font 
> like `lucida'. What FreeType would do in this case is return a very small 
> bitmap in `slot->bitmap.buffer' containing very little pixel data and it will 
> also give us `bitmap_left' and `bitmap_top' which will tell us how to 
> position the newly returned pixel data in a drawing context. In case of an 
> apostrophe it is supposed to be pulled up. In case of a comma ` , ` it will 
> be pulled down. I THINK this information is given by `bitmap_left' and 
> `bitmap_top'. Correct me please if I have got this concept wrong. Assuming I 
> have got this correct, I can reach the conclusion that FreeType renders a 
> glyph in the tightest bounding box possible (with no redundant white space) 
> and gives the positioning information using `bitmap_left' and `bitmap_top'.

Thank you for detailed explanation. My understanding is exactly same.

> If the above conclusion is correct, let me now discuss how SVG glyphs are 
> placed. I am attaching the a rendered SVG document for the apostrophe 
> character. In this image, the bottom left corner is (0, 0) of the SVG 
> coordinate system, bottom right corner is (1000, 0), and top left is (0, 
> -1000). According to the specs the base line is at y = 0. The information 
> about where to place this glyph is already encapsulated in the document.

OK.

> If we want to make FreeType behave with SVG glyphs in exactly the same way 
> that it behaves with TTF scalable glyphs, we must render only the tightest 
> bounding box around the glyph (with no redundant white space), and provide 
> `bitmap_left' and `bitmap_top' separately to our clients (the program that is 
> using FreeType for rendering SVG glyphs). To do this, firstly we need a glyph 
> rendered in the tightest box.

Mmm, please let me ask a question. It is true that there are many un-inked 
pixel around apostrophe glyph. But, do we need to exclude surrounding un-inkeds 
pixel when we put some SVG glyph into slot->bitmap.buffer? If we pass an image 
with surrounding un-inked pixels to slot->bitmap.buffer, what kind of the 
troubles would happen?

> This is possible only if you know the bounding box in SVG coordinates, 
> (`resvg` just added a function that tells this) and then you can do `cairo` 
> translation transformation to exactly get the useful pixel data and nothing 
> else. With the bounding box information (its x, y, width and height) you can 
> also calculate the `bitmap_left' and `bitmap_top' needed.

I understand. Because you think as we should remove the surrounding un-inked 
pixels before passing a glyph image to slot->bitmap.buffer, you want to obtain 
bitmap_left and bitmap_top, to pickup the inked part of the rasterized result.
Maybe your concern is "even if having surrounding un-inked pixel does not cause 
serious problem, it means that the client would receive different metrics 
information for same glyph ID, depending whether the glyph is TrueType or SVG". 
Yes, it might be slightly confusing... I should think more about it.

BTW, how resvg calculate the bitmap_left properties?

Regards,
mpsuzuki



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

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 Viewer have the APIs to retrieve the width
and height, SVGDocument::Width() and SVGDocument::Height()

https://github.com/adobe/svg-native-viewer/blob/master/svgnative/src/SVGDocument.cpp

See line 75 and 77, they are taken from the viewbox. But no API for bitmap_left
and bitmap_top. I want to know how they are required for SVG-OT.

For conventional sbit font, recording the bitmap_left, bitmap_top as numerical
parameters is good idea to the non-inked pixels around the glyph bitmap (in EBDT
spec, the glyph bitmaps are stored with their metrics data). The font rasterizer
should reflect the bearing information to obtain the correctly rasterized 
bitmap.

According to the spec saying "the SVG origin (0,0) is aligned with the origin in
the TrueType/CFF design grid; and y = 0 is the default horizontal baseline used
for text layout" and "As with CFF glyphs, no explicit glyph bounding boxes are
recorded", I guess, the rasterized image is expected to be placed as if bearingX
bearingY are zero. Yet I've not experienced by myself, using bitmap_left = 0 &&
bitmap_top = 0 cause some inappropriate result?

About the possibility of the calculation of bounding box (spec says "The ink
bounding box of the rendered SVG glyph should be used if a bounding box is
desired; this box may be different for animated versus static renderings of the
glyph."), I'm not so much positive to do it within SVG Native Viewer.

Let's think about a case: we set 1024 x 1024 image, and put on a circle with
radius 128, at the center of the square image, and use it to clip a small circle
from the square image. After the rasterization, there would be 448 white space
at the left side of the circle, it looks like as if bearingX is 448. But it
would not be so easy for the SVG renderer to calculate this length
mathematically. If I'm forced to do that, I would suggest to find inked pixel
after the rasterization.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC: OT-SVG Support to FreeType: Report week 1

[suzuki toshiya]

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 understanding of your code.

* please include your name into ttsvg.c and ttsvg.h, they are new files created 
by you :-)

now I'm reading the part you wrote as broke...

Regards,
mpsuzuki

On 2019/06/11 18:15, Moazin Khatri wrote:
> Hi Werner and Toshiya,
> 
> You can find the report for the work done so far here:
> 
> https://hackmd.io/@xAHoMwB3QOSJR5L2HGzXGg/r19-sChRN
> 
> I hope it is understandable. It was hard for me to judge the length and depth 
> this weekly report should have been written with. So let me know about that 
> and I will take that into consideration for the next one.
> 
> Please read at your convenience and  let me know of your thoughts! :)
> 
> -Moazin
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] An analysis of Librsvg

[suzuki toshiya]

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 location of the SVG document parser, it seems
>> that the parsing of SVG is helped by XML parsed in
>> src/lib/eina/eina_simple_xml_parser.c
> 
> yes, it's a simple SAX-like parser

I see!!

>> * output: efl_gfx
>> If I can spot the location of the SVG document parser, the
>> rendering of parsed SVG is done by _efl_gfx_path_XXX() in
>> src/lib/efl/interfaces/efl_gfx_path.c
>>
>> There is a comment "code adapted from enesim which was adapted
>> from moonlight sources". Are they based on FreeType2?
> 
> here I have to ask. I'm not involved in the development of that part.
> I'll ask the maintainers

Thank you for taking care! My impression is, Enlightenment has their
own graphic framework which is very rich-featured, and, I'm wondering
whether we can extract the minimum part to have something like "svg2png".

At present, most SVG renderers are using Cairo, Skia, Qt or other
rich graphic framework. If we are focused to the simple raster
output instead of scalable graphic devices, there is a possibility
to reduce the codesize - maybe Cairo + pixmap could be already too
much. However, I don't think this is exciting item for most people,
and nobody is trying to write such.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] An analysis of Librsvg

[suzuki toshiya]

Dear Vincent,

> Enligthenment, and more precisely the EFL (the libraries)

Thanks. Please let me confirm a few points.

* the supported elements
In my understanding, the parser of SVG document is implemented
in src/modules/evas/vg_loaders/svg/evas_vg_load_svg.c
(
https://github.com/Enlightenment/efl/blob/master/src/modules/evas/vg_loaders/svg/evas_vg_load_svg.c
),

I think the elements supported by this loader are defined by
TAG_DEF macro, thus, , , , , ,
, , , and, , , , 
are supported. Am I understanding correctly?

* input: xml support
If I can spot the location of the SVG document parser, it seems
that the parsing of SVG is helped by XML parsed in
src/lib/eina/eina_simple_xml_parser.c
(
https://github.com/Enlightenment/efl/blob/master/src/lib/eina/eina_simple_xml_parser.c
)

* output: efl_gfx
If I can spot the location of the SVG document parser, the
rendering of parsed SVG is done by _efl_gfx_path_XXX() in
src/lib/efl/interfaces/efl_gfx_path.c
(
https://github.com/Enlightenment/efl/blob/master/src/lib/efl/interfaces/efl_gfx_path.c
)

There is a comment "code adapted from enesim which was adapted
from moonlight sources". Are they based on FreeType2?

If I'm asked 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 suzuki toshiya
>  wrote:
>> 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. Thank you for the vote of confidence in FreeType rendering
>>> engine. I am all for adding color, even gradient color, to the engine.
>> Excuse me, I cannot remember about the project Vincent talks about,
>> please let me know what it is. Enlightenment is what you're talking about?
> 
> Enligthenment, and more precisely the EFL (the libraries)
> 
> Vincent Torri
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] An analysis of Librsvg

[suzuki toshiya]

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. Thank you for the vote of confidence in FreeType rendering
engine. I am all for adding color, even gradient color, to the engine.


Excuse me, I cannot remember about the project Vincent talks about,
please let me know what it is. Enlightenment is what you're talking about?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] [FYI] overescaped characters in the document at libexpat.github.io

[suzuki toshiya]

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 PR, there is a link to the website showing manually fixed
HTML contents, but it would be removed when this issue is resolved,
so I don't paste the link to this post. Please do not bookmark it.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Wrote a tiny Python 3 script to extract SVG Documents out of a OT-SVG font

[suzuki toshiya]

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 more document. Your code
explains itself, very well (so, in the educational context, I appreciate your
publishing your own code)

> I know tools like these can be easily found online. I just did it as to get 
> some practice, since I'd be eventually doing this in C inside FreeType when 
> my coding time starts. I'd be happy if this helps anyone! :)

I understand, I have almost same experience. Before macOS font support in
FreeType2, I've implemented in Perl, then in Ruby, and finally in C. Writing a
parse is very helpful to understand the specification. I appreciate your
DIY-like motivation deeply. In fact, there are other font file parsing
libraries, but due to their huge feature set, sometimes it is not easy for the
beginners to read. Reading a small code for simple task (but in generic design)
would be very helpful for the beginners, I believe.

Regards,
mpsuzuki

Moazin Khatri wrote:
> Hi Toshiya,
> 
> However, to proceed to next step, I should prepare some sample SVGs which are 
> precisely fitting to the feature range of SVG Native,
> and which we can understand "correct" rendering result. It seems that 
> svgnative/test files are not precisely
> fitting to the feature range of SVG Native (thus, testSkia result is 
> different from that by rsvg-convert).
> 
> I have written a very small Python 3 script that can read OT files and 
> extract SVG documents out of it.
> 
> You can find it here: 
> https://github.com/moazin/font-file-reader
> 
> I have tried to make it generalized enough so that it can be easily modified 
> to support more tables. For now, the README will tell you the default 
> behavior of the script. It can be modified with a basic knowledge of Python. 
> If you want me to document it or if you have any questions, feel free to ask 
> me, I'd love to help.
> 
> You can extract the glyphs using this script and render them using any tool 
> you want. However, your browser and some other SVG renderers might not render 
> these properly because of the coordinate system inversion.  However, I have 
> found an online editor that can show you the results. You can find it here 
> http://vectorpaint.yaks.co.nz/.
>  You'll need to zoom out to see the glyph (because of coordinate system 
> inversion again).
> 
> You can grab some free SVG based fonts from here:  
> https://www.colorfonts.wtf/
> 
> Note that this is very basic and might not work with all fonts. Also, GZIP 
> encoded SVG documents are not supported at the moment.
> 
> I know tools like these can be easily found online. I just did it as to get 
> some practice, since I'd be eventually doing this in C inside FreeType when 
> my coding time starts. I'd be happy if this helps anyone! :)
> 
> Regards,
> Moazin
> 
> 
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] about github.com/mpsuzuki/svg-native-viewer (Re: I would draft some documents to build SVG Native Viewer...)

[suzuki toshiya]

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.
cairo branch is very frequently rebased to catch up to Adobe.

Within a few weeks, the "master" branch of my repository would be
changed for my own development, for continuous integration test.

I think nobody uses the master branch in my repository to refer
Adobe's original master, but if anybody does such accidentally,
please prepare yourself. Maybe add Adobe's repository as another
remote repository and change the upstream to it would help you.

Sorry for your inconvenience.

Regards,
mpsuzuki

On 2019/05/12 0:05, Moazin Khatri wrote:

Dear Toshiya,
The current status of my document is like this:
https://github.com/mpsuzuki/svg-native-viewer/blob/cairo-cpp11/README.md


Thank you very much Toshiya, most of the steps are exactly what I have tried 
yesterday. I just need to change the branch to chrome/m70. I'll try it and see 
how it goes. I'll also see if I can refine the document anytime soon! :)

Also, maybe by some accident, Skia backend is forcibly disabled
if the platform detected by cmake is not Apple. I tweaked these
issues by this changeset.
https://github.com/mpsuzuki/svg-native-viewer/commit/76cda7dc39a4326f829580b860a854ad23b80b75

Yea, quite right. I made almost 90% of exactly the same changes to make it 
almost work (still the branch needs to be set to m70).

However, it is not sufficiently flexible. I hardwired the location
of libskia.

I think, it's good for now. Once we get it running and decide to use it in our 
project, we will refine it.

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?

Regards,
Moazin




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] The criterion for comparing SVG Rendering libraries

[suzuki toshiya]

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 FT_Renderer with hooks to external library. The SVG 
> support can be enabled/disabled using the renderer modules, say "svg-ot", in 
> modules.cfg.

Behdad wrote:
> EXACTLY.  Also why I think, and said, that all the current energy is going in 
> the wrong direction.

Could you tell me more about "all the current energye is going in the wrong
direction"?
Do you think "spending much energy for the discussion which is not so much
important"?
Or, do you think "trying to implement something in wrong design"?

> Work can already be started implementing the SVG table and 
> FT_GLYPH_FORMAT_SVG and then tested with any of the renderers before being 
> any need to settle on one.

Ah, maybe the implementation of the SVG table parser might be the most stable
part, regardless with which SVG renderer is good, how it is collaborate with
FreeType. It's correct.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] before posting the name of yet another SVG rendering software...

[suzuki toshiya]

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) recommend
it to use the default, or builtin SVG renderer of FreeType. Please clarify
whether you have the infos on, or don't have:

* where we can reach the latest source code under development?

* how about the SVG features covered by the software?
(I mean, the features of SVG-OT is narrower than SVG, but some
people introduced SVG renderer whose feature is smaller than SVG Native)

* the part of SVG rendering is well separated, packaged and distributed?

* the APIs of SVG rendering are well stabilized?

It's not problem at all to post an info quoting a software name with
answers "dunno, dunno, dunno, dunno". You can leave them with other
kind people. But there would be a possibility that FreeType maintainers
& GSoC students cannot have sufficient time to investigate, and give
up to evaluate it,  aslike "apt-cache search libblahblahblah does not
return anything", "the source tree does not have configure script", etc.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Status of Cairo backend for SVG Native Viewer (Re: I would draft some documents to build SVG Native Viewer...)

[suzuki toshiya]

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 CairoScript, PNG, XML and 
SVG are supported). Any crash report is welcomed.

However, to proceed to next step, I should prepare some sample SVGs which are 
precisely fitting to the feature range of SVG Native,
and which we can understand "correct" rendering result. It seems that 
svgnative/test files are not precisely
fitting to the feature range of SVG Native (thus, testSkia result is different 
from that by rsvg-convert).

Especially, masking & clipping features in Cairo backend are not implemented after 
perfect understanding of SVG spec & cairo.

Regards,
mpsuzuki

On 2019/05/12 0:05, Moazin Khatri wrote:

Dear Toshiya,
The current status of my document is like this:
https://github.com/mpsuzuki/svg-native-viewer/blob/cairo-cpp11/README.md


Thank you very much Toshiya, most of the steps are exactly what I have tried 
yesterday. I just need to change the branch to chrome/m70. I'll try it and see 
how it goes. I'll also see if I can refine the document anytime soon! :)

Also, maybe by some accident, Skia backend is forcibly disabled
if the platform detected by cmake is not Apple. I tweaked these
issues by this changeset.
https://github.com/mpsuzuki/svg-native-viewer/commit/76cda7dc39a4326f829580b860a854ad23b80b75

Yea, quite right. I made almost 90% of exactly the same changes to make it 
almost work (still the branch needs to be set to m70).

However, it is not sufficiently flexible. I hardwired the location
of libskia.

I think, it's good for now. Once we get it running and decide to use it in our 
project, we will refine it.

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?

Regards,
Moazin




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] I would draft some documents to build SVG Native Viewer...

[suzuki toshiya]

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 not Apple. I tweaked these
issues by this changeset.

https://github.com/mpsuzuki/svg-native-viewer/commit/76cda7dc39a4326f829580b860a854ad23b80b75

However, it is not sufficiently flexible. I hardwired the location
of libskia.

Regards,
mpsuzuki


On 2019/05/11 21:06, Moazin Khatri wrote:

Hi Toshiya,

Oh, I apologize that I've not finished any documents how
to build & test SVG Native Viewer. I've asked a few questions
to Dirk and got his answers (I'm sure my questions must
be almost same with you), but not summarized the information
as a step-by-step guide for others.

At first I was trying to compile Skia's master branch, which I successfully 
did. After that I tried compiling SVG Native Viewer. First of all, there were 
configuration issues due to which the variable `USE_SKIA` wasn't being set to 
True on my Linux. After fixing that, there were many issues regarding header 
files not being found. Those were because of the latest changes in Skia. I 
fixed those too. The final issues were in the compilation of Skia based 
rendering port. Which was due to `SkShader` class getting changed. It turns out 
that SVG Native Viewer can directly work with up to `chrome/m40` branch of 
Skia. So the next thing I have to do is get the `chrome/m40` branch compiled. I 
was thinking about asking Dirk but thankfully, you just told me that you 
already have. Since I have figured out the most parts, I think a rough guide 
will work for me too.  So if you could just write a few lines describing an 
overview, that'll most likely work for me.

I'm sorry for that my
laziness made you spend your times.

Oh it's totally fine. It taught me a lot. :D

# however, yet I have no experience to build it on Windows.
# only Linux and macOS...

I am on Linux. So no problem. Ubuntu to be specific.

When I finish drafting of first revision, I hope you can
review it and find some overlooked pitholes.

For sure, I would love to!

Regards,

Moazin




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] I would draft some documents to build SVG Native Viewer...

[suzuki toshiya]

Dear Moazin,

On 2019/05/11 20:05, Moazin Khatri wrote:

First of all sorry for responding a bit late. I have been trying to get SVG 
Native Viewer compiled and running with its Skia port. Turns out, Skia made 
some significant changes to their codebase recently and SVG Native Viewer 
hasn't been updated to take care of those changes. I didn't know this earlier 
and spent something like 8 hours trying to get it it to compile.


Oh, I apologize that I've not finished any documents how
to build & test SVG Native Viewer. I've asked a few questions
to Dirk and got his answers (I'm sure my questions must
be almost same with you), but not summarized the informations
as a step-by-step guide for others. I'm sorry for that my
laziness made you spend your times.

# however, yet I have no experience to build it on Windows.
# only Linux and macOS...

When I finish drafting of first revision, I hope you can
review it and find some overlooked pitholes.

Regards,
mpsuzuki



You don't need to apologize, Toshiya. I am really grateful that you're trying 
to explain it to me.

Yes, you just cleared the whole thing to me now. I understand "staying" and 
"non-staying" 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 10, 2019 at 9:30 PM suzuki toshiya 
mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
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 callbacks 
in languages like C. Your explanation made it even more clear.
  >
  >> The collaboration by callback functions is: When FreeType finds SVG-OT, and
  >> requested glyph is available as SVG, FreeType tries to extract SVG data 
from the
  >> font file (this could be done within FreeType). In next, FreeType tries to
  >> invoke the callback function to pass the extracted SVG data. The callback
  >> function should render the SVG data, and return the rendered result to 
FreeType.
  >> If external renderer returns PNG image data, FreeType can take the rendered
  >> result as if it were PNG image data loaded from sbix table. Yet I've not 
decided
  >> about the cache subsystem.
  >
  > I think I understood this part pretty well. Basically, FreeType will be passed in some 
structure with function pointers. It'll rely on these functions for rendering SVGs. However, the 
internal logic won't really care where these functions come from. It'll only expect the functions 
to conform to an interface. Each renderer, let's give it the name 'SVG Rendering Module" for 
now, will have it's own structure that can be passed in. FreeType won't really care which one it 
is. Thus, we can swap "SVG Rendering Modules" whenever we want to without making any 
changes in the internal logic of FreeType. I guess this is something in principle very similar to 
Dependency
Inversion<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDependency_inversion_principle=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C22fb6c0b75874555b00f08d6d477ba01%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C636930008017004019=kvUjwp6M8%2Fl0ORlQ%2FjmnUGGC0QXYLbVipU22LqZM3Q8%3D=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDependency_inversion_principle=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C340795f709f34a249fba08d6d6009c16%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C636931695437500792=gn8LmDwXyT5Dp9FwsKKEFYw0f1n%2BGDSmIy8iUroIJpA%3D=0>>.
 I guess I have got most of it correct but please correct me wherever I have got it wrong.
Correct, you've understood me perfectly.

  >>   Maybe, somebody wonders "so, the interface to be decided would be very 
simple,
  >> the required feature would be only giving SVG data and taking PNG data". It
  >> could be too simplified. In my understanding, most of existing 
self-standing SVG
  >> renderer is not designed to be "staying" as something like "SVG renderer
  >> daemon". On the other hand, they might be designed to be initialized in 
every
  >> SVG document. I think SVG renderers in web browsers might be different, but
  >> anyway, in the font driver, the renderer is expected to be "staying". So, 
it is
  >> needed to be the APIs to initialize & destroy the renderer itself.
  >
  > So this part, I have understood some but have missed some too.

I apologize I made you confused.

  > I think 

[ft-devel] wording "stay" / "non-stay" (Re: libsvgtiny (Re: [ft] Three GSoC projects for FreeType))

[suzuki toshiya]

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 callbacks in 
languages like C. Your explanation made it even more clear.
>
>> The collaboration by callback functions is: When FreeType finds SVG-OT, and
>> requested glyph is available as SVG, FreeType tries to extract SVG data from 
the
>> font file (this could be done within FreeType). In next, FreeType tries to
>> invoke the callback function to pass the extracted SVG data. The callback
>> function should render the SVG data, and return the rendered result to 
FreeType.
>> If external renderer returns PNG image data, FreeType can take the rendered
>> result as if it were PNG image data loaded from sbix table. Yet I've not 
decided
>> about the cache subsystem.
>
> I think I understood this part pretty well. Basically, FreeType will be passed in some structure with function pointers. It'll rely on these functions for rendering SVGs. However, the internal logic won't really care where these functions come from. It'll only expect the functions to conform to an interface. Each renderer, let's give it the name 'SVG Rendering Module" for now, will have it's own structure that can be passed in. FreeType won't really care which one it is. Thus, we can swap "SVG Rendering Modules" whenever we want to without making any changes in the internal logic of FreeType. I guess this is something in principle very similar to Dependency 
Inversion. I guess I have got most of it correct but please correct me wherever I have got it wrong.

Correct, you've understood me perfectly.

>>   Maybe, somebody wonders "so, the interface to be decided would be very 
simple,
>> the required feature would be only giving SVG data and taking PNG data". It
>> could be too simplified. In my understanding, most of existing self-standing 
SVG
>> renderer is not designed to be "staying" as something like "SVG renderer
>> daemon". On the other hand, they might be designed to be initialized in every
>> SVG document. I think SVG renderers in web browsers might be different, but
>> anyway, in the font driver, the renderer is expected to be "staying". So, it 
is
>> needed to be the APIs to initialize & destroy the renderer itself.
>
> So this part, I have understood some but have missed some too.

I apologize I made you confused.

> I think I have understood what you meant by "staying" and "not staying". By "not staying" you are referring to a system that is 
stateless. For example, a system that exposes a function you can just call while passing in your "SVG Document" in the form of a "string" say, 
and it'll return a set of pixels back. That will be called "not staying". Since it doesn't stay. On the other hand, a "staying" system will be 
where you're given, say, some structure. You initialize it, maybe pass in some configuration and stuff, the object stays in memory. You can use it to perform 
renderings. Multiple times. Once you're done you can destroy it. This is what you meant by "staying" I guess? Please correct me if I got it wrong..

OK, please let me try explain in another way.

librsvg has 2 ways to obtain raster image from SVG data.

One is: make a RsvgHandle object from SVG data,
and pass it to rsvg_handle_get_pixbuf().

Another is: make a RsvgHandle object from SVG data,
and create a cairo context, pass it to rsvg_handle_render_cairo().

(some people may think the 2nd way must be popular,
because there is a frequent rumor "rsvg renders SVG
by cairo", and rsvg-convert use it too. But if you
check rsvg-cairo.h, you would find using 2nd way out
of librsvg source tree would be warned as "deprecated").

In the 1st way, no data is shared between the rendering
of glyph A and glyph B. In my wording, there is nothing
"staying". The objects are only alive during the rendering.

How about in the 2nd way? Of course, RsvgHandle objects
cannot be shared. But, how about cairo context? To render
glyph A and B, should we create 2 cairo surface, 2
cairo contexts? Maybe it is not so stupid to hope that
we create single cairo surface and 2 cairo contexts,
or, reuse single cairo surface, single cairo context,
by flushing the content in cairo context before (or after)
rendering a glyph.

In this case (single cairo surface), I want to call "cairo
surface is staying" from one rendering to next rendering.

Can we reuse cairo surface or cairo context endlessly?
I'm not sure. For example, if I pass cairo recording
surface, it would record everything - I'm 

Re: [ft-devel] SVG "Native" Re: [ft] Three GSoC projects for FreeType

[suzuki toshiya]

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

[ft-devel] SVG "Native" Re: [ft] Three GSoC projects for FreeType

[suzuki toshiya]

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, I was misunderstanding.
By the blog entry you mentioned, I've understood that
"Native" of "SVG Native" is a term used in mobile device
field, like the contrast between "web/browser/HTML5
application" versus "native application". I was unaware
that. Hmm, so there is a possibility that (some) SVG-OT
fonts require richer features than SVG Native spec...

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] libsvgtiny (Re: [ft] Three GSoC projects for FreeType)

[suzuki toshiya]

 something like "SVG renderer
daemon". On the other hand, they might be designed to be initialized in every
SVG document. I think SVG renderers in web browsers might be different, but
anyway, in the font driver, the renderer is expected to be "staying". So, it is
needed to be the APIs to initialize & destroy the renderer itself.

If my email is unclear, please ask me again. My English is quite poor, there
would be so many rooms to be improved in my explanation.

Regards,
mpsuzuki


Moazin Khatri wrote:
> Dear Toshiya,
> 
> You're quite right that my original proposal for this idea was quite 
> different. The idea was to use some external well known and well tested SVG 
> Renderer to render SVG documents and writing the necessary glue code to make 
> this happen. More of it can be found in the proposal.
> 
> Writing a new renderer myself sounds something very different than my 
> original plan. I am not saying it's not doable at all, but given my lack of 
> expertise in the area of renderers, its hard to say whether I'll be able to 
> complete it within the GSoC period. However, if somebody volunteers to 
> collaborate with me on this during the period of GSoC, I'd very much love to 
> do that. The volunteer could focus more on the new renderer and I could focus 
> on making it work with FreeType. This would also be something quite similar 
> to my original proposal. :-)
> 
> In one of your recent emails in the list you say and I quote:
> At present, I don't suggest to link SVG renderer to libfreetype directly.
> For sbix color font support, libpng is directly linked to libfreetype,
> but I suggest to make libfreetype + SVG renderer collaborate by a callback
> system.
> Can you please clarify what do you mean exactly by collaboration via a 
> callback system? With the little knowledge of Software Architecture that I 
> have, my guess is you're trying to say that instead of making FreeType 
> directly dependent on one particular SVG Renderer, we should instead create 
> an abstraction in between so the users of FreeType can plug in any SVG 
> Renderer they like as long as they make it conform to the interface. This 
> would be similar to how Adobe's SVG Native Viewer 
> <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fsvg-native-viewer=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C3cf33d63de7348c0bd4d08d6d425950c%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C636929655210327541=aiehJTzVcTV%2FB503Qfk5rJfhgTKz%2BKB6JdOt%2FS1b1rs%3D=0>
>   relies on a rendering port to render stuff, and the users can plug in any 
> renderer they like as long as they write the glue code necessary. Which 
> you've also 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 explain if you can. It'd be also great 
if you can point me to any articles, documents, books or videos that explain 
this technique or codebases that implement this type of a "collaboration by 
callback functions" technique.
> 
> Thanks,
> 
> Moazin
> 
> On Thu, May 9, 2019 at 5:54 AM suzuki toshiya 
> mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
> 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 schedule and task
> list in GSoC.
> 
> I welcome if there's any volunteer to work in this direction
> (if Sylvain would do, that's very helpful for Moazin), but
> I don't recommend Moazin to do it.
> 
> Moazin, how do you think about? Alexei, do you think whether
> it could be achieved (as a subside task) within GSoC 2019
> period?
> 
> Regards,
> mpsuzuki
> 
> Alexei Podtelezhnikov wrote:
>> That said, I am wondering if the expressive power of freetype internal vector
>> code could satisfy the requirements of the font svg rendering. Because that
>> would reduce the external dependency to some xml parser, then some internal
>> freetype code would "translate" this font svg directly into internal freetype
>> vector code.
>>
>> FreeType historically was a colorless rasterizer and only returned a pixel 
>> coverage map, which could then be colored and blended by a client 
>> application. As of the last version, FreeType can now add color according to 
>> CPAL/COLR tables, where each layer is blended with a monocolor. To support 
>> SVG, tt is a matter of implementing color gradients, which is not that hard. 
>> Some work needs to be done to implement data structures for complex colors 
>> and properly isolate the blending code into a dedicated blender-rasterizer.
>>
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] libsvgtiny (Re: [ft] Three GSoC projects for FreeType)

[suzuki toshiya]

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 schedule and task
list in GSoC.

I welcome if there's any volunteer to work in this direction
(if Sylvain would do, that's very helpful for Moazin), but
I don't recommend Moazin to do it.

Moazin, how do you think about? Alexei, do you think whether
it could be achieved (as a subside task) within GSoC 2019
period?

Regards,
mpsuzuki

Alexei Podtelezhnikov wrote:
> That said, I am wondering if the expressive power of freetype internal vector
> code could satisfy the requirements of the font svg rendering. Because that
> would reduce the external dependency to some xml parser, then some internal
> freetype code would "translate" this font svg directly into internal freetype
> vector code.
> 
> FreeType historically was a colorless rasterizer and only returned a pixel 
> coverage map, which could then be colored and blended by a client 
> application. As of the last version, FreeType can now add color according to 
> CPAL/COLR tables, where each layer is blended with a monocolor. To support 
> SVG, tt is a matter of implementing color gradients, which is not that hard. 
> Some work needs to be done to implement data structures for complex colors 
> and properly isolate the blending code into a dedicated blender-rasterizer.
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] libsvgtiny (Re: [ft] Three GSoC projects for FreeType)

[suzuki toshiya]

> I am not familiar with libsvgtiny, I know it exists because since I am a
> "noscript/(x)html basic" supporter for the web, I had a look into netsurf.

Good to hear that, thanks! I hope you would have a time to
investigate libsvgtiny. When you reached a conclusion that
linking 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 know the exist of libsvgtiny, I must thank you
>> for giving the information.
> 
> Hi,
> 
> This is why I did jump into the thread, to give that information and suggest 
> it
> may be worth adding what's needed to libsvgtiny to in order to provide a cairo
> based svg renderer for freetype svg font support. I am worried because the 
> only
> other open source lib for svg rendering I know of is librsvg which is
> "exploding" in SDK configuration and complexity space that due to its port to
> rust.
> 
> I am not familiar with libsvgtiny, I know it exists because since I am a
> "noscript/(x)html basic" supporter for the web, I had a look into netsurf.
> 
> That said, I am wondering if the expressive power of freetype internal vector
> code could satisfy the requirements of the font svg rendering. Because that
> would reduce the external dependency to some xml parser, then some internal
> freetype code would "translate" this font svg directly into internal freetype
> vector code.
> 
> regards,
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] libsvgtiny (Re: [ft] Three GSoC projects for FreeType)

[suzuki toshiya]

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 library to use for SVG-OT support in FreeType?
Or, you don't think so (or you're unsure) but just giving the information
to FreeType developers?

If some netsurf users want to have SVG-OT support, it might be considerable
option, but I'm questionable whether libsvgtiny could be a generic solution.

I assume you're familiar with libsvgtiny and its usage in/out of netsurf,
if it's my misunderstanding, please ignore.

Regards,
mpsuzuki

sylvain.bertr...@gmail.com wrote:
> Hi,
> 
> Kind of neither and both.
> 
> 1 - I know of a small svg lib based on cairo, which is used by the netsurf
> browser.
> 2 - in the context of enabling freetype to support svg font rendering, I was
> wondering if this lib was considered? I don't know "how much" it is 
> required
> to add to this svg renderer to make it render a font svg.
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] libsvgtiny (Re: [ft] Three GSoC projects for FreeType)

[suzuki toshiya]

Dear Sylvain,

Excuse me, please let me confirm your intention.
Which is the background of "I cannot answer this question by myself".

a) libsvgtiny should be audited from now, because we (including both
of you and me) have not audited.

b) we (including both of you and me) don't know the required features
of SVG in SVG-OT, so it's not the time to discuss "the image element
is not supported or not", because we should decide "the support of the
image is needed or not" before asking it.

which is your position?

Regards,
mpsuzuki

sylvain.bertr...@gmail.com wrote:
> On Wed, May 08, 2019 at 01:44:39AM +, suzuki toshiya wrote:
>> However, my impression on libsvgtiny is... its range of the features
>> might be narrower than SVG Native: I think it does not support
>> the image elements in SVG. Am I misunderstanding?
> 
> Hi,
> 
> This is for this very reason this lib should be audited as a svg renderer. The
> question of "how much more" this lib needs in order to be able to render
> "reasonably" the "font svg subset", would have to be answered. I cannot answer
> this question myself.
> 
> Their SDK seems still of a reasonable complexity and size... for the moment.
> 
> regards,
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [ft] Three GSoC projects for FreeType

[suzuki toshiya]

Dear Sylvain,

Thank you for the introduction of libsvgtiny in netsurf browser.
I think I've once visited netsurf website, but I was unaware that
it has their own SVG renderer.

Just I've checked the source, and, it's interesting to see that
netsurf has their own DOM support library based on expat.

However, my impression on libsvgtiny is... its range of the features
might be narrower than SVG Native: I think it does not support
the image elements in SVG. Am I misunderstanding?

Regards,
mpsuzuki

sylvain.bertr...@gmail.com wrote:
> On Tue, May 07, 2019 at 07:53:22PM +0500, Moazin Khatri wrote:
>>> I wonder if a re-implementation is a good idea.
> 
> Since it's to get rid of a c++ toolchain dep, it's always a good idea.
> Maintenance will occur naturally if svg based fonts get significant traction.
> The good new is that it seems to be a small subset of svg, specific to font
> rendering.
> 
> For the svg renderer, the tiny svg renderer from the netsurf browser should
> really be really audited: how much to add to get "font svg" rendering (already
> based on cairo).
> 
> regards,
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [ft] Three GSoC projects for FreeType

[suzuki toshiya]

Dear Sylvain,

> Which svg renderer will be used? Which XML parser will be used? Because, that
> could add heavy SDK deps to freetype.

Very very good point, I sympathize you strongly.

At present, I don't suggest to link SVG renderer to libfreetype directly.
For sbix color font support, libpng is directly linked to libfreetype,
but I suggest to make libfreetype + SVG renderer collaborate by a callback
system.

If the users of SVG-OT want to use SVG-OT with the application
which already have their own SVG renderer (aslike web browsers or
other application using WebKit as layout engine), I hope if they
can use existing SVG renderers by a callback system.

> libxml2 is massive and heavy, and we can start to feel the weight of
> expat.

Indeed. I don't suggest to link libxml2 to libfreetype directly,
because it's huge as you say. In my understanding, expat can parse
XML, but the clients have to many things by themselves. I don't
suggest to invent yet another XML parser for FreeType and maintain
as a part of FreeType.

Regards,
mpsuzuki

sylvain.bertr...@gmail.com wrote:
> On Tue, May 07, 2019 at 06:24:41AM +0200, Werner LEMBERG wrote:
>>   (3) Moazin Khatti: Adding support for OpenType SVG Colored Fonts to
>>  FreeType
> 
> Hi,
> 
> Which svg renderer will be used? Which XML parser will be used? Because, that
> could add heavy SDK deps to freetype.
> librsvg is re-implemented in rust, and the only reasonable alternative I know
> is the small and incomplete svg renderer from netsurf browser.
> 
> libxml2 is massive and heavy, and we can start to feel the weight of
> expat.
> 
> Or will be there a font taylored svg renderer? (I guess that would add a dep 
> on
> cairo FT own vector rendering code).
> 
> regards,
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Just committed.
Also I uploaded the tarball of 2b3e0ef6c095cf6ea920e95fc9826dc39694162a ,
http://gyvern.ipc.hiroshima-u.ac.jp/~mpsuzuki/freetype-2.9.1-sunpro.tar.gz

Many thanks to all!

Regards,
mpsuzuki

suzuki toshiya wrote:
> Dear Alexei, Kanazawa-san and Alan,
> 
> Thank you for the info about the versions of SunPro C
> supporting visibility feature.
> 
> Googling "SUNPRO_C 0x550", I found that several widely
> used software, like, Xorg, pixman, glib, ICU are using
> 0x550 as the lowest version to enable visibility feature.
> 
> I think, although yet I have no access to older SunPro
> C, doing same with other widely used software is not so
> bad idea. Please let me use 0x550.
> 
> Soon I will commit my patch. In later, I will tweak
> configure.raw to make CFLAGS and FT_EXPORT() consistent
> always.
> 
> Regards,
> mpsuzuki
> 
> Kiyoshi KANAZAWA wrote:
>> Hello,
>>
>> If this has been introduced to Oracle cc 12.6 (developerstudio12.6),
>> "__SUNPRO_C >= 0x5150" is correct, I guess.
>>
>> % cc -V
>> cc: Studio 12.6 Sun C 5.15 SunOS_i386 2017/05/30
>> % cat print___SUNPRO_C.c
>> #include 
>>
>> void main (void)
>> {
>> printf ("__SUNPRO_C = 0x%x\n", __SUNPRO_C);
>> }
>>
>> % cc print___SUNPRO_C.c
>> % a.out
>> __SUNPRO_C = 0x5150
>>
>>
>> Regards,
>>
>> --- Kiyoshi
>>
>> - Original Message -
>> From: Alexei Podtelezhnikov <apodt...@gmail.com>
>> To: suzuki toshiya <mpsuz...@hiroshima-u.ac.jp>
>> Cc: Alan Coopersmith <alan.coopersm...@oracle.com>; Kiyoshi KANAZAWA 
>> <yoi_no_myou...@yahoo.co.jp>; "freetype-devel@nongnu.org" 
>> <freetype-devel@nongnu.org>
>> Date: 2018/5/4, Fri 11:04
>> Subject: Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc 
>> on Solaris x64
>>
>> On Thu, May 3, 2018 at 7:50 PM, suzuki toshiya
>> <mpsuz...@hiroshima-u.ac.jp<mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
>>> I guess, latest Oracle cc may accept both of __global and
>>> __attribute__((visibility)) styles, and both of --xldscope and
>>> -fvisibility= styles.
>> This has only been introduced to Oracle cc 12.6 in 2017.
>> https://docs.oracle.com/cd/E77782_01/html/E77784/gncki.html
>>
>>> If so, there's any preference? If the style like GCC was
>>> introduced in later (for the compatibility with GCC), using
>>> GCC-unlike style would be more generic for SunPro C.
>> Please apply your patch with __SUNPRO_C >= 0x550.
>>
>>
>>
> 
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Dear Alexei, Kanazawa-san and Alan,

Thank you for the info about the versions of SunPro C
supporting visibility feature.

Googling "SUNPRO_C 0x550", I found that several widely
used software, like, Xorg, pixman, glib, ICU are using
0x550 as the lowest version to enable visibility feature.

I think, although yet I have no access to older SunPro
C, doing same with other widely used software is not so
bad idea. Please let me use 0x550.

Soon I will commit my patch. In later, I will tweak
configure.raw to make CFLAGS and FT_EXPORT() consistent
always.

Regards,
mpsuzuki

Kiyoshi KANAZAWA wrote:
> Hello,
> 
> If this has been introduced to Oracle cc 12.6 (developerstudio12.6),
> "__SUNPRO_C >= 0x5150" is correct, I guess.
> 
> % cc -V
> cc: Studio 12.6 Sun C 5.15 SunOS_i386 2017/05/30
> % cat print___SUNPRO_C.c
> #include 
> 
> void main (void)
> {
> printf ("__SUNPRO_C = 0x%x\n", __SUNPRO_C);
> }
> 
> % cc print___SUNPRO_C.c
> % a.out
> __SUNPRO_C = 0x5150
> 
> 
> Regards,
> 
> --- Kiyoshi
> 
> - Original Message -
> From: Alexei Podtelezhnikov <apodt...@gmail.com>
> To: suzuki toshiya <mpsuz...@hiroshima-u.ac.jp>
> Cc: Alan Coopersmith <alan.coopersm...@oracle.com>; Kiyoshi KANAZAWA 
> <yoi_no_myou...@yahoo.co.jp>; "freetype-devel@nongnu.org" 
> <freetype-devel@nongnu.org>
> Date: 2018/5/4, Fri 11:04
> Subject: Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc 
> on Solaris x64
> 
> On Thu, May 3, 2018 at 7:50 PM, suzuki toshiya
> <mpsuz...@hiroshima-u.ac.jp<mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
>> I guess, latest Oracle cc may accept both of __global and
>> __attribute__((visibility)) styles, and both of --xldscope and
>> -fvisibility= styles.
> 
> This has only been introduced to Oracle cc 12.6 in 2017.
> https://docs.oracle.com/cd/E77782_01/html/E77784/gncki.html
> 
>> If so, there's any preference? If the style like GCC was
>> introduced in later (for the compatibility with GCC), using
>> GCC-unlike style would be more generic for SunPro C.
> 
> Please apply your patch with __SUNPRO_C >= 0x550.
> 
> 
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Dear Kanazawa-san,

Thanks for confirmation! Maybe I would have to ask for your reconfirmation
after polishing up the patch, after a while. Please keep in touch.

mpsuzuki

Kiyoshi KANAZAWA wrote:
> Dear Suzuki san,
> 
> Your patch solved the problem.
> Tested both with
> - ./configure CC="cc -m64"
> % nm objs/.libs/libfreetype.so.6.16.1 | grep FT_Init_FreeType
> [2394]  |355488|   123|FUNC |GLOB |0|17 |FT_Init_FreeType
> 
> - ./configure CC="cc -m32"
> % nm objs/.libs/libfreetype.so.6.16.1 | grep FT_Init_FreeType
> [2398]  |185536|   148|FUNC |GLOB |0|15 |FT_Init_FreeType
> 
> 
> Best regards,
> 
> --- Kiyoshi
> 
> - Original Message -
> From: suzuki toshiya <mpsuz...@hiroshima-u.ac.jp>
> To: Kiyoshi KANAZAWA <yoi_no_myou...@yahoo.co.jp>
> Cc: freetype-devel <freetype-devel@nongnu.org>
> Date: 2018/5/3, Thu 23:49
> Subject: Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc 
> on Solaris x64
> 
> Maybe
> __attribute__((visibility("__global"))) foo
> is wrong, and
> __global foo
> would be correct. also I guess
> __attribute__((visibility("default"))) foo
> is acceptable for Oracle cc too.
> 
> I uploaded the revised tarball (revised patch is attached).
> No need to try immediately :-)
> 
> suzuki toshiya wrote:
>> Dear Kanazawa-san,
>>
>> Thanks!
>>
>> Kiyoshi KANAZAWA wrote:
>>> Dear Suzuki san,
>>>
>>> Tried to build freetype-2.9.1-sunpro, but failed.
>>> Log files are attached.
>>>
>>> I'm going to bed, now.
>>> See you again, tomorrow.
>>> Regards,
>>>
>>> --- Kiyoshi
>>>
>>>
>>> - Original Message -
>>> From: suzuki toshiya 
>>> <mpsuz...@hiroshima-u.ac.jp<mailto:mpsuz...@hiroshima-u.ac.jp>>
>>> To: Alexei Podtelezhnikov <apodt...@gmail.com<mailto:apodt...@gmail.com>>; 
>>> Kiyoshi KANAZAWA 
>>> <yoi_no_myou...@yahoo.co.jp<mailto:yoi_no_myou...@yahoo.co.jp>>
>>> Cc: freetype-devel 
>>> <freetype-devel@nongnu.org<mailto:freetype-devel@nongnu.org>>
>>> Date: 2018/5/3, Thu 23:09
>>> Subject: Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with 
>>> cc on Solaris x64
>>>
>>> Dear Alexei, Kanazawa-san,
>>>
>>> Here is the patch trying to use visibility options on SunPro.
>>> Also patched tarball is uploaded at:
>>>
>>> http://gyvern.ipc.hiroshima-u.ac.jp/~mpsuzuki/freetype-2.9.1-sunpro.tar.gz
>>>
>>> This is completely untested on SunPro, there might be silly
>>> mistakes, but I hope anybody can try.
>>>
>>> Regards,
>>> mpsuzuki
>>>
>>> suzuki toshiya wrote:
>>>> Alexei Podtelezhnikov wrote:
>>>>>> Thus, attribute visibility is only enabled for GCC >= 4.
>>>>>>
>>>>>> Comparing with configure.raw, I guess you assumed that
>>>>>> -fvisibility is GCC-specific feature?
>>>>> Solaris compiler would natively need -xldscope=hidden and __global
>>>>> attribute, according to
>>>>> http://www.oracle.com/technetwork/server-storage/solaris/symbol-scope-140496.html
>>>> The values of attribute-visibility would be compatible with
>>>> GNU style, according to
>>>> https://docs.oracle.com/cd/E19205-01/821-2496/bjabi/index.html
>>>> please find 2.9.
>>>>
>>>>> -fvisibility is GNU so Solaris had better define __GNUC__. Oh well.
>>>> According to configure.log.xz by Kanazawa-san, Oracle cc
>>>> (pretends to as if it) supports -fvisibility.
>>>> Anyway, I have no objection to write Sun style explicitly.
>>>>
>>>> Regards,
>>>> mpsuzuki
>>>>
>>>>
>>>> ___
>>>> Freetype-devel mailing list
>>>> Freetype-devel@nongnu.org<mailto:Freetype-devel@nongnu.org><mailto:Freetype-devel@nongnu.org<mailto:Freetype-devel@nongnu.org>>
>>>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>>>
>>>
>>
>> ___
>> Freetype-devel mailing list
>> Freetype-devel@nongnu.org<mailto:Freetype-devel@nongnu.org>
>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>
> 
> 
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Dear Alexei,

>> I would consider -D__GNUC__=4  for Solaris too, only if it also
>> supports GNU style assembler and __builtin_clz.

BTW, I'm negative about the idea to add -D__GNUC__=4 to
non-gcc compilers by autotool, cmake, etc.

If we are discussing about the advice for the developers
using non-gnu toolchains and cannot wait the future release
fixing the issue, "please try CFLAGS='-D__GNUC__=4'" is
good.

But, basically, current problem is because of different
switching of visibility control.

In configure, -fvisibility=hidden availability is checked,
on the other hand, in ftconfig.h, __GNUC__ is checked.
It is natural that non-gcc compilers with -fvisibility=hidden
feature fail to compile.

The expected switching would be:

a) check -fvisibility=hidden availability only if
__GNUC__ >= 4.

b) check __attribute__((visibility("default")))__
availability in autoconf (for any compilers) and enable
if it is available, regardless with gcc version.

there are so many gcc-specific features, so making non-gcc
compilers pretend as if it were gcc is too drastic solution.

This is my personal opinion.

Regards,
mpsuzuki


suzuki toshiya wrote:
> Dear Alexei,
> 
> Thanks, I received after revising the patch X-)
> 
> Regards,
> mpsuzuki
> 
> Alexei Podtelezhnikov wrote:
>>> +#elif defined( __SUNPRO_C ) && __SUNPRO_C >= 0x500
>>> +#define FT_EXPORT( x )  __attribute__(( visibility( "__global" ) ))  x
>> Simply,
>> +#define FT_EXPORT( x )  __global  x
>>
>> I would consider -D__GNUC__=4  for Solaris too, only if it also
>> supports GNU style assembler and __builtin_clz.
>>
> 
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Dear Alexei,

Thanks, I received after revising the patch X-)

Regards,
mpsuzuki

Alexei Podtelezhnikov wrote:
>> +#elif defined( __SUNPRO_C ) && __SUNPRO_C >= 0x500
>> +#define FT_EXPORT( x )  __attribute__(( visibility( "__global" ) ))  x
> 
> Simply,
> +#define FT_EXPORT( x )  __global  x
> 
> I would consider -D__GNUC__=4  for Solaris too, only if it also
> supports GNU style assembler and __builtin_clz.
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Maybe
__attribute__((visibility("__global"))) foo
is wrong, and
__global foo
would be correct. also I guess
__attribute__((visibility("default"))) foo
is acceptable for Oracle cc too.

I uploaded the revised tarball (revised patch is attached).
No need to try immediately :-)

suzuki toshiya wrote:
> Dear Kanazawa-san,
> 
> Thanks!
> 
> Kiyoshi KANAZAWA wrote:
>> Dear Suzuki san,
>>
>> Tried to build freetype-2.9.1-sunpro, but failed.
>> Log files are attached.
>>
>> I'm going to bed, now.
>> See you again, tomorrow.
>> Regards,
>>
>> --- Kiyoshi
>>
>>
>> - Original Message -
>> From: suzuki toshiya <mpsuz...@hiroshima-u.ac.jp>
>> To: Alexei Podtelezhnikov <apodt...@gmail.com>; Kiyoshi KANAZAWA 
>> <yoi_no_myou...@yahoo.co.jp>
>> Cc: freetype-devel <freetype-devel@nongnu.org>
>> Date: 2018/5/3, Thu 23:09
>> Subject: Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc 
>> on Solaris x64
>>
>> Dear Alexei, Kanazawa-san,
>>
>> Here is the patch trying to use visibility options on SunPro.
>> Also patched tarball is uploaded at:
>>
>> http://gyvern.ipc.hiroshima-u.ac.jp/~mpsuzuki/freetype-2.9.1-sunpro.tar.gz
>>
>> This is completely untested on SunPro, there might be silly
>> mistakes, but I hope anybody can try.
>>
>> Regards,
>> mpsuzuki
>>
>> suzuki toshiya wrote:
>>> Alexei Podtelezhnikov wrote:
>>>>> Thus, attribute visibility is only enabled for GCC >= 4.
>>>>>
>>>>> Comparing with configure.raw, I guess you assumed that
>>>>> -fvisibility is GCC-specific feature?
>>>> Solaris compiler would natively need -xldscope=hidden and __global
>>>> attribute, according to
>>>> http://www.oracle.com/technetwork/server-storage/solaris/symbol-scope-140496.html
>>> The values of attribute-visibility would be compatible with
>>> GNU style, according to
>>> https://docs.oracle.com/cd/E19205-01/821-2496/bjabi/index.html
>>> please find 2.9.
>>>
>>>> -fvisibility is GNU so Solaris had better define __GNUC__. Oh well.
>>> According to configure.log.xz by Kanazawa-san, Oracle cc
>>> (pretends to as if it) supports -fvisibility.
>>> Anyway, I have no objection to write Sun style explicitly.
>>>
>>> Regards,
>>> mpsuzuki
>>>
>>>
>>> ___
>>> Freetype-devel mailing list
>>> Freetype-devel@nongnu.org<mailto:Freetype-devel@nongnu.org>
>>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>>
>>
>>
> 
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 
diff --git a/builds/unix/configure.raw b/builds/unix/configure.raw
index baab79dc5..8eded34b4 100644
--- a/builds/unix/configure.raw
+++ b/builds/unix/configure.raw
@@ -311,6 +311,14 @@ AC_SUBST([XX_ANSIFLAGS])
 # It is recommended that shared libraries hide symbols except those with
 # explicit __attribute__((visibility("default"))).
 #
+AC_MSG_CHECKING([for -xldscope=hidden compiler flag])
+orig_CFLAGS="${CFLAGS}"
+CFLAGS="${CFLAGS} -xldscope=hidden"
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[])],
+  AC_MSG_RESULT(yes),
+  CFLAGS="${orig_CFLAGS}"
+  AC_MSG_RESULT(no))
+
 AC_MSG_CHECKING([for -fvisibility=hidden compiler flag])
 orig_CFLAGS="${CFLAGS}"
 CFLAGS="${CFLAGS} -fvisibility=hidden"
diff --git a/builds/unix/ftconfig.in b/builds/unix/ftconfig.in
index b9c21da2c..3a8884600 100644
--- a/builds/unix/ftconfig.in
+++ b/builds/unix/ftconfig.in
@@ -493,6 +493,8 @@ FT_BEGIN_HEADER
 #define FT_EXPORT( x )  __declspec( dllexport )  x
 #elif defined( __GNUC__ ) && __GNUC__ >= 4
 #define FT_EXPORT( x )  __attribute__(( visibility( "default" ) ))  x
+#elif defined( __SUNPRO_C ) && __SUNPRO_C >= 0x500
+#define FT_EXPORT( x )  __global  x
 #elif defined( __cplusplus )
 #define FT_EXPORT( x )  extern "C"  x
 #else
diff --git a/builds/vms/ftconfig.h b/builds/vms/ftconfig.h
index 021e2c651..28ca3a727 100644
--- a/builds/vms/ftconfig.h
+++ b/builds/vms/ftconfig.h
@@ -445,6 +445,8 @@ FT_BEGIN_HEADER
 #define FT_EXPORT( x )  __declspec( dllexport )  x
 #elif defined( __GNUC__ ) && __GNUC__ >= 4
 #define FT_EXPORT( x )  __attribute__(( visibility( "default" ) ))  x
+#elif defined( __SU

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Dear Kanazawa-san,

Thanks!

Kiyoshi KANAZAWA wrote:
> Dear Suzuki san,
> 
> Tried to build freetype-2.9.1-sunpro, but failed.
> Log files are attached.
> 
> I'm going to bed, now.
> See you again, tomorrow.
> Regards,
> 
> --- Kiyoshi
> 
> 
> - Original Message -
> From: suzuki toshiya <mpsuz...@hiroshima-u.ac.jp>
> To: Alexei Podtelezhnikov <apodt...@gmail.com>; Kiyoshi KANAZAWA 
> <yoi_no_myou...@yahoo.co.jp>
> Cc: freetype-devel <freetype-devel@nongnu.org>
> Date: 2018/5/3, Thu 23:09
> Subject: Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc 
> on Solaris x64
> 
> Dear Alexei, Kanazawa-san,
> 
> Here is the patch trying to use visibility options on SunPro.
> Also patched tarball is uploaded at:
> 
> http://gyvern.ipc.hiroshima-u.ac.jp/~mpsuzuki/freetype-2.9.1-sunpro.tar.gz
> 
> This is completely untested on SunPro, there might be silly
> mistakes, but I hope anybody can try.
> 
> Regards,
> mpsuzuki
> 
> suzuki toshiya wrote:
>> Alexei Podtelezhnikov wrote:
>>>> Thus, attribute visibility is only enabled for GCC >= 4.
>>>>
>>>> Comparing with configure.raw, I guess you assumed that
>>>> -fvisibility is GCC-specific feature?
>>> Solaris compiler would natively need -xldscope=hidden and __global
>>> attribute, according to
>>> http://www.oracle.com/technetwork/server-storage/solaris/symbol-scope-140496.html
>> The values of attribute-visibility would be compatible with
>> GNU style, according to
>> https://docs.oracle.com/cd/E19205-01/821-2496/bjabi/index.html
>> please find 2.9.
>>
>>> -fvisibility is GNU so Solaris had better define __GNUC__. Oh well.
>> According to configure.log.xz by Kanazawa-san, Oracle cc
>> (pretends to as if it) supports -fvisibility.
>> Anyway, I have no objection to write Sun style explicitly.
>>
>> Regards,
>> mpsuzuki
>>
>>
>> ___
>> Freetype-devel mailing list
>> Freetype-devel@nongnu.org<mailto:Freetype-devel@nongnu.org>
>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>
> 
> 
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Dear Alexei, Kanazawa-san,

Here is the patch trying to use visibility options on SunPro.
Also patched tarball is uploaded at:

http://gyvern.ipc.hiroshima-u.ac.jp/~mpsuzuki/freetype-2.9.1-sunpro.tar.gz

This is completely untested on SunPro, there might be silly
mistakes, but I hope anybody can try.

Regards,
mpsuzuki

suzuki toshiya wrote:
> Alexei Podtelezhnikov wrote:
>>> Thus, attribute visibility is only enabled for GCC >= 4.
>>>
>>> Comparing with configure.raw, I guess you assumed that
>>> -fvisibility is GCC-specific feature?
>> Solaris compiler would natively need -xldscope=hidden and __global
>> attribute, according to
>> http://www.oracle.com/technetwork/server-storage/solaris/symbol-scope-140496.html
> 
> The values of attribute-visibility would be compatible with
> GNU style, according to
> https://docs.oracle.com/cd/E19205-01/821-2496/bjabi/index.html
> please find 2.9.
> 
>> -fvisibility is GNU so Solaris had better define __GNUC__. Oh well.
> 
> According to configure.log.xz by Kanazawa-san, Oracle cc
> (pretends to as if it) supports -fvisibility.
> Anyway, I have no objection to write Sun style explicitly.
> 
> Regards,
> mpsuzuki
> 
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 
diff --git a/builds/unix/configure.raw b/builds/unix/configure.raw
index baab79dc5..8eded34b4 100644
--- a/builds/unix/configure.raw
+++ b/builds/unix/configure.raw
@@ -311,6 +311,14 @@ AC_SUBST([XX_ANSIFLAGS])
 # It is recommended that shared libraries hide symbols except those with
 # explicit __attribute__((visibility("default"))).
 #
+AC_MSG_CHECKING([for -xldscope=hidden compiler flag])
+orig_CFLAGS="${CFLAGS}"
+CFLAGS="${CFLAGS} -xldscope=hidden"
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[])],
+  AC_MSG_RESULT(yes),
+  CFLAGS="${orig_CFLAGS}"
+  AC_MSG_RESULT(no))
+
 AC_MSG_CHECKING([for -fvisibility=hidden compiler flag])
 orig_CFLAGS="${CFLAGS}"
 CFLAGS="${CFLAGS} -fvisibility=hidden"
diff --git a/builds/unix/ftconfig.in b/builds/unix/ftconfig.in
index b9c21da2c..282898d8a 100644
--- a/builds/unix/ftconfig.in
+++ b/builds/unix/ftconfig.in
@@ -493,6 +493,8 @@ FT_BEGIN_HEADER
 #define FT_EXPORT( x )  __declspec( dllexport )  x
 #elif defined( __GNUC__ ) && __GNUC__ >= 4
 #define FT_EXPORT( x )  __attribute__(( visibility( "default" ) ))  x
+#elif defined( __SUNPRO_C ) && __SUNPRO_C >= 0x500
+#define FT_EXPORT( x )  __attribute__(( visibility( "__global" ) ))  x
 #elif defined( __cplusplus )
 #define FT_EXPORT( x )  extern "C"  x
 #else
diff --git a/builds/vms/ftconfig.h b/builds/vms/ftconfig.h
index 021e2c651..2a2fe71a1 100644
--- a/builds/vms/ftconfig.h
+++ b/builds/vms/ftconfig.h
@@ -445,6 +445,8 @@ FT_BEGIN_HEADER
 #define FT_EXPORT( x )  __declspec( dllexport )  x
 #elif defined( __GNUC__ ) && __GNUC__ >= 4
 #define FT_EXPORT( x )  __attribute__(( visibility( "default" ) ))  x
+#elif defined( __SUNPRO_C ) && __SUNPRO_C >= 0x500
+#define FT_EXPORT( x )  __attribute__(( visibility( "__global" ) ))  x
 #elif defined( __cplusplus )
 #define FT_EXPORT( x )  extern "C"  x
 #else
diff --git a/include/freetype/config/ftconfig.h b/include/freetype/config/ftconfig.h
index eedebf408..a3905073c 100644
--- a/include/freetype/config/ftconfig.h
+++ b/include/freetype/config/ftconfig.h
@@ -461,6 +461,8 @@ FT_BEGIN_HEADER
 #define FT_EXPORT( x )  __declspec( dllexport )  x
 #elif defined( __GNUC__ ) && __GNUC__ >= 4
 #define FT_EXPORT( x )  __attribute__(( visibility( "default" ) ))  x
+#elif defined( __SUNPRO_C ) && __SUNPRO_C >= 0x500
+#define FT_EXPORT( x )  __attribute__(( visibility( "__global" ) ))  x
 #elif defined( __cplusplus )
 #define FT_EXPORT( x )  extern "C"  x
 #else
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Dear Kanazawa-san,

No, no :-) I apologize if my question made you confused.

The source of configure script is in shell script syntax
or m4 macro syntax. "#if..." does not work, because autotool
does not use C preprocessor. More complicated tests are
needed (because autoconf lacks an utility macro to test
the predefined C preprocessor macro).

Regards,
mpsuzuki

Kiyoshi KANAZAWA wrote:
> Dear Suzuki san,
> 
> Oh, it is my fault.
> It is has to be
> #if !defined(__SUNPRO_C)
> instead of
> #ifndef __SUNPRO_C
> ?
> 
> Regards,
> 
> --- Kiyoshi
> 
> 
> - Original Message -
> From: suzuki toshiya <mpsuz...@hiroshima-u.ac.jp>
> To: Kiyoshi KANAZAWA <yoi_no_myou...@yahoo.co.jp>
> Cc: "freetype-devel@nongnu.org" <freetype-devel@nongnu.org>
> Date: 2018/5/3, Thu 21:52
> Subject: Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc 
> on Solaris x64
> 
> Dear Kanazawa-san,
> 
> BTW, I want to ask one of my question, just for curious.
> 
> suzuki toshiya wrote:
>>> diff -ur ../freetype-2.9.1.orig/builds/unix/configure.raw 
>>> ./builds/unix/configure.raw
>>> --- ../freetype-2.9.1.orig/builds/unix/configure.raw2018-05-01 
>>> 19:35:09.0 +
>>> +++ ./builds/unix/configure.raw 2018-05-03 17:27:54.383361566 +
>>> @@ -313,7 +313,9 @@
>>>  #
>>>  AC_MSG_CHECKING([for -fvisibility=hidden compiler flag])
>>>  orig_CFLAGS="${CFLAGS}"
>>> +#ifndef __SUNPRO_C
>>>  CFLAGS="${CFLAGS} -fvisibility=hidden"
>>> +#endif
>>>  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[])],
>>>AC_MSG_RESULT(yes),
>>>CFLAGS="${orig_CFLAGS}"
>> Excuse me, these changes for autotools look quite different from the syntax 
>> of
>> autoconf, it looks like C preprocessor. Have you ever resolved similar 
>> problem
>> by such patch for autoconf files?
> 
> Regards,
> mpsuzuki
> 
> 
> 
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Alexei Podtelezhnikov wrote:
>> Thus, attribute visibility is only enabled for GCC >= 4.
>>
>> Comparing with configure.raw, I guess you assumed that
>> -fvisibility is GCC-specific feature?
> 
> Solaris compiler would natively need -xldscope=hidden and __global
> attribute, according to
> http://www.oracle.com/technetwork/server-storage/solaris/symbol-scope-140496.html

The values of attribute-visibility would be compatible with
GNU style, according to
https://docs.oracle.com/cd/E19205-01/821-2496/bjabi/index.html
please find 2.9.

> -fvisibility is GNU so Solaris had better define __GNUC__. Oh well.

According to configure.log.xz by Kanazawa-san, Oracle cc
(pretends to as if it) supports -fvisibility.
Anyway, I have no objection to write Sun style explicitly.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel