Dear Werner,
I'm quite sorry for bothering you - I've drafted a quick update
of gsoc.html to notice FreeType project is absent in GSoC 2024.
https://gitlab.freedesktop.org/freetype/freetype-web/-/merge_requests/14
Please could you check?
Regards,
mpsuzuki
On 2024/02/22 15:37, suzuki toshiya
Dear Akhilesh,
Please find the discussion after Nitish's similar post:
https://lists.nongnu.org/archive/html/freetype-devel/2024-02/msg0.html
Regards,
mpsuzuki
On 2024/02/23 3:00, Akhilesh yadav wrote:
Hello,
I hope this message finds you well. I noticed that Free Type is participating
organisation, with a link to the 2023
projects webpage. Should this perhaps be changed?
Regards,
Brad
On 22/2/24 17:10, suzuki toshiya wrote:
Dear Nitish,
I'm sorry, Werner and me are hard to participate to GSoC 2024.
I've not heard from Alexei whether he can or he will, but I
guess the FreeType
Dear Nitish,
I'm sorry, Werner and me are hard to participate to GSoC 2024.
I've not heard from Alexei whether he can or he will, but I
guess the FreeType project would be unable to have a project
in GSoC 2024.
--
I don't know any existing modern communication channels for
young people, like
4:20, suzuki toshiya wrote:
I would try to let AX_HAVE_QT() macro to find appropriate set:
https://www.gnu.org/software/autoconf-archive/ax_have_qt.html<https://www.gnu.org/software/autoconf-archive/ax_have_qt.html>
In the case of Debian (and Ubuntu), qtchooser might be the unified
interface
.
Regards,
mpsuzuki
On 2023/07/13 16:24, suzuki toshiya wrote:
Thanks, using same macro with ttfautohint would be easier for future
developers, I would use it.
Regards,
mpsuzuki
On 2023/07/13 15:28, Werner LEMBERG wrote:
I would try to let AX_HAVE_QT() macro to find appropriate set:
https://w
Thanks, using same macro with ttfautohint would be easier for future
developers, I would use it.
Regards,
mpsuzuki
On 2023/07/13 15:28, Werner LEMBERG wrote:
I would try to let AX_HAVE_QT() macro to find appropriate set:
https://www.gnu.org/software/autoconf-archive/ax_have_qt.html
An
2023 at 04:04:54 BST, suzuki toshiya
wrote:
Good, I was just trying to update configure.raw to add C++ version check &
pkg-check for Qt5 :-)
Regards,
mpsuzuki
On 2023/07/13 11:30, Hin-Tak Leung wrote:
Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both
to revise my
Good, I was just trying to update configure.raw to add C++ version check &
pkg-check for Qt5 :-)
Regards,
mpsuzuki
On 2023/07/13 11:30, Hin-Tak Leung wrote:
Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both
to revise my makefile-fu, and perhaps as an educational
Dear Hin-Tak,
As one of the contributors of the FreeType and a person
who had once struggled with Skia, I'm very happy to hear
your progress report about the Skia-based backend of OT-SVG
for FreeType.
But I'm slightly questionable whether the subscribers of
MPEG-OTSPEC are enjoying samely.
Hi,
In the conventional workflow, the source tree of the FreeType2 library
has "./configure", but freetype-demos does not have. Just starting
"make" with existing Makefile under "freetype-demos" carries the
configured values from freetype directory. The meson for the ftinspect
wants to confirm
Oops! I'm quite sorry, I will take a look.
Regards,
mpsuzuki
On 2023/07/08 14:51, Werner LEMBERG wrote:
Toshiya-san,
Hin-Tak reports the following:
I set up both freetype2 and ft2-demos for multiple remotes and track
both gnu savannah and gitlab in both. For most parts freetype2 to
stay
Hi Hin-Tak,
Are there any stable distributions of the
prebuilt Skia binary, especially for Linux?
The skia-python package has its own Skia
binary (plus libbz2, libfreetype, libfontconfig,
libpng, and libuuid).
Once, I was involved in developing SVG Native
Viewer, which has the backend to Skia.
Hi,
- Don't call `gcc` directly! You should rather use `$(CC)` (or
probably `$(CCexe)`, I'm not sure right now).
In my understanding, $(CC) can be a cross compiler (e.g. building
Win32 binary on Linux platform), but $(CCexe) is a native compiler
to build "apinames".
The compiler to
Sorry, it's too late. Please consider GSoC 2024 and check the schedule.
Regards,
mpsuzuki
BTW, IIT Advanced (The
https://en.wikipedia.org/wiki/Joint_Entrance_Examination_%E2%80%93_Advanced?)
rank may be difficult for most non-Indian developers to assess whether it is
high or low. Developing
uki
P.S.
Personally I'm interested in the enhancement of t1cid to
accept the "incrementally-defined" CIDFontType0 font file,
which uses /GlyphDirectory and includes no binary section.
But I have to start from making a font data which GS and
genuine PostScript interpreter can accept
Dear Werner,
Ah, I need more time to propose deprecating or removing
the incremental loading feature in the t1cid driver.
But there is room for improvement in this feature's
documentation (or a tutorial). Just I've written to
the ghostscript-devel mailing list and asked whether
GhostScript has
loading feature of t1cid is helpful to render the PostScript
document using the incremental definition of the CIDFontType 0 dictionary.
If anybody knows a practical use case, please let me know.
Regards,
mpsuzuki
On 2023/04/27 21:40, suzuki toshiya wrote:
Hi,
Recently, Alex gave me an idea to
Hi,
Recently, Alex gave me an idea to improve FT_Get_CID_From_Glyph_Index() API for
CID-keyed font Type 0 (FontType 9, the most traditional CID-keyed font using
PostScript Type1 CharStrings) by adding a fallback to CID=0 for the cases that
the requested GID points to a broken entry providing
stream offsets
could not load a glyph for CID=3
cid_load_glyph: invalid glyph stream offsets
issue.
Regards,
mpsuzuki
On 2023/04/21 16:42, suzuki toshiya wrote:
Dear Alexei,
Excuse me; please let me ask your background to scan
all CIDs. Is it a confirmation of the existence of
the glyph
In my opinion, only validated CIDs are interesting. Therefore,
FT_Get_CID_From_Glyph_Index is confusing to me. It looks like it is useful for
CFF only but not for Type 1. It looks like the we need different approaches:
FT_Load for t1cid and FT_Get_CID for CFF.
OK. Yet I've not checked what
2023 at 12:47 AM suzuki toshiya
wrote:
Dear Alexei, Werner,
Here is reworked version, which assumes
"no zig-zag mapping is found by FT_Get_CID_From_Glyph_Index()".
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/commit/453de7aa3f9ccd54824ab3468c5a3b91507a86a9
(
http
os-mps-wip/-/commits/mr-ftdump-print-cid-ros-assume-order
)
Regards,
mpsuzuki
On 2023/04/20 12:46, suzuki toshiya wrote:
Dear Alexei,
Umm, TN#5092 is a document in the world of pure CID-keyed font,
so it does not care about the mapping between the CID and
TrueType (or CFF) GID, so
Dear Alexei,
Umm, TN#5092 is a document in the world of pure CID-keyed font,
so it does not care about the mapping between the CID and
TrueType (or CFF) GID, so I'm unsure if it is a solid footstone
to exclude the unordered CIDs.
For example, "GB1 represents the first version of the ordering
Dear Alex,
I agree that bitshift is too complicated. If the glyphs are sorted by
CID, you might not need the temporary storage if you keep track of the
previous CID and some format string tricks. I can work on that later
by adopting the lines 676-707 (if the CIDs are sorted indeed).
Indeed.
Dear Werner, Alex,
Thank you for positive comment. I fixed my broken comment by Werner's advice.
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...2bf378a1
BTW, if the 64kByte array to check CID availability can be
reduced to a 64kBit (= 8kByte for most
Here is the 3rd revision.
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...228f50f0
The execution "ftdump -c" for OpenType/CFF fonts with "holes" in
the implemented CIDs, like Hiragino fonts on macOS, generates
the output ending with:
cally).
I tested it with both of raw CID-keyed font (like WadaGo-Bold), and
OpenType/CFF.
Regards,
mpsuzuki
On 2023/04/16 22:11, suzuki toshiya wrote:
Thank you very much for positive comment - Indeed, yet I've not considered and
tested with real CID fonts! I should rework.
Showing a string
Thank you very much for positive comment - Indeed, yet I've not considered and
tested with real CID fonts! I should rework.
Showing a string type value after the numerical value might be strange.
In conventional PostScript CID fonts, ROS is usually identified as a string like Adobe-Japan1-4,
Hi all,
FreeType has an API to retrieve the CID registry, ordering, and supplement;
FT_Get_CID_Registry_Ordering_Supplement(), but ftdump does not use it.
In traditional usecases of CIDKeyedFont 0 and 2, we don't have to use
FreeType to obtain ROS information, because they are often written in
Hi,
In the recent Xcode (a genuine SDK for macOS) by Apple, the command "gcc" is an
alias of clang, there is no real GNU C compiler.
Although I've not checked whether its behaviour can be changed by its invocation name (the case which clang is invoked
as "clang", and the case which clang is
Hi,
Please try the released tarball of 2.6.5, instead of the git snapshot. If you
really really want to try the git snapshot for 2.6.5, you should gather the
versions when 2.6.5 was developed. According to
https://gitlab.freedesktop.org/freetype/freetype/-/blob/VER-2-6-5/autogen.sh ,
://www.rasterman.com/files/wp2.avi
but i don't think you will switch to the EFL :-)
regards
Vincent Torri
On Thu, Jul 28, 2022 at 8:02 AM suzuki toshiya
wrote:
Dear Werner, Charlie,
In the case of Ubuntu, the versions of Qt are following.
18.04LTS (until April 2023): 5.9.5
20.04LTS (until
Dear Werner, Charlie,
In the case of Ubuntu, the versions of Qt are following.
18.04LTS (until April 2023): 5.9.5
20.04LTS (until April 2025): 5.12.8
21.10: 5.12.2
22.04LTS (until April 2027): 5.15.3
Kinetic: 5.15.4
I think supporting Qt 5.12 is helpful for lazy late adapters like me :-),
but
Dear Liu Kunpeng,
Yes, at least I received your post through the list, I hope many people
received - but yet I don't have sufficient time to review the code, I apologize
sincerely.
Please could you allow me to ask a question before reviewing the code...?
FreeType2 has a functions like
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
Hi all,
Sorry for posting about my homework in 6 months ago.
During the fix for the issue 1078
https://gitlab.freedesktop.org/freetype/freetype/-/issues/1087
, I added a tweak skipping the randomization "tag"
of the family names of the fonts embedded in PDF.
They might even be broken but have zero maintenance cost.
+1
On 2021/08/06 0:00, Alexei Podtelezhnikov wrote:
Also, makefiles for DOS are present too
FreeDOS 1.3 RC4 released 3 May 2021
- Amiga: Discontinued in 1996
- Atari: Discontinued in 1992, latest console Atari VCS runs on a Linux
Dear Sarthak,
Is it possible for you to write a small external program producing a difference
from 2 images (rendered by FreeType)?
Regards,
mpsuzuki
On 2021/05/23 19:44, Sarthak Bhardwaj wrote:
Hello,
I was a little confused about, What file should I modify in the FreeType source
to
Dear Sarthak,
It seems that you think as - the FreeType is a huge software which the compiler
generates so many warnings, like uninitialized variable, passing the
inappropriate typed values, etc etc, and some of them are related with the
rasterization results. It is not. Even if you try to
Dear Anshuman,
Please check the official site as the first step to obtain the developers info:
https://www.freetype.org/developer.html
Regards,
mpsuzuki
On 2021/03/16 4:38, Anshuman Singh wrote:
Greetings,
I am an Engineering student from India and my coding interests lie primarily in
C.
I
Dear Utkarsh,
(sorry for that I slipped to follow FIFO rule)
Please check the official site as the first step to obtain the developers info:
https://www.freetype.org/developer.html
Regards,
mpsuzuki
On 2021/03/16 1:16, UTKARSH CHAUHAN wrote:
Hello,
I am Utkarsh Chauhan doing btech in
is PDLCJH+OCR-A font.
This is incremental font build of OCR-A font. Free type flags it as tricky.
BR,
Justyna
-Original Message-
From: suzuki toshiya
Sent: Friday, February 12, 2021 2:06 AM
To: Werner LEMBERG ; Justyna Wawrzynska
; Roy Tam
Cc: freetype-devel@nongnu.org
Subject: [EXTERNAL] Re
Dear Werner, Justyna and Roy,
"DLC" was introduced by the request from Mr. Roy Tam,
https://gitlab.freedesktop.org/freetype/freetype/-/commit/0ed9fef032641c30d0398d98a01b69eca1c15224
The assumed font file*s* were dlctt-m7.ttf and dftt-f5.ttf. Revisiting the changeset, using
"DLC" prefix in
Dear Werner, Anuj,
Werner LEMBERG wrote:
>> Also, I can see **Message not available* *after my emails in the
>> freetype-devel archives.
>
> AFAICS, this is a pure accident. The (automatically) deleted messages
> are spam, I reckon.
>
>> Am I doing something wrong?
>
> No, I don't think so.
Dear Werner,
Werner LEMBERG wrote:
>> Oh, I see the value to be stored is in a range [-1.0, 1.0].
>> I want to hear the comments from other developers :-),
>> whether the initial implementation should be FT_F2Dot14 (16bit)
>> or float (32bit, at least).
>
> Well, we have dropped 16bit support
>
> But, for now I think the storing part can be postponed until we have compared
> the
> accuracy. If there isn't a much difference in the accuracy of floats vs
> integers, then
> we can simply use 8 bits per pixel and store them as something like PNG.
> What do yo
I'm gonna do
> as Suzuki suggested
> and use floats for my initial draft and later without floats.
> And I'm not gonna focus on the saving part because the user can always do a
> conversion.
>
> Also, can I directly use *float* or use FT_Fixed?
>
> Thanks,
>
> Anuj
>
Dear Anuj,
I agree with Werner's comment.
It might be uncomfortable for you to leave an untested question, something
like "if I use a floating point calculation, the result could be better?".
Please use a floating point in your initial draft (if you want),
and let's discuss about the trade-off
am
most comfortable with it. But if it is necessary I will switch to Linux.
Do you use existing project file in the source tree? Or, do you use CMake?
Yes, I use cmake.
On Wed, May 6, 2020 at 11:08 AM suzuki toshiya
mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
Dear Anuj,
I was wondering if I could tweak th
ng else I should use,
> please let me know so that I can learn that in the meantime.
>
> Thanks,
> Anuj
>
> On Tue, May 5, 2020 at 10:32 AM suzuki toshiya
> mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
> Dear Anuj,
>
>> Should I call you Suzuki or Sir
Dear Anuj,
> Should I call you Suzuki or Sir Suzuki ? Which do you prefer?
"Suzuki" is sufficient! Please don't mind about the honorifics, I'm not a native
(or good) English user :-).
> I have a lot of questions and things to understand about the workflow, so can
> I ask them here only or is
Hello Anuj!
I'm suzuki toshiya, the one of your mentors. I'm glad to have a chance to help
your effort of the distance field.
I'm really old man who slipped to catch the wave of the recent e-communications
like twitter, Slack, Discord etc., and my organization is sometimes filtering
The circular dependency is a headache, but I don't think the
reconsideration of the building system is good place to discuss
the simplification of the dependency between FreeType and harfbuzz.
In my understanding, the features of harfbuzz used by FreeType are
very small subset, the classification
Dear Alexei, Turner,
It is a pity that I hear the lack of -fvisibility=hidden is
not only current status but promised in the future release X-(.
BTW, during the participation to Poppler and SVG Native Viewer,
I had big headache by the CMake's lack of the seamless (or
side-by-side) support for
Dear Moazin,
Please browse the attached SVG: which paints a big blue square (1024 x 1024),
and clip small circle at the center of it (r=64). How do you evaluate the
bitmap_left and bitmap_top? bitmap_left is 512 - 64 = 448? Or, bitmap_left is 0?
Moazin Khatri wrote:
> `Resvg' works with two
Moazin Khatri wrote:
>> BTW, how resvg calculate the bitmap_left properties?
>
> It doesn't. But we can do it using it. For the sake of this explanation
> assume that no scaling is to be performed. We firstly use `resvg' to get a
> tight bounding box around the `inked' part. It will return us a
>If all of them have such, I would discuss such API is acceptable for SVG
>Native Viewer.
I meant, I would discuss whether such API is acceptable for SVG Native Viewer.
Regards,
mpsuzuki
On 2019/06/14 19:05, suzuki toshiya wrote:
> Oh, I should add a few more.
>
>> I'll
have such, I
would discuss such API is acceptable for SVG Native Viewer.
Regards,
mpsuzuki
On 2019/06/14 18:44, suzuki toshiya wrote:
> Dear Moazin,
>
> On 2019/06/14 17:27, Moazin Khatri wrote:
>> For the sake of this explanation please assume that we are only talking
>> a
Dear Moazin,
On 2019/06/14 17:27, Moazin Khatri wrote:
> For the sake of this explanation please assume that we are only talking about
> the SVG documents which only contain one glyph and the whole document is
> supposed to be rendered.
OK!
> [...] I want to know how they are required for
Sorry for lated response.
Werner LEMBERG wrote:
>> 1. Get the pixel data of the whole SVG doc [...]
>> 2. Get the bounding box of the whole doc (or the particular node) in
>>SVG coordinates. [...]
> OK. Toshiya-san and/or Moazin, what about svgnative?
The SVG document object in SVG Native
Dear Moazin,
Thank you for writing the detailed report. Please let me comment 2 points (no
need to update the week 1).
* if the hyperlink to the commit on git repository (like
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=GSoC-2019-moazin=1fa8fe65
) is added, it helps the
Dear Vincent,
Vincent Torri wrote:
>> * the supported elements
>> I think the elements supported by this loader are defined by
>> TAG_DEF macro, thus, , , , , ,
>> , , , and, , , ,
>> are supported. Am I understanding correctly?
>
> yes
Good!
>> * input: xml support
>> If I can spot the
ed to rewrite whole of elf_gfx_xxx() to fit FreeType2,
simply I would respond "oh, too big, please modularize the
part just to support SVG, I would reconsider after seeing it".
Is it easy for EFL expert?
Regards,
mpsuzuki
Vincent Torri wrote:
> On Tue, May 21, 2019 at 6:00 PM suzu
Hi Vincent, Alexei,
On 2019/05/21 22:04, Alexei Podtelezhnikov wrote:
On Tue, May 21, 2019 at 5:35 AM Vincent Torri wrote:
as I have said, in our project, we parse ourselves the svg and use
freetype renderer directly for the rendering. we do not depend on any
external library
I noticed.
Hi,
Checking the feature range of libexpat, I found there are many
overescaped characters looking like "lt;".
It's very hard for me to translate into the appropriate format
in my brain on the fly, so I filed a pull request to fix them.
https://github.com/libexpat/libexpat.github.io/pull/15
In
Dear Moazin,
Wow, great! It would be very meaningful for you to have your own handaxe to
enter the jungle of unfamiliar softwares, because you can understand the
behaviour of your own handaxe completely. Although I've just taken a glance on
your code, I'm sure it's very clean and no need to have
Hi,
My forked repository of SVG Native Viewer
https://github.com/mpsuzuki/svg-native-viewer
, for the development of Cairo backend, has 2 important branches;
one is master, which is not changed from Adobe's original master branch,
another is cairo branch, which is my work-in-progress branch.
Dear Behdad,
Alexei wrote:
> Whatever external SVG renderer you choose, please use FT_Renderer facility to
> hook it up with FreeType instead of creating a set of SVG specific functions:
> an SVG glyph should be tagged as FT_GLYPH_FORMAT_SVG, which is then picked up
> by the dedicated SVG
Dear kind people giving the information on yet another SVG rendering software,
I'm sorry for that I ask for more detailed introduction, because I'm unsure
whether you're just trying to complete a list of SVG rendering softwares
(or softwares which has its own SVG renderer), or, you (strongly)
Dear Moazin,
> What's the status of your Cairo based rendering port? Is it as complete as
the Skia based rendering port? If both are complete, which one would you prefer to
be set as the default one for use with FreeType? and why?
It's ready to render an SVG to other surfaces (now
Dear Moazin,
The current status of my document is like this:
https://github.com/mpsuzuki/svg-native-viewer/blob/cairo-cpp11/README.md
Dirk told me that current Skia backend is designed for m70.
Also, maybe by some accident, Skia backend is forcibly disabled
if the platform detected by cmake is
; now. I can also relate it to Werner's SVG Global and Local initialization.
Basically, Werner just explained to me how we will be plugging modules in. Everything is clear and
in perspective now.
The terminology of "staying/non-staying" is totally fine to me.
Thank you,
Moazin
On Fri, May
Dear Moazin,
On 2019/05/09 21:13, Moazin Khatri wrote:
> Thank you for taking the time to write so much. It's really helpful.
My pleasure!
> I already know about how callbacks in languages like JS and Python work and I
am also familiar with how function pointers can be used to implement
Dear Werner,
On 2019/05/09 14:47, Werner LEMBERG wrote:
at least, I hope that this won't happen.
Me too!!!
Regards,
mpsuzuki
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Dear Behdad,
On 2019/05/09 14:18, Werner LEMBERG wrote:
Now, some would claim that that's exactly what is allowed in
OpenType. Again, that's what we will be discussing to make happen.
As it happens, there is no relationship between OpenType and SVG
Native.
OK.
Thank you for reminding that,
so done with your Cairo
based rendering port. I know how abstractions like these can be written in C++
via the use of Virtual Functions. But I am not sure how collaboration by
callbacks work or even if it's the same idea. I apologize in advance if I have
got some bit, or all of it wrong. Please ex
Dear Moazin, Alexei,
In my understanding, Sylvain's idea is much different from
the draft schedule of GSoC project of Moazin: I think Moazin
was going to combine some well-known & tested existing SVG
renderer, not going to write yet another SVG renderer.
Doing it might require big change of the
nking libsvgtiny is better than callback system, please
let me know.
Regards,
mpsuzuki
sylvain.bertr...@gmail.com wrote:
> On Wed, May 08, 2019 at 12:12:50PM +0000, suzuki toshiya wrote:
>> As far as I can remember, libsvgtiny was not discussed in the thread for
>> SVG-OT support. I didn't
Dear Sylvain,
As far as I can remember, libsvgtiny was not discussed in the thread for
SVG-OT support. I didn't know the exist of libsvgtiny, I must thank you
for giving the information.
But I want to know, you're already familiar with libsvgtiny and you suggest
as the libsvgtiny is the best
:
> 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,
>
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
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
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
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..
; [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:
lity 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
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
>
>
d 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
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
>
>
> - Origin
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?
>> Solar
hi
>
>
> - 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-de
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
>
racle.com/cd/E19205-01/820-1209/bjaii/index.html
https://stackoverflow.com/questions/37715467/how-to-print-preprocessor-macros-under-sun-studio
Maybe "__SUNPRO_C" could be used as the indicator.
Regards,
mpsuzuki
suzuki toshiya wrote:
> Dear Alexei,
>
>>> Does
ORT( x ) extern x
#endif
Thus, attribute visibility is only enabled for GCC >= 4.
Comparing with configure.raw, I guess you assumed that
-fvisibility is GCC-specific feature?
# I should remind, such kind of linker-related technologies
# in GNU toolchains are heavily inspired by Solaris, maybe
Alexei Podtelezhnikov wrote:
> On Thu, May 3, 2018 at 8:31 AM, suzuki toshiya
> <mpsuz...@hiroshima-u.ac.jp> wrote:
>> Dear Kanazawa-san,
>>
>> Hmm, it looks good... why Oracle cc hides all symbols...?
>>
>
> because it accepts -fvisibility=hidden, w
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
>>
Dear Alexei,
Yes, Oracle cc accepts it, as far as I can read from the online help.
And, at least, during the compilation (from *.c to *.o), the control
by __attribute__((visibility("default"))) works well. The exported symbols
are exposed to global.
But when Oracle cc links the object files into
Dear Kanazawa-san,
Hmm, it looks good... why Oracle cc hides all symbols...?
Regards,
mpsuzuki
Kiyoshi KANAZAWA wrote:
> Dear Suzuki san,
>
> ftexport.sym is attached,
>
> Regards,
>
> --- Kiyoshi
>
>
> - Original Message -
> From: suzuki to
.
If this issue is recognized as urgent, should I propose the exclusion of Oracle
CC from the cases to use "-fvisibility=hidden" even if it is available?
Regards,
mpsuzuki
suzuki toshiya wrote:
> Dear Kanazawa-san,
>
> Thank you for confirmation that the symbol loss occurs
> in linki
1 - 100 of 283 matches
Mail list logo
