[ft-devel] Announcing ttfautohint 1.8.3

ttfautohint 1.8.3 has been released. The source tarball, statically-linked binaries for Win32 (TTY and GUI) and OS X (TTY only) are available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ttfautohint/1.8.3 Instructions to build t

Re: [ft-devel] harfbuzz dependencies for FT 2.10.0

>> Or better actually, simply add -DFT_CONFIG_OPTION_USE_HARFBUZZ. to >> the compile options when ON. > > Hm. Werner, the default build system modifies ftoption.h so that > the defines are persisted when the file gets installed into the > target include directory, no? Yep. Werner ___

Re: [ft-devel] harfbuzz dependencies for FT 2.10.0

> Why do we need to install ftoption.h? It does not contain public > API. It shows how FreeType has been configured at compile time. I consider this quite valuable information. > In config, only ftheader.h and a few types defined in ftconfig.h are > public. Can they be moved? Please elabora

[ft-devel] Three GSoC projects for FreeType

Dear FreeType community, we are happy to announce that FreeType participates at GSoC with three projects this year. https://summerofcode.withgoogle.com/organizations/6062712681922560/ The following projects were selected. (1) Veeki Yadav: Improve the 'ftinspect' demo program (2) Nikhi

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

>> Adding support for OpenType SVG Colored Fonts to FreeType > > Which svg renderer will be used? Whatever the system has, see below. > Which XML parser will be used? With a very high probability it will be `svgnative', contributed by Adobe: https://github.com/adobe/svg-native-viewer/ It's

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

> What happened to the resvg (Rust library) idea? It's not completely off the table, but it seems to me that `svgnative' is preferable. > Also, note that the small SVG Native comes at a cost that it doesn't > support much... This remark I don't understand. What exactly do you mean with `doesn

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

>> It's not completely off the table, but it seems to me that >> `svgnative' is preferable. > > Given that we want a pluggable renderer, the whole discussion is > moot. It's not moot at all IMHO. I want to have a default that has as few dependencies as possible and is flexible. And `svgnative'

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

> Hmm, so there is a possibility that (some) SVG-OT fonts require > richer features than SVG Native spec... I don't think so – at least, I hope that this won't happen. Ideally, the OpenType specifications gets updated to use the forthcoming W3C standard as soon it is finished. Werner _

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

>> I don't think so – at least, I hope that this won't happen. >> Ideally, the OpenType specifications gets updated to use the >> forthcoming W3C standard as soon it is finished. > > Given that we make SVG renderers "pluggable", even if this does > happen, won't we be able to just resort to some be

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

>> (1) Provide one or more API functions in FreeType that set up hooks >> (i.e., function pointers) for calling SVG routines. >> > > I think, whenever people use the term "API functions" in the context > of a library codebase, they are referring to functions which the > library exposes to th

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

>> On the other hand, I want to have a configure-time default so that >> it is only necessary to explicitly set hooks for non-default SVG >> libraries (or if the default SVG library is not found at configure >> time). This would allow applications to get SVG OpenType support >> out of the box, wit

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

> Now I also see why Toshiya was saying not to link any SVG library > directly to FreeType. Totally get it now! :) :-) Note, however, that I definitely want the `default SVG library' (whatever it will become after your explorations) to be linked to FreeType. Only if the user explicitly switche

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

> While I am at it: is freetype vector rendering code ignored for svg > font in the end? This is the plan, yes. SVG data will be sent to the external SVG library, which will return a bitmap or pixmap. I don't want to blow up FreeType with graphics code. Werner __

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

>> SVG data will be sent to the external SVG library, which will >> return a bitmap or pixmap. I don't want to blow up FreeType with >> graphics code. > > Ok. Then it would mean even the restricted "font svg" is > excessively expressive vector wise for freetype vector rendering > code. Maybe th

Re: [ft-devel] Supporting OT-SVG out of the box

> I think Werner took the day off today so let me quickly jump in with > a few thoughts that might help you until Werner is back :) Thanks! It's mother's day... >> 1. We specify `svgnative' and `cairo' as a dependency, just like >> 'libpng' is defined currently (provided it is configured to be >

Re: [ft-devel] Supporting OT-SVG out of the box

> It is amazing how complex dependency trees can be treated with ease > using dynamic linking. I compiled a very simple program that uses > FreeType today and tried to link everything statically. It's really > painful. I had to seek out `.a' files of the dependencies of > FreeType and then thos

[ft-devel] current git broken

Folks, current git of FreeType is severely broken for TTFs. I'm working on it. Werner ___ 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

> The criterion I have in mind is based on the following points: > > 1. *SVG Features*: This is very important. Anything that doesn't >support all of the features of `SVG Native' specification would >probably not be considered. The more features supported, the >better. On the other

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

>> 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 e

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

>> 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"? > > (Replying to your and Werner's messag

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

> If you read the OT-SVG table spec, multiple glyphs can refer to the > same SVG document. Then for a glyph eg. 1234, client is expected to > render the element with id "glyph1234" in the referenced SVG > document. OK, thanks. Since my SVG knowledge is virtually zero, the following question mi

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

>> Do you think that this kind of `caching' should be done on the >> FreeType side or on the SVG side? > > That's interesting question. Ideally font is memory-mapped and > FreeType just returns a pointer to the SVG document, so there's no > copying involved. Then the client can do any caching i

Re: [ft-devel] Pixel Differences after 2ea511eed8 and 7a81b63abc2b3

> in Chrome, I am encountering issues rolling to latest FreeType ToT, see > details in > https://bugs.chromium.org/p/chromium/issues/detail?id=962932 Assuming that you are testing with the current git, please post one or two images of the pixel differences so that Alexei can have a closer look.

Re: [ft-devel] Having trouble rendering emojis with FreeType

Moazin, the `ftview' demo program displays the font in question just fine, so maybe it makes sense to check this program how it works. Probably tomorrow I will check your code – but maybe you are faster than me in identifying the error :-) > *What's the problem?* > > If I call `FT_Set_Char_Siz

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

> We'll provide a test font that has multiple glyphs within an SVG > doc. I agree that this should be in a test suite repo. Excellent, thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/lis

[ft-devel] hinting of variation fonts was flawed

>From the ChangeLog: [truetype] Actually scale varied CVT values. Up to now, only the unscaled CVT values were varied; in other words, the `CVAR' data was never used for bytecode hinting. Please test this change! I only have `Skia', and I see differences, which seem to improve the resul

Re: [ft-devel] Having trouble rendering emojis with FreeType

> 'ftdump /usr/lib/thunderbird/fonts/EmojiOneMozilla.ttf' does not > show a "fixed size" section. Well, ftdump joypixels-android.ttf *does* show such a section :-) fixed size 0: height 128, width 136 size 109.000, x_ppem 109.000, y_ppem 109.000 Werner

Re: [ft-devel] An analysis of Librsvg

> I have a done a brief analysis of Librsvg in terms of the criterion > I discussed earlier. Very nice! However, please convert the stuff in the first section to a table with comments; this will increase readability, I think. For example SVG | banned | banned in | supported | fea

Re: [ft-devel] An analysis of Librsvg

> I've mentioned this discussion to the resvg dev, and he seems pretty > interested: > > https://github.com/RazrFalcon/resvg/issues/135 Thanks. > I can imagine that in case of resvg, the dev could be willing to > implement some profiles (such as OT-SVG and SVG Native) which, when > used, could

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

> The "fonts" dir at > https://github.com/unicode-org/text-rendering-tests now contains a > few TestSVG*.otf fonts, including one with multiple glyphs in a > single SVG doc (and one with gzip'd SVG). Thanks for telling us! Werner ___ Freetype-de

Re: [ft-devel] A reminder

> This is a reminder that my final exams for this semester are just > starting from tomorrow (24 May) and will end on 4 June. Have success! > [...] I plan to provide a similar overview of `resvg' this weekend > (hopefully, I'll get enough time to do it). Great! > The coding period of GSoC sta

Re: [ft-devel] FreeType into Chromium autoroller

> At [0] there is now an autoroller from Chromium's mirror of the > FreeType repository [1] into Chromium. [...] Thanks a lot! > This makes rolling easier for Chromium, but we also hope this is > useful to FreeType development. It certainly is. Werner __

Re: [ft-devel] different output from 32-bit and 64bit version of gray_render_scanline

> I've found that when I compile my code for i586 or x86_64, I get > different slightly different bitmaps using freetype. Interesting. > I eventually got to gray_render_scanline in src/smooth/ftgrays.c and > noticed that we have a different implementation of > gray_render_scanline for FT_LONG64

Re: [ft-devel] FreeType development cycle

> I have the following approach in mind: > > - Code the new stuff in the repo > - Write a program (with a `main' function) that will eventually > trigger the "newly added" part somehow. > - Use GDB to set a break point on the "newly added" part and then > step through it and confirm whether e

Re: [ft-devel] FT_Renderer for SVGs

> 1. I see that all default modules (including the renderers) are >initialized in FT_Init_FreeType. Whatever hooks we decide to >have, there is likely to be one for initiating the external >library. The function this initialization hook points to, will >usually instantiate the re

Re: [ft-devel] Modification in FT_Gzip_Uncompress

> In OpenType fonts, SVG documents can be either in plain text or gzip > encoded. > > While writing the code to read these documents I looked for a > function which could do gzip decoding inside FreeType. That's when > I found `FT_Gzip_Uncompress'. Using it, I realized it didn't work > as expec

Re: [ft-devel] 'ftinspect' project timeline

> Just a quick heads up to everyone who is wondering about the > progress in 'ftinspect' development so far. [...] Thanks! Werner PS: Please subscribe to the `freetype-devel' mailing list. https://lists.nongnu.org/mailman/listinfo/freetype-devel _

Re: [ft-devel] Optional fields and stream reading in WOFF2

> I have been going through the WOFF2 specifications, and there a lot > of optional fields in various tables. > > For example, the header size is fixed (48 bytes), but the table > directory (https://www.w3.org/TR/WOFF2/#table_dir_format) has > 2 optional fields, `tag' and `transformLength'. In a

Re: [ft-devel] 'ftinspect' project timeline

>> PS: Please subscribe to the `freetype-devel' mailing list. > > I'm already subscribed to the mailing list. OK, for some reasons the `moderated' bit was set... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongn

Re: [ft-devel] Optional fields and stream reading in WOFF2

> While trying to read the table directory, I am following these steps: > > 1. Define and assign `FT_Byte* p = stream->cursor;' > > 2. After reading and validating the header, I say something like > (assuming stream is within limit): > > table->FlagByte = FT_NEXT_BYTE( p ); > > this gives a segm

Re: [ft-devel] Optional fields and stream reading in WOFF2

> My bad, sorry. It's not `FT_NEXT_*' but either `FT_Get_*' or > `FT_READ_*'. From `ftstream.h': s/FT_Get_*/FT_GET_*/ Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] OpenType in SVG support?

> I'm curious if you have any updates on this? :) Moazin is working on this. https://hackmd.io/@xAHoMwB3QOSJR5L2HGzXGg/r19-sChRN Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetyp

Re: [ft-devel] ftinspect compilation error

> In the autofitter debug mode I'm able to test ftgrid and other > program but at the same time ftinspect compilation throws the > following error > > g++: error: ../../../freetype2/objs/.libs/libfreetype.a: No such file or > directory > Makefile:190: recipe for target 'ftinspect' failed > make:

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

> You can find the report for the work done so far here: > > https://hackmd.io/@xAHoMwB3QOSJR5L2HGzXGg/r19-sChRN Thanks a lot! > 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

Re: [ft-devel] Optional fields and stream reading in WOFF2

> [...] what is the point of using `FT_GET_XXX' if I can't use > `FT_STREAM_SEEK' or `FT_STREAM_POS'? How do I decide whether to use > `FT_READ_XXX' or `FT_GET_XXX'? FT_GET_XXX' calls are to be used within a frame (which sets up `stream->cursor' and `stream->limit'). However, if you have to jump

Re: [ft-devel] SVG Rendering Library

> [...] we expect to do the following using the external SVG rendering > library. > > 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. [...] I think all your conclusions are correct. > *Resvg* can do mo

Re: [ft-devel] SVG Rendering Library

> I think we can off-load all of the rendering and the `bitmap_left' > and `bitmap_top' extraction part to the rendering port. [...] Do we really have to get the those values by actually rasterizing the SVG stuff? I don't think this was the intention of the SVG specification in OpenType, since

Re: [ft-devel] SVG Rendering Library

>> [...] , it sounds as if the fonts should be designed as the metric >> values from TrueType or CFF glyphs could be used as if they are >> same for SVG glyphs. > > THIS! If that's the case, it is going to solve the whole problem I > think. :) I also believe that this is the route to go.

Re: [ft-devel] WOFF2 support update and questions

> I have implemented functionality to read the WOFF2 header, table > directory and collection directory (if the font is a TTC), including > most of the checks (given in the specification) in `sfwoff2.c' on > the `GSoC-2019-nikhil' branch. Nice! > It would be *great* if you could review (and also

Re: [ft-devel] crash in

>> > - $(OBJ_DIR_2)/grx11.$(O): $(GR_X11)/grx11.c $(GR_X11)/grx11.h >> > + $(OBJ_DIR_2)/grx11.$(O): $(GR_X11)/grx11.c $(GR_X11)/grx11.h $(GRAPH_H) > > Ok. I will do this in all drivers later tonight. [...] Thanks! Werner ___ Freetype-devel mai

Re: [ft-devel] DMARC related changes starting this week for FSF hosted Mailman lists

> Over the next few days, the Free Software Foundation will be making > changes to our GNU Mailman systems, [...] > > The first option, and the preferable way for discussion lists, is > what we call the "unmodified message fix." There are Mailman list > settings which modify the messages by adding

Re: [ft-devel] GSoC: OpenType SVG support in FreeType. Report Week II

> Please find the report of the last week here: > https://hackmd.io/@xAHoMwB3QOSJR5L2HGzXGg/Bk5IMbIkH > > I have added references to the commits that I talk about in the > report, just as Toshiya asked. I have tried to make it less > technical and focused more on the high level ideas. I hope it

Re: [ft-devel] WOFF2 support update and questions

> Let's say I want to load the nth font inside a TTC. Would it be > sufficient to write an SFNT stream starting with the Offset Table > (and not the TTC Header) along with only those tables that make up > the nth face? Yes. > To put this in context of WOFF2, I want to know whether I should pass

Re: [ft-devel] OT-SVG: Some issues I have run into with the previous design decisions

> Just one question, I grepped the source code of the current master > to see where else `other' field was being used. It turns out that > it is used only once inside the function `cff_compute_max_advance' > which is currently not in use with the comment, "unused until we > support pure CFF fonts

Re: [ft-devel] WOFF2 support update and questions

> Another question: How do I access the requested `face index'? > `sfnt_open_font' does not have the information as a parameter, but > its caller (`sfnt_init_face' does have the requested index as > `face_instance_index'). What do you mean with `access'? `sfnt_open_font' fills up the array with

Re: [ft-devel] WOFF2 support update and questions

>> What do you mean with `access'? `sfnt_open_font' fills up the >> array with all header offsets; it thus doesn't need a face index. > > But the whole process of uncompressing a WOFF2 will take place in > `sfwoff2.c' (woff2_open_font), which is being called from > `sfnt_font_open'. If the func

Re: [ft-devel] CMake build system: some proposed changes

> I've been looking at some CMake issues filed over at Savannah. One > ting that pops up in a few places is that some people do not expect > CMake to autodetect external dependencies, which can lead to > problems when e.g. baking packages for distribution. Having switches for all external depende

Re: [ft-devel] WOFF2 support update and questions

> I have added Brotli as a dependency with commit > 8e05ab3e2ebf9d90b6015cb2aa7e789517b293e6. This works on my setup > after installing Brotli and running `sh autogen.sh', `./configure' > in the freetype2 directory. I'm also now able to include > `brotli/decode.h' in `sfwoff2.c'. Looks good, than

Re: [ft-devel] Accessing FT_Stream API

> Also, I just ran into the issue of `FT_Stream_OpenGzip' requiring > the stream to having a valid `memory' field, which is not provided > by `FT_Stream_OpenMemory' (for obvious reasons). This looks like a bug, both in documentation (which doesn't mention it) and implementation (which doesn't cor

Re: [ft-devel] GSoC: OpenType SVG support to FreeType: Report Week 3

> Please find the report for week 3 here: > https://hackmd.io/@xAHoMwB3QOSJR5L2HGzXGg/Hyk1JtC1S Thanks! > *A demo of `ftview' working with OT-SVG fonts* Very nice! A minor nit: To both save bandwidth and speed up downloads I suggest that the next time you are going to demonstrate something wit

[ft-devel] Announcing FreeType 2.10.1

FreeType 2.10.1 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ The latter site also holds older versions of the FreeType library. See below for the relevant snippet from the CHANGES file. Enjoy

[ft-devel] Fw: Announcing FreeType 2.10.1 - regression in ftgzip.c

Ouch! Folks, please confirm the issue and advise how to fix it best. Werner --- Begin Message --- Hi Werner, I tried to subscribe to the mailling list but https://lists.nongnu.org is currently unreachable. I've found a bug related to commit #6a92b1fadde26477a9179cbea988b3e04bd2decc. In f

Re: [ft-devel] Fw: Announcing FreeType 2.10.1 - regression in ftgzip.c

>> Ouch! Folks, please confirm the issue and advise how to fix it best. > > The issue is with outdated internal copy of ZLib. It is best to > update the internal copy. I agree. I wanted to do this since years, but it is a non-trivial thing, alas, mainly because I don't have any experience wit

Re: [ft-devel] Announcing FreeType 2.10.1 - regression in ftgzip.c

> Werner, I think this change shouldn't have been made to master > because it fails with the built-in version of zlib. Don't know what > we should do now. Probably revert it? This is what we will tell people who are forced to use the internal zlib version. As Alexei suggested, updating the int

Re: [ft-devel] [GSoC'19] ftinspect questions

> I need to obtain the glyph index and that could be done using the > two methods .i.e * FTC_CMapCache_Lookup > * > and *FT_Get_Char_Index >

Re: [ft-devel] Fw: Announcing FreeType 2.10.1 - regression in ftgzip.c

> I would be happy to give it a try, after GSoC or within it. Thanks! > I am starting the work on an `svgnative' based port. Let's see how > it goes and how much work is remaining for the OT-SVG project. OK. Werner ___ Freetype-devel mailing l

Re: [ft-devel] GSoC: OT-SVG: `librsvg' based port functional now

> While using resvg to render glyphs from SVG documents which contain > multiple glyphs, I observed some clipping issues. Ultimately, I > realized the problem was with `resvg'. So I started work on a > `librsvg' based port. That is functional now and can be found here >

Re: [ft-devel] Fw: Announcing FreeType 2.10.1 - regression in ftgzip.c

>> Moazin, Nikhil, would one of you be able to do that? Of course >> after the GSoC, or in case you have too much time :-) > > Although I have no experience with zlib either, I'll be happy to > help out with this after summer, if I can find the time :-) Thanks too for your offer! Werner

Re: [ft-devel] [GSoC'19] ftinspect questions

> is this tool availablle on Windows too ? It should be, more or less – it is Qt code using a `.pro' file (which must be manually adjusted). However, I haven't tried it, and there may be stuff that works on Unix boxes only. It would be great if you could test it and report problems. Werne

Re: [ft-devel] [GSoC'19] ftinspect questions

> I have integrated the basic functionality of 'ftview'. Great! > As all the demo programs have some features specific to each. For > example 'ftview' has options for stroke, slant etc. So, I was > wondering about creating option tabs specific to some programs or > instead just add all the fea

Re: [ft-devel] WOFF2 support update and questions

> I have now added code to uncompress the Brotli-compressed stream. Nice! > Right now, I'm allocating the required memory for the stream, and > storing the output in an FT_Byte array (`uncompressed_buf'). How do > I create an `FT_Stream' from this so that I can read it using the > `FT_READ_XXX'

Re: [ft-devel] [GSoC'19] ftinspect questions

>> > is this tool availablle on Windows too ? >> >> It should be, more or less – it is Qt code using a `.pro' file >> (which must be manually adjusted). However, I haven't tried it, >> and there may be stuff that works on Unix boxes only. >> >> It would be great if you could test it and report pro

Re: [ft-devel] [GSoC'19] ftinspect questions

> As far as I know, Qt *does* work on a large bunch of Windows > versions. If everything fails, you can try GNU/Linux for compilation :-) I regularly build a Windows stand-alone binary of my ttfautohintGUI program using the mxe framework. https://mxe.cc/ https://sourceforge.net/projects/fre

Re: [ft-devel] Accessing FT_Stream API

>>> Also, I just ran into the issue of `FT_Stream_OpenGzip' requiring >>> the stream to having a valid `memory' field, which is not provided >>> by `FT_Stream_OpenMemory' (for obvious reasons). >> >> This looks like a bug, both in documentation (which doesn't mention >> it) and implementation (whi

Re: [ft-devel] WOFF2 support update and questions

>> `FT_Stream_OpenMemory' is be the right function. After calling >> this, you should use `FT_Stream_EnterFrame' and proceed as usual. > > This is working now. [...] OK, LGTM. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org ht

Re: [ft-devel] [GSoC'19] ftinspect questions

>> IMHO, `FT_Get_Char_Index' is sufficient. For displaying single >> characters in `ftinspect' (or a bunch of them once in a separate >> window for ftview-like stuff) you don't need a cache for speeding >> up things. > > Let me know if I'm wrong but isn't it looks up the glyph index > correspondi

Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks

Hello Moazin! > [...] `ft_mem_*' cannot be accessed from outside FreeType if the > client program is linking dynamically. Yes. IMHO, it should stay hidden, to properly encapsulate such internal detail. > To solve this issue, memory allocation needs to be performed from > the FreeType side.

Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks

>> Not necessarily. You could also provide hooks for allocation, >> (probably reallocation also), and deallocation routines. > > Okay so these 3 functions will be written on FT side (more or less > wrappers around `ft_mem_*' functions) and their function pointers > will be passed down to the ren

Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks

>> Do you plan runtime selection of SVG library? This is not very >> user friendly. Perhaps it is better to have separate rendering >> modules for each SVG library, selected at compile time. I will >> take a detailed look at your code soon. > > Well, yes, at the moment it is selected at runtim

Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks

> We should not decide this if both libraries work. Why not? I don't see any problem in providing a default that can be overridden by the user. It's less than 10 lines of (user) code to do so. > We should have both modules available so that user can FT_Add_Module > or FT_Remove_Module at runti

Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks

>>> We should not decide this if both libraries work. >> >> Why not? I don't see any problem in providing a default that can >> be overridden by the user. It's less than 10 lines of (user) code >> to do so. > > We might even suggest that the SVG libraies maintain the respective > renderers in t

Re: [ft-devel] GSoC: OT-SVG: Brief Update Week 5

> I wanted to give a brief update on the work done this week. Most of > it was discussed in the mailing list however, just for completeness > sake, I would briefly describe it in this email. [...] Thanks, very helpful! Werner ___ Freetype-devel

Re: [ft-devel] GSoC: OT-SVG: Brief Update Week 6

>> 2. Adding a default library for OT-SVG. No default has been >>decided. So I'll just try it with all three libraries that I >>have been working with. :D > > Or, you can just prioritize the separate renderers. Do not waste > your work. While the concept of having different renderers so

Re: [ft-devel] GSoC: OT-SVG: Brief Update Week 6

>> I still favour the model of having a *single* default renderer for >> SVG, providing hooks that can be overridden at run-time for another >> library. > > This is not user friendly and users will resist it. If I'm going to use a non-default SVG engine then I clearly expect some lines of code f

Re: [ft-devel] GSoC: OT-SVG: Brief Update Week 6

> No default required. Ah, this reminds me of another option for the `configure' script. --with-svg=yes unconditionally use a default SVG engine (to be determined yet which one) --with-svg=no don't compile the SVG code --with-svg=autoeither

Re: [ft-devel] GSoC: OT-SVG: Brief Update Week 6

> PS: One easy solution that just came to my mind is making the hook > structure public and just passing the pointer to it. Only one call > to `FT_Property_Set'. :) Yep. Thanks for the quick change! Werner ___ Freetype-devel mailing list Freety

Re: [ft-devel] GSoC: OT-SVG: Brief Update Week 6

> It is supposed to work from an environment variable > FREETYPE_PROPERTIES too. So please use: > > FT_Property_Get( library, "svg", "svg_library", "librsvg" ); > FT_Property_Get( library, "svg", "svg_library", "resvg" ); > > and then hide the presets and consider proper default initializatio

Re: [ft-devel] Question about default SVG library integration in FreeType build system

>> imho, just set CPPFLAGS and LDFLAGS accordingly so that header >> files and libraries are found. These environment variables exist >> for such purpose Yes, so... > However, ultimately when we do decide on a default library, we'd > wanna have proper configuration for the SVG library in the bu

Re: [ft-devel] Question about default SVG library integration in FreeType build system

>> ... simply use the `PKG_CHECK_MODULES' macro in `configure.raw', >> which provides both the necessary environment variables and a check >> whether a proper .pc file is available (the former overrides the >> latter). > > Thanks. I have done the basic work needed to have a default library. Looks

Re: [ft-devel] Question about default SVG library integration in FreeType build system

>> [...] I believe that my suggested `no-default' mode is a simpler >> solution; [...] > > Okay, so if I have understood this correctly. In case of `auto' or > `yes', we see if our default is available, and if yes, we use that, > if the user chose `no-default' then the user would need to plug the

Re: [ft-devel] Question about default SVG library integration in FreeType build system

> One more thing, in case the user chose `yes' or `auto' and the > default SVG library wasn't found in the system and neither were the > environment variables, should we fallback to `no' (No SVG support) > or `no-default' (SVG code compiled but no default hooks). If the user chooses `yes' and the

Re: [ft-devel] Question about default SVG library integration in FreeType build system

> 1. The `rules.mk' of the `svg' module compiles the port files. That >should only be compiled only if a default SVG port is needed, >otherwise not. So, my question was how do I access this >information (whether `yes'/`auto' was selected or `no-default') >in my `rules.mk'. The s

Re: [ft-devel] Question about default SVG library integration in FreeType build system

>> Simply protect the whole code in the SVG module file(s) with >> >> #ifdef FT_CONFIG_OPTION_SVG >> ... >> #endif > > I tried this. But there's one problem with it. The `bzip2' module > doesn't expose anything apart from some functions. However, my `svg' > module exposes a renderer class w

Re: [ft-devel] Question about default SVG library integration in FreeType build system

> Werner, the integration of a default SVG library in the GNU build > system (`configure.raw' and `Makefiles') is almost complete now. Excellent, thanks! > Should I now integrate it in other build systems too? Hmm. > I see mainly two other build systems namely CMake and Jam. If yes, > which o

Re: [ft-devel] GSoC: OT-SVG: Performance concerns about SVG Document Lookup

> Currently, the SVG document lookup is a simple linear search. See > `find_doc' in `src/sfnt/ttsvg.c'. This is inefficient and I think I > should convert it to binary search. Yes – and you've already done so, thanks :-) Werner ___ Freetype-deve

Re: [ft-devel] GSoC: OT-SVG: Feature requirements from SVG rendering library

> In this email I intend to list the features we require from an SVG > rendering library for use in OT-SVG project. [...] Thanks for the overview. > `librsvg' recently got a new function added namely, > `rsvg_handle_get_intrinsic_dimensions' which meets (1) completely. > However, it's too recen

Re: [ft-devel] GSoC: OT-SVG: Error propagation from SVG library hooks

> I was trying to write some good error handling code in the > `librsvg' rendering port. If you say `rendering port', you mean code that gets added to librsvg, to FreeType, or to the calling application? > What I did is that I created a new error `Invalid_SVG_Document'. > Then, I check the error

Re: [ft-devel] GSoC: OT-SVG: Error propagation from SVG library hooks

>> If you say `rendering port', you mean code that gets added to >> librsvg, to FreeType, or to the calling application? > > I mean the hook functions which the client will write and set them > using `FT_Property_Set'. These will of course be different for each > library. Have a look here: > htt

Re: [ft-devel] GSoC: OT-SVG: Error propagation from SVG library hooks

>> So yes, please define errors and use them in the external code, but >> just without FT_THROW. Maybe the library uses its own error code >> debugging feature... > > How does this look? This is OK :-) Werner ___ Freetype-devel mailing list Free

Re: [ft-devel] Travis CI broken: OSS Regression Suite

> I am aware of the fact that Travis CI is broken since midweek and > I'm trying to talk to someone from Travis to get that fixed. [...] Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/li

<    8   9   10   11   12   13   14   15   16   17   >