Re: [ft-devel] (no subject)
> Is there any irc channel No, we don't have that. If you are interested in GSoC, communication is done via the `freetype-devel' e-mail list. For normal FreeType user questions please use the `freetype' e-mail list. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
There’s a link to unsubscribe at the bottom of every eMail. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
> Ah, this is the result of Emacs's `adaptive fill mode' that > automatically determines the fill prefix of paragraphs. Setting the > corresponding regexp explicitly fixes this. Attached is a patch – it > fixes some more places. > Great, this fixes it. Meanwhile, I had a look at the complete diff, and I'm attaching the cases that will need to be fixed manually, Other than these, I think we're now ready to convert to markdown, and apply your code to normalize lines. -- Nikhil problems.diff Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
>> Please check and report further problems! > > Here's one: > > * Calling the internal function `FT_Stream_Close` on the new stream > will > - * **not** call `FT_Stream_Close` on the source stream. None of the > stream > + * **not** call `FT_Stream_Close` on the source stream. None of the > + * **stream > * objects will be released to the heap. > > It seems like the overflowing word was moved to a new line of its > own. Also a stray `**' was added to the line. Ah, this is the result of Emacs's `adaptive fill mode' that automatically determines the fill prefix of paragraphs. Setting the corresponding regexp explicitly fixes this. Attached is a patch – it fixes some more places. >> PS: I think we should change *all* comments in the public header >> files to use `xxx` and 'xxx' (whatever appropriate) instead of >> `xxx' for consistency. I guess we have to do this manually, >> right? > > Already doing this :-) Great! Werner --- markdown-format.bash.old 2018-08-06 17:21:05.918467407 +0200 +++ markdown-format.bash 2018-08-07 21:11:50.179087065 +0200 @@ -11,6 +11,8 @@ ;;; Written 2018 by ;;; Werner Lemberg ;;; +;;; Version 2018-Aug-07 +;;; ;;; This code is explicitly placed into the public domain. @@ -38,6 +40,7 @@ ;; Set up a block (called a `form' in Elisp speak) with local ;; variables (called `local bindings' in Elisp speak). (let ((fill-column 78) + (adaptive-fill-regexp " \\* *") start end) ;; Outer loop: search a comment line that should be formatted. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
> attached you can find an Elisp script in disguise which calls Emacs > with itself. It will do the paragraph formatting after executing > `markify.py' as discussed. > > I've commented the script extensively; hopefully, it makes you > understand the Elisp code a little bit :-) > Thank you for the extensive comments! > A typical usage would be > > for i in `find . -type f -name "*.h"`; do > bash markdown-format.bash $i > done > > to convert all specified header files (without creating backup files). > I applied this to the markdown-converted header files from `GSoC-2018-nikhil' branch. > Up to now I've only found a single incorrect paragraph formatting due > to a sloppy @macro definition in the internal header file `ftserv.h': > It provides a bunch of `FT_DEFINE_SERVICEDESCREC*' lines that wouldn't > be output correctly anyway – this has to be undone manually after > running the script. > > Please check and report further problems! > Here's one: diff --git a/include/freetype/ftbzip2.h b/include/freetype/ftbzip2.h index 5ea9a53a5..d04109fbe 100644 --- a/include/freetype/ftbzip2.h +++ b/include/freetype/ftbzip2.h @@ -72,17 +72,18 @@ FT_BEGIN_HEADER * The source stream must be opened _before_ calling this function. * * Calling the internal function `FT_Stream_Close` on the new stream will - * **not** call `FT_Stream_Close` on the source stream. None of the stream + * **not** call `FT_Stream_Close` on the source stream. None of the + * **stream * objects will be released to the heap. It seems like the overflowing word was moved to a new line of its own. Also a stray `**' was added to the line. > PS: I think we should change *all* comments in the public header files > to use `xxx` and 'xxx' (whatever appropriate) instead of `xxx' for > consistency. I guess we have to do this manually, right? > Already doing this :-) https://github.com/nikramakrishnan/freetype-docs/blob/master/markdown_utils.py#L299 This uses regex to try and differentiate code sequences and normal text in quotes. It does a reasonable job, but manual cleanup is required. -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
Bhaskar, > (file:///home/bhaskar/Desktop/test-htmltomarkdown/doc1stpage.html) i > have tried to convert the home page of the freetype into markdown, > will be removing the whitespaces to make it more readable. As mentioned in another e-mail, it doesn't make sense right now to convert the homepage except for testing purposes to find out what you are going to write into your proposal :-) > Want to know wheather we have to convert the left side (Home,news, > overview part too)?? Well, yes. The ultimate goal is to have *everything* converted to markdown,[*] with navigation, CSS, etc., etc.: `make web' should create a state-of-the-art webpage that looks good. In particular, there should an *easy* way to quickly and automatically generate the navigation. Werner [*] I.e., the FreeType2 stuff, not the old FreeType1 data. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
[Please always write to one of the FreeType mailing lists so that we have a broader audience.] > Why does the table 'maxp' only specify *maxComponentElements *and > *maxComponentDepth* ? Doesn't the 'number of components in the 2nd > level' matter the memory pre-allocation? My mistake, sorry. I meant maxCompositePoints Maximum points in a composite glyph. maxCompositeContours Maximum contours in a composite glyph. > What if the 2nd level (if any) has more components then the top > level (Wouldn't this happen)? This doesn't matter. > Currently my 'composite glyph parsing process' is as follow: > Allocate two arrays -- outlinePoints[maxCompositePoints] and > endPtOfContours[maxCompositeContours]. Each time I visit a child > simple glyph of current composite glyph, I'll append the outline > points and end points of contours of the simple glyph to those two > arrays. Exactly. > But those two fields -- *maxComponentElements *and > *maxComponentDepth* -- don't even exist in this process. You are free to ignore them if your algorithm doesn't need those values; for example, FreeType doesn't use `maxComponentElements'. However, `maxComponentDepth' is useful to limit the recursion depth in case of buggy fonts. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
> 1. a simple problem -- I failed to build a demo project using > freetype2. [...] Since I don't use Windows, I can't help. Maybe someone else can chime in? > *2. When does the freetype parse the glyph data? > > My ttf_parser reads ttf file and parses the tables into classes > right away (This process is laterly referred as *LOAD *time). But > now I wonder if I can delay the glyph data parsing process to the > time when users fetch the glyph outline (referred as *FETCH *time). > I have two reasons supporting this change. Yes, you should read glyph data only on demand if you want quick parsing. Loading them completely is time consuming and costs a lot of memory. > But I am also afraid of the trade-off -- the FETCH process might > slow down. This should be neglegible compared to the rendering process itself. > Besides, I cannot pre-determine by how many simple glyph a specific > composite glyph is composed (is it?). Since composite glyphs can be nested, there is no way to get this number in advance without full parsing. Instead, there are the values maxComponentElements Maximum number of components referenced at “top level” for any composite glyph. maxComponentDepth Maximum levels of recursion; 1 for simple components. in the `maxp' table that should be sufficient to allocate the necessary memory in advance if necessary. [Unfortunately, some fonts don't compute the values correctly, but this is a different issue.] Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
> I believe the CMakeLists.txt is missing:
>
> include_directories("include")
A patch in diff format, please.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
>> Applied, thanks, with slight revisions (and formatting). Please >> check. > > I get segfaults in Firefox: Thanks, should be fixed now. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
16.07.2013, 13:38, "Werner LEMBERG" : >> Here's a small set of patches that slightly improve the performance >> of FreeType when compiled for ARM and x86_64 with GCC. I also >> checked that it doesn't negatively affect x86 performance. > > Applied, thanks, with slight revisions (and formatting). Please > check. I get segfaults in Firefox: Program received signal SIGSEGV, Segmentation fault. 0x73a94d7f in gray_find_cell (worker=worker@entry=0x1db4900) at /var/tmp/freetype2/src/smooth/ftgrays.c:557 557 if ( cell == NULL || cell->x > x ) (gdb) bt #0 0x73a94d7f in gray_find_cell (worker=worker@entry=0x1db4900) at /var/tmp/freetype2/src/smooth/ftgrays.c:557 #1 gray_record_cell (worker=worker@entry=0x1db4900) at /var/tmp/freetype2/src/smooth/ftgrays.c:587 #2 0x73a94e9d in gray_record_cell (worker=0x1db4900) at /var/tmp/freetype2/src/smooth/ftgrays.c:626 #3 gray_set_cell (worker=worker@entry=0x1db4900, ex=ex@entry=12, ey=-29, ey@entry=4) at /var/tmp/freetype2/src/smooth/ftgrays.c:630 #4 0x73a9521e in gray_render_line (worker=0x1db4900, to_x=4652, to_y=13572) at /var/tmp/freetype2/src/smooth/ftgrays.c:872 #5 0x73a95b92 in gray_line_to (to=, worker=) at /var/tmp/freetype2/src/smooth/ftgrays.c:1200 #6 0x73a49da9 in FT_Outline_Decompose (outline=outline@entry=0x1db5028, func_interface=func_interface@entry=0x73ac8f40 , user=user@entry=0x1db4900) at /var/tmp/freetype2/src/base/ftoutln.c:161 #7 0x73a95d33 in gray_convert_glyph_inner (worker=worker@entry=0x1db4900) at /var/tmp/freetype2/src/smooth/ftgrays.c:1791 #8 0x73a9607d in gray_convert_glyph (worker=0x1db4900) at /var/tmp/freetype2/src/smooth/ftgrays.c:1894 #9 0x73a94abe in ft_smooth_render_generic (render=0x1db9b00, slot=slot@entry=0x65bb9f0, mode=FT_RENDER_MODE_LCD_V, origin=, required_mode=required_mode@entry=FT_RENDER_MODE_LCD_V) at /var/tmp/freetype2/src/smooth/ftsmooth.c:288 #10 0x73a94ccf in ft_smooth_render_lcd_v (render=, slot=0x65bb9f0, mode=, origin=) at /var/tmp/freetype2/src/smooth/ftsmooth.c:445 #11 0x73a4dea3 in FT_Render_Glyph_Internal (library=0x19910c0, slot=0x65bb9f0, render_mode=FT_RENDER_MODE_LCD_V) at /var/tmp/freetype2/src/base/ftobjs.c:4055 #12 0x761e3564 in ?? () from /usr/lib64/firefox/libxul.so ... ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
> Here's a small set of patches that slightly improve the performance > of FreeType when compiled for ARM and x86_64 with GCC. I also > checked that it doesn't negatively affect x86 performance. Applied, thanks, with slight revisions (and formatting). Please check. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
> The way I try to read the buffer is by copying the bytes starting at > the memory location of the buffer ranging until glyph.bitmap.width * > glyph.bitmap.rows. I suspect alignment problems. Please have a look at the documentation of FT_Bitmap and read the details of the `pitch' field. For testing purposes, you should try to render a simple glyph shape, say, a rectangle, so that you can find out which pitch you need or get. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
> I guess to make DLL you have to use > #define FT_EXPORT(x) __declspec( dllexport ) x Can you write a small README file how to make such a library? I think it would be a good idea to add this to the FreeType's `docs' directory. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (no subject)
Trevor, > I compiled a DLL of FreeType with MSVC.NET, and the library initializes > fine, but I cant load a font (FT_New_Face(...);) > > I am using > > #define FT_EXPORT(x) x __cdecl > > for my FT_EXPORT() macro as > > __stdcall > > causes the compiler to crash. I am using the most recent "stable release". I guess to make DLL you have to use #define FT_EXPORT(x) __declspec( dllexport ) x > Any help as to whether my calling convention, compiler settings, or anything > else might be the cause of FT_New_Face not working, would be very much > appriciated. > > Note: I have tested the fonts I am using with a program I wrote that used > SDL_TTF (which wraps FreeType as I am sure you know) and the fonts loaded > and render correctly. > > Thanks in advance, and for all the help you have all offered me so far. I have some FreeType binaries available at http://kd.lab.nig.ac.jp/glyph-keeper/files.html They work for me and my users. Compilation scripts are included in the archives. -- Best regards, Kirill ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
