Re: [ft-devel] (no subject)

2019-03-08 Thread Werner LEMBERG


> 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


[ft-devel] (no subject)

2019-03-08 Thread Sourabh Sharma
Hi
My name is Sourabh Sharma
Is there any irc channel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] (no subject)

2019-03-03 Thread Nikolaus Waxweiler
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


[ft-devel] (no subject)

2019-03-03 Thread Angie Fitch
Please unsubscribe me from getting emails from the free type project. Thank
you, Angie Fitch
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] (no subject)

2018-08-10 Thread Nikhil Ramakrishnan
> 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)

2018-08-07 Thread Werner LEMBERG

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

2018-08-07 Thread Nikhil Ramakrishnan
> 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


[ft-devel] (no subject)

2018-08-06 Thread Werner LEMBERG

Nikhil,


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

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

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!


Werner


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?
#! /bin/sh
":"; exec emacs --no-site-file --script "$0" -- "$@" # -*- mode:emacs-lisp -*-

;;; ^^^ The above line makes `bash' execute emacs in batch mode, using
;;; this script as input.  Note that the script handles a single
;;; argument only.


;;; markdown-format.bash
;;;
;;; Written 2018 by
;;; Werner Lemberg 
;;;
;;; This code is explicitly placed into the public domain.


;;; The job of this script is to format paragraphs as emitted by
;;; Nikhil Ramakrishnan's `markify.py' script, cf.
;;;
;;;   https://github.com/nikramakrishnan/freetype-docs/blob/master/markify.py


;; We don't want backup files.
(setq make-backup-files nil)

(message "Processing file `%s'" (nth 1 argv))

;; Open file.
(find-file (nth 1 argv))

(defun markdown-format-paragraph ()
  ""
  (interactive)

  ;; Go to beginning of file.
  (goto-char (point-min))

  ;; Set up a block (called a `form' in Elisp speak) with local
  ;; variables (called `local bindings' in Elisp speak).
  (let ((fill-column 78)
start
end)
;; Outer loop: search a comment line that should be formatted.
;; (Note that backslashes must be doubled in Elisp strings.)
(while (re-search-forward "^   \\*\\( \\|$\\)" nil t)
  ;; Go to the beginning of the current line and remember this
  ;; position.
  (setq start (line-beginning-position))
  (setq end start)
  (goto-char start)

  (message "%s" (line-number-at-pos))

  ;; Inner loop: collect stuff for formatting, line by line.  Stop
  ;; also if we have
  ;;
  ;;   * the start of a code block (surrounded by "```"),
  ;;   * a tag (ending in `::'), or
  ;;   * an `@order' or `@sections' section.
  ;;
  ;; Since the regexp machine of Emacs doesn't support negative
  ;; look-ahead assertions, we use two regexps in succession.
  ;; Both regexps are restricted to the current line; the second
  ;; one starts searching at the position where the first stops.
  ;;
  ;; `\=' matches the current position (`point' in Elisp speak).
  (while (and (re-search-forward
   "^   \\*\\( \\|$\\)"
   (line-end-position)
   t)
  (not (re-search-forward
"\\= *\\(```\\|[[:alnum:]_-]+ 
::\\|@order:\\|@sections:\\)"
(line-end-position)
t)))

;; If we were successful, update end position ...
(setq end (line-end-position))
;; ... and advance to the beginning of the next line.
(beginning-of-line 2))

  ;; Format the collected lines (if there is something to format)
  ;; and advance to the next line.  Before doing so, however, we
  ;; have to attach a text property to the character at position
  ;; `end' so that we can find this character after formatting
  ;; (`end' is simply an integer and doesn't adjust to the new
  ;; position).  Reason is that `fill-individual-paragraphs'
  ;; doesn't have a sensible return value, but we need a position
  ;; to continue.
  ;;
  ;; We arbitrarily call the property `fill-end'.
  (unless (= start end)
(put-text-property end (+ end 1) 'fill-end t)
(fill-individual-paragraphs start end)
(next-single-property-change start 'fill-end)
(beginning-of-line 2))

  ;; If the current line starts a code block, skip it.
  (if (re-search-forward "^   \\* +```" (line-end-position) t)
  (re-search-forward "^   \\* +```" nil t))

  ;; If the current line starts an `@order' or `@sections'
  ;; section, skip to the next section or to the end of the
  ;; comment block.
  (if (re-search-forward "^   \\* +\\(@order:\\|@sections:\\)"
 (line-end-position)
 t)
  (unless (re-search-forward "^   \\* +@[[:alnum:]_-]+:" nil t)
(re-search-forward "^   \\*/" nil t)))

  ;; Advanc

[ft-devel] (no subject)

2018-03-10 Thread ranshi stanley
please need help and directives on how to go about here.
   thanks
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] (no subject)

2018-03-06 Thread Werner LEMBERG

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


[ft-devel] (no subject)

2017-07-11 Thread Werner LEMBERG

> Perhaps a little too much to add a new Changelog entry for a
> one-character typo...

Indeed.

> Please feel free not to add the Changelog entry.

Yep.  I've applied the rest of the patch, thanks!


Werner

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


[ft-devel] (no subject)

2017-07-10 Thread Hin-Tak Leung
Hi,

Perhaps a little too much to add a new Changelog entry for a one-character 
typo... Please feel free not to add the Changelog entry.

Hin-TakFrom 8ed5b92c078ee972dfbce30c3500915d3f5866f7 Mon Sep 17 00:00:00 2001
From: Hin-Tak Leung 
Date: Tue, 11 Jul 2017 01:53:01 +0100
Subject: [PATCH] * Changelog: typo, chromium issue id is 2276 instead of 2278

Signed-off-by: Hin-Tak Leung 
---
 ChangeLog | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 235e4093e..5c0867baf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2017-07-11  Hin-Tak Leung  
+
+	* Changelog: typo, chromium issue id is 2276 instead of 2278
+
 2017-07-07  Werner Lemberg  
 
 	[cff] Integer overflow.
@@ -152,7 +156,7 @@
 	Reported as
 
 	  https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2270
-	  https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2278
+	  https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2276
 
 	* src/truetype/ttinterp.c (Ins_MDRP, _iup_worker_interpolate): Use
 	ADD_LONG and SUB_LONG.
-- 
2.13.0

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


Re: [ft-devel] (no subject)

2014-04-23 Thread Werner LEMBERG

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

2014-04-20 Thread Werner LEMBERG


> 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


[ft-devel] (no subject)

2014-04-20 Thread Zhenglai Liu
Hi there,
I'm writing a ttf parser and want to learn from the source code of freetype.
My questions are:
*1.* a simple problem -- I failed to build a demo project using freetype2.
I followed the steps in "FreeType 2 Tutorial Step
1
".
First, I located "the FreeType 2 include directory" by right clicking on
project, Properties, Configuration Properties, VC++ Directories, Include
Directories, and added "D:\freeT\freetype2\include". Note that my project
directory is "D:\freeT\".
Second, I wrote the following code:
#include 
#include FT_FREETYPE_H
#include 
int main(){
  FT_Library  library;
  FT_Face face;  /* handle to face object */
  FT_Error error = FT_Init_FreeType( &library );
  if ( error ) { printf("Error!\n"); }
  error = FT_New_Face( library,
"arial.ttf",
0,
&face );
if ( error ){
printf("ERROR!\n");
  }
  printf("Hello");
  getchar();
  return 0;
}
But finally I got the following error message:
>freeT.obj : error LNK2019: unresolved external symbol _FT_New_Face
referenced in function _main
1>freeT.obj : error LNK2019: unresolved external symbol _FT_Init_FreeType
referenced in function _main
Why? BTW, I tried to build with freetype253.dll and freetype253.lib and
succeed!

*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.
a) My program parses the glyph data during the *LOAD *time, and it's really
slow to load a ttf file if the file size is as big as tens of MB. In a
word, my ttf_parser is slow in *LOAD *time but fast in *FETCH *time. Maybe
it would be better if I delay the parsing process to *FETCH *time? But I am
also afraid of the trade-off -- the FETCH process might slow down.
b) I realized that lots of the information are stored sequentially and it's
easier for parsing if I don't break the file into pieces of tables.
Besides, I cannot pre-determine by how many simple glyph a specific
composite glyph is composed (is it?). To deal with it I should use
std::vector but I prefer not 'cause I will build my parser into dll and
using standard containers will cause some trouble.

Um.. I hope I described my question clearly. Any advise will be
appreciated! And I'll keep reading the source of freetype. Thanks for your
work.

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


Re: [ft-devel] (no subject)

2014-03-17 Thread Werner LEMBERG

> 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


[ft-devel] (no subject)

2014-03-17 Thread Taylor Holberton
HI,

I believe the CMakeLists.txt is missing:

include_directories("include")

I added it to a fork of mine because it there was an error that
reported a missing header. Adding this line fixed the error so
I suppose it might have got overwritten at some point.

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


Re: [ft-devel] (no subject)

2013-07-16 Thread Werner LEMBERG
>> 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)

2013-07-16 Thread octoploid


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)

2013-07-16 Thread 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.


Werner

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


[ft-devel] (no subject)

2013-07-08 Thread David Turner
Hello,

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.

On ARM, loading glyphs is about 3% faster, and rendering gray bitmaps is 6%
faster.
On x86_64, loading glyphs is 6% faster, and rendering gray bitmaps is 2.5%
faster.

The optimizations were found by inspecting the generated machine code in
hot spots.

Let me know if you find any issue.

- David

PS: Everything measured with:

./ftbench -p -t 5 -s 14 -f 0008 Arial.ttf

(0008 is FT_LOAD_NO_BITMAP)

ARM:


CFLAGS="-O2 -fomit-frame-pointer -march=armv7-a -mthumb" ./configure
--disable-shared --without-zlib --without-png --without-bzip2
--host=arm-linux-androideabi

Before:
  Load  34.287 us/op
  Load_Advances (Normal)34.317 us/op
  Load_Advances (Fast)  0.176 us/op
  Render23.544 us/op
  Get_Glyph 6.661 us/op
  Get_CBox  1.957 us/op
  Get_Char_Index0.261 us/op
  Iterate CMap  121.696 us/op
  New_Face  115.143 us/op
  Embolden  1.428 us/op
  Get_BBox  3.313 us/op

After:
  Load  33.358 us/op
  Load_Advances (Normal)33.330 us/op
  Load_Advances (Fast)  0.176 us/op
  Render22.079 us/op
  Get_Glyph 6.494 us/op
  Get_CBox  1.937 us/op
  Get_Char_Index0.232 us/op
  Iterate CMap  120.793 us/op
  New_Face  115.759 us/op
  Embolden  1.450 us/op
  Get_BBox  3.384 us/op

x86_64:
===

CFLAGS="-O2 -fomit-frame-pointer" ./configure --disable-shared
--without-zlib --without-png --without-bzip2

Before:
  Load  4.890 us/op
  Load_Advances (Normal)4.849 us/op
  Load_Advances (Fast)  0.027 us/op
  Render2.813 us/op
  Get_Glyph 0.473 us/op
  Get_CBox  0.076 us/op
  Get_Char_Index0.024 us/op
  Iterate CMap  13.982 us/op
  New_Face  12.341 us/op
  Embolden  0.027 us/op
  Get_BBox  0.303 us/op

After:
  Load  4.617 us/op
  Load_Advances (Normal)4.537 us/op
  Load_Advances (Fast)  0.028 us/op
  Render2.743 us/op
  Get_Glyph 0.441 us/op
  Get_CBox  0.076 us/op
  Get_Char_Index0.023 us/op
  Iterate CMap  13.508 us/op
  New_Face  12.298 us/op
  Embolden  0.027 us/op
  Get_BBox  0.296 us/op

x86:


CFLAGS="-O2 -fomit-frame-pointer -m32" LDFLAGS="-m32" ./configure
--disable-shared --without-zlib --without-png --without-bzip2

Before:
  Load  4.973 us/op
  Load_Advances (Normal)4.910 us/op
  Load_Advances (Fast)  0.023 us/op
  Render3.140 us/op
  Get_Glyph 0.641 us/op
  Get_CBox  0.243 us/op
  Get_Char_Index0.027 us/op
  Iterate CMap  15.303 us/op
  New_Face  13.041 us/op
  Embolden  0.167 us/op
  Get_BBox  0.527 us/op

After:
  Load  4.930 us/op
  Load_Advances (Normal)4.895 us/op
  Load_Advances (Fast)  0.023 us/op
  Render3.131 us/op
  Get_Glyph 0.620 us/op
  Get_CBox  0.237 us/op
  Get_Char_Index0.027 us/op
  Iterate CMap  15.051 us/op
  New_Face  13.133 us/op
  Embolden  0.163 us/op
  Get_BBox  0.524 us/op


0001-arm-Enable-FT_MulFix_arm-for-thumb2-compilation.patch
Description: Binary data


0002-x86_64-Optimize-FT_MulFix-for-x86_64-GCC-builds.patch
Description: Binary data


0003-arm-x86-x86_64-Optimized-TT_MulFix14-TT_DivFix14.patch
Description: Binary data


0004-arm-Improve-gray-rasterizer-performance.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] (no subject)

2012-05-08 Thread Werner LEMBERG

> 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


[ft-devel] (no subject)

2012-05-08 Thread Vladimiros Papaditsas
Hello,

I have found some port attempts of freetype2 for .NET and I try to set up a
working project of mine. My intention is to read the bytes of a generated
glyph's buffer. The problem is that when I try to create a .NET Bitmap
objects from these bytes I always get exceptions or garbage no matter what
alternatives I have used. With freetype I have tried two approaches :

Init_Freetype();
New_Face();
Set_Pixel_Sizes();
Get_Char_Index();
Load_Glyph();
Render_Glyph();

And then from the GlyphSlotRec structure that Render_Glyph() saves, I try
to read bitmap.buffer. My second approach is the following :

Init_Freetype();
New_Face();
Set_Pixel_Sizes();
Get_Char_Index();
Load_Glyph()
Get_Glyph();
Glyph_To_Bitmap();

And then with a typecast I get a Bitmap_Glyph structure object.

All the methods I mentioned above return 0 so there are no errors. And the
typecast seems ok. Obviously there is something wrong when i try to access
the bytes of the generated glyph like this :

glyph.bitmap.buffer.

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.

Any suggestions or hints?

Thanks,

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


[ft-devel] (no subject)

2010-08-06 Thread paul . forleo
I am doing an application where I need to use the Freetype library in a 
browser using Silverlight.  Problem is that Silverlight does not allow use 
of unmanaged code.  Has anyone ported the Freetype library to C#?   If 
not, I may do this myself.  Do you know of any problems I might run into 
if I do this? 
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


[ft-devel] (no subject)

2009-01-18 Thread Chi Nguyen
To freetype maintainers,

Included with this email is a bug report listing some deficiencies of the
freetype specification. These documentation issues still exist in the
documentation of version 2.3.8.

Please review and advise.



Thanks



Nguyen Trung Chi


NEC Solutions Viet Nam


V0024-Problem_Standard-freetype-2.1.10-Basic_Interface-Size_Management-Multiple_Masters.odt
Description: application/vnd.oasis.opendocument.text
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


[ft-devel] (no subject)

2006-04-18 Thread Patrick Hoffmann

Hi out there ( outside of windows :P ),

I've used your freetype library some years ago for a small emedded  
project. It's tiny but works nice. Good job!


Now I think about using your library for a second time. And before I start  
to test it in another embedded system, I have to link your lib to a  
windows test application. But linking your stuff is isn't easy and  
compiling too. This is why:


When I use the VC++ 7 build file that comes with your library, I can't  
link because of some unresolved externals:


my.cpp (ftinit.obj) : error LNK2001: unresolved external symbol  
_otv_module_class
my.cpp (ftglyph.obj) : error LNK2019: unresolved external symbol  
_FT_Bitmap_Copy referenced in function _ft_bitmap_glyph_init
my.cpp (ftglyph.obj) : error LNK2019: unresolved external symbol  
_FT_Bitmap_New referenced in function _ft_bitmap_glyph_init
my.cpp (ftglyph.obj) : error LNK2019: unresolved external symbol  
_FT_Bitmap_Done referenced in function _ft_bitmap_glyph_done


adding ftbitmap.c to the project fixed the Bitmap issues. But otv is a  
hard nut to crack! I've tried to add otvmod.c to the project, but then I  
got some more unresolved externals (one for example):


my.lib(otvmod.obj) : error LNK2019: unresolved external symbol  
_otv_JSTF_validate referenced in function _otv_validate


I've added otvjstf.c but then I get the following errors (one for example):

freetype-2.1.10\src\otvalid\otvjstf.c(100) : warning C4003: not enough  
actual parameters for macro 'OTV_NEST2_'
freetype-2.1.10\src\otvalid\otvjstf.c(100) : error C2059: syntax error :  
';'


The source of this error is (I cut it together):

// used defines
#define JstfMax otv_x_Ox, "JstfMax"
#define JstfLookup otv_GPOS_subtable_validate, ""
#define OTV_NEST2( x, y ) OTV_NEST2_( x, y )
#define OTV_NEST2_( func0, name0, func1, name1 )

// error code
OTV_NEST2( JstfMax, JstfLookup );

So the problem is that the preprocessor of my compiler tries to check the  
number of parameters of each macro call. And it collapses when you guys  
are juggling with your macro's parameters. For example: OTV_NEST2 gets two  
parameters. Each of them gets two parameters in one (e.g. JstfMax  
otv_x_Ox, "JstfMax"). And like if this isn't enough you follow these weird  
parameters to another macro called OTV_NEST2_ that takes 4 parameters.


Ok, maybe baby! If I would have written a C compiler, it surely would eat  
this code like I would eat vanilla ice cream :P. But I'm not sure about  
the "microcodies" at microsoft!


This e-mail is just to let you know that you have left the path of  
portable code (since some versions). I would suggest you to forbear to  
give more and more code to the preprocessor instead to the compiler.  
You're escaping C! ;)


If you can show me the line in the C Standard that is about this  
preprocessor behaviour, I'll follow up this message to microsoft. But if  
you can't, please fix that code!


Thanx!

--
Mit freundlichen Grüßen,

Patrick Hoffmann

PGP Public Key: www.patsite.de/ph.asc



Auszug aus einem Chatgespräch:
 Es gibt ein Leben außerhalb des Internets...!!!
 wtf?
 Link?


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


Re: [ft-devel] (no subject)

2005-06-06 Thread Werner LEMBERG

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

2005-06-05 Thread Kirill Kryukov
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


[ft-devel] (no subject)

2005-06-04 Thread Trevor Parscal
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".

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.

- Trevor Parscal




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


[ft-devel] (no subject)

2005-04-20 Thread scriptmagic
Dear Sir,
  I am working for a well known software devl. organization and 
currnetly working on a multilingual dos based product.For that we are using
One of your FREETYPE version (Freetype1.3.9).Since we found this is the
only version supporting TC (Turbo C) compilation. (If any other,Please let
us know.)And we found it is perfectly stable and working fine under TC
enviornment.We really appriciate stability of your product.
  But our ultimate aim is use it in TSR (Terminate & Stay Resident 
Program)under TC enviornment, where we are facing problems. We are unable to 
include FT in TSR. 

Different approches we tried are---
-Creating Freetype Lib,Include in TC project,It doesn't work since cant keep
lib in memory
-Inluding all freetype files to our application,Giving lot of errors
-Creating TC project and inluding all Freetype files in project.This 
compiles successfully,but unable call FT functions in TSR 

What we need is a TSR under TC enviornment using Freetype.
We are facing a lot problem.Please Help us out.Please send such TSR sample 
code if possible. 

Anticipating your valuable reply. 

Thank you 

-
Rahul H
Software Engg.
Image Point Tech. Pvt. Ltd. PUNE
INDIA. 


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