Re: Gradient Color Fonts, COLR v1 Contributions to FreeType
>> Alexei, this sounds interesting. Care to implement this, as an >> alternative interface? What Dominik has written fits quite well to >> the existing API, so I'm in favor to add his code. > > I am scared of ttgload.c, which constantly juggles transforming and > hinting. Are layers ever transformed or hinted? Of course they are! The layers are ordinary glyphs consisting of ordinary outlines, which are handled the normal way. Whether hinted layers make sense, and whether you find such layers in the wild is a different question. Werner
Re: Gradient Color Fonts, COLR v1 Contributions to FreeType
> > I would much rather prefer that > > > > 1) FT_Load_Glyph sequentially loads and merges all contours from all > >layers into a single outline and uses FT_GlyphSlot->other to tag > >each contour with the layer information and the corresponding > >comprehensive (including gradient) color description after > >palette decoding. This could potentially work for SVG glyphs > >too. I really want FT_GlyphSlot to be self-sufficient and ready > >for a renderer to handle it without any additional calls. This > >could be a new glyph format. > > > > 2) then FT_Render_Glyph just calls a color renderer which quickly > >allocates the entire CBox of memory and just blends the layers > >possibly using FT_RASTER_FLAG_DIRECT for speed. We can > >eventually have gradient support as well. > > Alexei, this sounds interesting. Care to implement this, as an > alternative interface? What Dominik has written fits quite well to > the existing API, so I'm in favor to add his code. I am scared of ttgload.c, which constantly juggles transforming and hinting. Are layers ever transformed or hinted?.. > Note that the iterative API works also quite nicely if you are *not* > using FreeType to manage gradients and the like. On the other hand, > it seems to me that your proposed solution necessitates gradient > handling within FreeType (but maybe I'm just confused). On the contrary, I am advocating for loading of all layers as combined outlines with attached color descriptors per each contour or blocks of contours, but short of rendering. Rendering them would be implemented *eventually* but not necessarily for all cases. I see that solid colors and linear gradients are within the realm of possibility for FreeType as they do not require non-linear math. Alexei
Re: Logging Library-GSOC
> With my last commit dlg's Visual Studios project is only built for > `Debug' and `Debug Static' configurations on both `x64' and `Win32' > platforms. For `Release' and `Release Static' builds, dlg's build > is skipped. This sounds completely correct. Werner
Re: Logging Library-GSOC
Hi Alexei, *> I am sorry I was not following your logging project closely enough. So> I asked the most general question.* Ok, no problem at all :-) *> What is the difference between submodules and modules?* As part of this project, I have to integrate an Open Source logging library in FreeType to print tracing and other log messages to a file instead of stderr, for debugging purposes. Since dlg is a third party library and it uses a Meson build system for building purposes, Werner suggested me to first checkout dlg in a separate directory: `submodules/dlg' (`submodules' as for git submodule), and afterward, copy the necessary files to `src/dlg'. The directory `src/dlg' would contain a `rules.mk' file to build dlg along with FreeType, whenever FreeType is configured with a macro `FT_LOGGING' present in `include/freetype/config/ftoption.h'. > *Is this the mechanism to turn it on/off?* Therefore, the printing of tracing and other logs is totally controlled by `FT_LOGGING' macro in `include/freetype/config/ftoption.h' on both Windows and UNIX platforms. Please, let me know if there are any other concerns regarding my project. *> It is probably ok to have it enabled only in Debug builds (or make> devel). But there must be a way to disable it altogether.* With my last commit dlg's Visual Studios project is only built for `Debug' and `Debug Static' configurations on both `x64' and `Win32' platforms. For `Release' and `Release Static' builds, dlg's build is skipped. I wanted to check if I have set up the dlg's Visual Studios Project on Windows correctly? Especially, for Release builds of FreeType, is simply skipping dlg project the right way to not build dlg, or is there some other way around? Please guide me... Thanks, Priyesh On Tue, Aug 4, 2020 at 5:17 PM Alexei Podtelezhnikov wrote: > Hi Pryiesh, > > I am sorry I was not following your logging project closely enough. So > I asked the most general question. > > On Tue, Aug 4, 2020 at 7:32 AM Priyesh kumar > wrote: > > > > Hi Alexei, > > Thanks for replying. > > > > > It looks ok as far as clean separation. I don't quite understand why > > > you need to copy files > > In one of the previous mail about building dlg on Linux, Werner > > suggested me to first copy necessary files from `submodules/dlg' to > > `src/dlg' and then use a rules.mk file to build dlg. > > Therefore, I thought to set up the same directory hierarchy on windows > also. > > Is this the mechanism to turn it on/off? What is the difference > between submodules and modules? > > > > and how to disable dlg. > > I didn't understand your concern here... > > Are you asking about skipping dlg build in `Release' and `Release > Static' builds? > > It is probably ok to have it enabled only in Debug builds (or make > devel). But there must be a way to disable it altogether. > > Alexei >
Re: Logging Library-GSOC
Hi Pryiesh, I am sorry I was not following your logging project closely enough. So I asked the most general question. On Tue, Aug 4, 2020 at 7:32 AM Priyesh kumar wrote: > > Hi Alexei, > Thanks for replying. > > > It looks ok as far as clean separation. I don't quite understand why > > you need to copy files > In one of the previous mail about building dlg on Linux, Werner > suggested me to first copy necessary files from `submodules/dlg' to > `src/dlg' and then use a rules.mk file to build dlg. > Therefore, I thought to set up the same directory hierarchy on windows also. Is this the mechanism to turn it on/off? What is the difference between submodules and modules? > > and how to disable dlg. > I didn't understand your concern here... > Are you asking about skipping dlg build in `Release' and `Release Static' > builds? It is probably ok to have it enabled only in Debug builds (or make devel). But there must be a way to disable it altogether. Alexei
Re: Logging Library-GSOC
Hi Alexei, Thanks for replying. > It looks ok as far as clean separation. I don't quite understand why > you need to copy files In one of the previous mail about building dlg on Linux, Werner suggested me to first copy necessary files from `submodules/dlg' to `src/dlg' and then use a rules.mk file to build dlg. Therefore, I thought to set up the same directory hierarchy on windows also. > and how to disable dlg. I didn't understand your concern here... Are you asking about skipping dlg build in `Release' and `Release Static' builds? Thanks, Priyesh On Mon, Aug 3, 2020 at 10:43 PM Alexei Podtelezhnikov wrote: > Hi Priyesh > > On Mon, Aug 3, 2020 at 10:33 AM Priyesh kumar > wrote: > > > > Hi Alexei, > > Is there any update for me regarding Werner's previous mail? > >> > The dlg project contains two configurations: `Debug' and `Debug > >> > Static' on both `x64' and `Win32' platforms and will be built with > >> > FreeType, whenever FreeType is built in these configurations. I > >> > have also added a windows batch file which is called as a pre-built > >> > event whenever dlg is built, and it takes care of copying files from > >> > `submodules/dlg' to `src/dlg'... For `Release' and `Release Static' > >> > builds of FreeType the dlg project build will simply be skipped. > >> > >> OK. Alexei, can you please have a look? I have no clue about > >> Visual C, and I guess Priyesh wants to have comments. > > It looks ok as far as clean separation. I don't quite understand why > you need to copy files and how to disable dlg. > > Thanks, > Alexei >
Re: Gradient Color Fonts, COLR v1 Contributions to FreeType
>> I've made some progress with the COLR v1 extension implementation >> in FreeType and would be happy to hear initial feedback on the >> general approach and API style. Dominik, this is very nice code, thanks! > I would much rather prefer that > > 1) FT_Load_Glyph sequentially loads and merges all contours from all >layers into a single outline and uses FT_GlyphSlot->other to tag >each contour with the layer information and the corresponding >comprehensive (including gradient) color description after >palette decoding. This could potentially work for SVG glyphs >too. I really want FT_GlyphSlot to be self-sufficient and ready >for a renderer to handle it without any additional calls. This >could be a new glyph format. > > 2) then FT_Render_Glyph just calls a color renderer which quickly >allocates the entire CBox of memory and just blends the layers >possibly using FT_RASTER_FLAG_DIRECT for speed. We can >eventually have gradient support as well. Alexei, this sounds interesting. Care to implement this, as an alternative interface? What Dominik has written fits quite well to the existing API, so I'm in favor to add his code. Note that the iterative API works also quite nicely if you are *not* using FreeType to manage gradients and the like. On the other hand, it seems to me that your proposed solution necessitates gradient handling within FreeType (but maybe I'm just confused). Werner
