> I tested your new professional Makefile in WinUAE (Amiga OS 4.1
> Classic) on a PC in the afternoon and now on my AmigaOne and got the
> same following output:
>
> freetype/builds/amiga> make
>
> assign FT: //
> make: *** No rule to make target `ftbase.ppc.o', needed by `libfreetype.a'.
>
> I write a "new" Makefile (freed from a lot of "brick-a-brack" and
> tested) for building FreeType Library easily on an AmigaOne (AmigaOS
> 4.1 Final Edition Update 1): attached "Makefile".
Thanks!
> It makes a "libfreetype.a" (linked with ftinit.ppc.o and
> ftsystem.ppc.o, too) static library
> The bitmap dimensions. For a 'g' glyph opentype outline for
> instance, if I load it and render it using the LCD(RGB) related
> options, the resulting bitmap dimensions are the bounding box of the
> glyph. Is this true for any glyph outline rendering mode
> (monochrome, grayscale..)?
I
> let me reformulate: is "glyph hinted bounding box" always the output
> bitmap of any render operation?
It's still not clear to me what you are after, sorry. Are you talking
about the metrics? The actual bitmap dimensions?
Again: Please provide an example what you want to achieve.
>>> I think it would be possible for FT_Load_Glyph to implement this
>>> operation on its own without FT_Property_Set. Is there any plan
>>> that the Freetype will provide this characteristic?
>>
>> This is issue https://savannah.nongnu.org/bugs/?43380.
>
> I would like to ask you to solve
> Is this expected that lcd loading and rendering is done on the R/G/B
> glyph biggest bounding boxes or am I using freetype wrongly?
I don't understand the question. Please give an example.
Werner
___
Freetype mailing list
Freetype@nongnu.org
> In the runtime, what is the appropriate way to render the MS legacy
> fonts(Tahoma, Arial, ...) as v35 and the MS ClearType
> fonts(Consolas, ...) as v40? Microsoft Windows GDI displays two
> types of fonts at the same time.
>
> PSEUDO CODE:
>
> gasp_version = get_gasp_version( font
> First of all, thanks for the quick reply, but I think you miss the
> point a little bit, because I wrote that I managed to compiled
> FreeType library in the end:
OK. Can you provide a patch that updates the Amiga stuff? Maybe
contributing a new Makefile, if necessary...
>
Hello Károly!
> I would like to make an SDL application using SDL_ttf which is
> wrapped in FreeType library, so I downloaded it and try to compile
> on my AmigaOne with SDK and I type what the README says: "make -f
> makefile.os4", in turn the following error has occured: [...]
You are the
> I spotted a problem in the code where a returned error is not being
> handled correctly.
>
> The patch is already submitted in Ghostscript and can be found here :-
> http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=d0abc92713b2e84eb32c67839ddec2d160b3af8d
Thanks, applied!
Werner
[Ankit, please always reply to the list.]
Thanks for the first draft of a patch!
> > The meaning of the EID values depending on PID are given in
> >
> > https://docs.microsoft.com/en-us/typography/opentype/spec/cmap
> > https://docs.microsoft.com/en-us/typography/opentype/spec/name
>
>
Sorry for the late reply.
>> * I think it would be best if all the information is present in a
>> single window. If necessary, there could be tabs to split the
>> contents into smaller chunks.
>
> I have attached the new patch as per above suggestion, please have a
> look and suggest
Sorry for the late response.
> As a side note, would it be OK to:
>
> (a) modify the glnames script to use python3? python 2.x will be
> EOL soon.
If preserving compatibility is *extremely* hard, this is OK – the
generated data will be committed to the repository. On the other
hand, if
> I remember adding and removing this for some reason... Guess I'll
> find out at the next update.
OK :-)
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
> On Windows, you need to specify RUNTIME DESTINATION to install() in case
> of DLL builds.
Patch applied, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
> Maybe the web page regarding FT layout should be updated.
URL, please. AFAIK, we already point to HarfBuzz, telling the reader
that the `OpenType layout' library is deprecated.
Werner
___
Freetype mailing list
Freetype@nongnu.org
> What's happening to the FT layout lib?
>
> Dead or indefinitely postponed or still going?
Dead. We decided that handling layout tables like GPOS and GSUB must
be done at least one level higher than FreeType.
Werner
___
Freetype mailing list
> I wrote to you previously back in August (actually to the developer
> email on FreeType) and your information was very helpful. I was
> hoping you can steer me in the right direction again, and I
> apologize if this is the wrong place to send the e-mail.
I'm directly forwarding this to the
>> [...], please outline with a few words how you are going to
>> implement the compression.
>
> The size reduction is a result of several optimizations: [...]
Looks good, thanks. I assume that this will be a modification to the
existing `glnames.py' script, right? Please ensure that the
> I've recently came across ft_adobe_glyph_list array which is a 56kB
> table. It seems that it's possible to compress it better by
> extracting duplicate substrings possibly at some small performance
> cost.
>
> My preliminary calculations put the size of the optimized table
> somewhere
>> People can always run the hinter in paranoid mode, rendering a
>> glyph without hinting if an error is returned...
>
> Can you elaborate on this? How does one run the hinter in paranoid
> mode? I'm wondering if it would be possible/useful to do this in
> Xpdf (or at least provide an option
> This patch adds the basic functionality of ftdump in ftinspect.
> More changes/features will be added in subsequent patches.
Very nice! Do you plan to work more on ftinspect? This would be
great!
> Please have a look & suggest the required changes for refinement of
> this patch.
Some
> Btw, been wondering if something could/should be done on freetype
> too - while we know where the broken hinting instructions came about
> in this case, similar problem can come from a different source too.
People can always run the hinter in paranoid mode, rendering a glyph
without hinting
> Werner asked me about this a few days ago and since there are a few
> people using this repo I thought it is worth mentioning it in the
> ft-devel list: I just added `ccache' support to `freetype-testing'
> (https://github.com/freetype/freetype2-testing).
Thanks for the quick implementation!
>> Uh, oh. It's a regression in ttfautohint – version 1.7 works fine,
>> version 1.8 and higher fails. Now fixed in git.
>
> This explains why Fedora 27 with ttfautohint 1.7 was fine: dots were
> there but sometimes distorted.
Yep.
> I wonder if such short stems should ever be hinted.
>> I've downloaded the working Lohit Devanagari font from
>>
>> https://releases.pagure.org/lohit/lohit-devanagari-ttf-2.95.4.tar.gz ;
>>
>> it has
>>
>>
>>
>> in the `head' table.
>
> Okay, mine says 14 Feb 2018. Then I went to fedora's build farm to
> see how/what exactly have they done to
>> BTW, using the current version of Lohit Devanagari (2.95.4), which
>> has been hinted with a newer version of ttfautohint, the rendering
>> is OK.
>
> Hmm, the versioning doesn't help - the one ships by fedora also says
> 2.95.4 in the name table. Now that we know what to look for, I can
>
>> I was able to reproduce the missing dots with ftview in the
>> embedded file RSOAVR+Lohit-Devanagari.ttf (attached, they are OFL).
>> With native default hinter enabled, some dots are always missing
>> with sizes less than 57. There is no problem with autohinter or
>> with hinting disabled.
Hello Alexei!
> I finished text carpeting and waterfall modes in ftstring, keys '2'
> and '3' respectively. The goal is to remove these modes from ftview
> so that it becomes purely about font content and rendering, whereas
> ftstring demonstrates rudimentary layout features including kerning.
>> I have an installation of bzip2. Same is recognized by freetype2
>> configure script (using autoconf test) but not by pkg-config.
Another possibility is that your GNU/Linux distribution doesn't
provide a `bzip2.pc' file. In this case you should create such a file
by yourself and put it into
>>> I have an installation of bzip2. Same is recognized by freetype2
>>> configure script (using autoconf test) but not by pkg-config.
>
> Another possibility is that your GNU/Linux distribution doesn't
> provide a `bzip2.pc' file. In this case you should create such a file
> by yourself and
> I tried the compilation of ftinspect program but it is giving:
> ```
> Project ERROR: bzip2 development package not found
> ```
> I have an installation of bzip2. Same is recognized by freetype2
> configure script (using autoconf test) but not by pkg-config.
Often, there also exists a
>> Using `size_t' makes sense, yes.
>
> I applied the change but decided to stay away from ftdbgmem.c.
Thanks.
> What is its purpose anyway in the World of valgrind and other tools?
Embedded systems, I guess.
Werner
___
Freetype-devel mailing
>> >> Indeed, size_t is the correct C89-compliant type. Would it hurt
>> >> to modify FT_Alloc_Func and FT_Realloc_Func?
>>
>> Looks good! Provided we can use it without breaking the ABI, please
>> proceed.
>
> The ABI checker report is attached. The change is noticed but
> permitted, I think.
> We noticed a few very small differences in the font metrics we were
> getting for digits. [...]
>
> If we change our local copy of your code to the following and we are
> able to produce consistent results between releases 2.6.0 and 2.6.1:
>
> FT_LOCAL_DEF( FT_Bool )
>
> Not yet, thanks. I'll first try to update the `rules.mk'.
I've now updated the description of `X11_PATH' in this file to be as
concise as possible.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
> I installed ubutnu 18.04 in a virtualbox and tested this there too,
> initially it returned error with `make X11_PATH=/usr/include' then I
> found out `libx11-dev' was missing, so I installed it and then when
> I did `make X11_PATH=/usr/include' it allocated display surface and
> demo program
>> > This
>> >
>> > make X11_PATH="/usr/include \
>> > /usr/lib/x86_64-linux-gnu/X11/rstart/commands/x11r6"
>> >
>> > worked for me.
>>
>> Thanks. The latter part looks strange.
>
> You were right, Ubuntu switched to Wayland. We might need a port.
While this is probably a good
> When loading with DejaVuSans.ttf with FT_LOAD_NO_RECURSE there are
> glyphs that have format as FT_GLYPH_FORMAT_COMPOSITE, but the
> metrics are the same as when loaded without FT_LOAD_NO_RECURSE. On
> the other hand in that .ttc file loading with FT_LOAD_NO_RECURSE
> makes all the metrics as
> libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
> (0x7f40192d7000)
>
> Also, `libx11-dev' is properly installed, and `libX11.so' files are
> located in `/usr/lib/x86_64-linux-gnu/'.
Have a look into `graph/x11/rules.mk'. There you can see the
locations where make searches for
> Specifically (as an example, but this file NotoSansCJK-Regular.ttc
> behaves this way on nearly all glyphs), loading the glyph #41 with:
>
> FT_LOAD_NO_SCALE | FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP |
> FT_LOAD_IGNORE_TRANSFORM | FT_LOAD_LINEAR_DESIGN
>
> gives the width and height of
> So is it possible to get accurate width and height of (width and
> rows) of what the bitmap will be without having to use
> FT_LOAD_RENDER and if so how?
No. Please read the `note' section in
https://www.dxdy.ooo/freetype-web-jekyll/docs/reference/ft2-base_interface.html#ft_size_metrics
>> %p is implementation defined, perhaps %#p will prefix 0x on all
>> %platforms.
>
> Nice idea!
Hin-Tak, can you try this and update your patch if it works?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
>> besides the prototype, some of the printf's also needs changing as
>> size_t is larger than %ld.
>
> %zu should work for gcc and VC2015 and up.
... probably to be realized with a conditional macro.
> %p is implementation defined, perhaps %#p will prefix 0x on all
> %platforms.
Nice idea!
>> Indeed, size_t is the correct C89-compliant type. Would it hurt to
>> modify FT_Alloc_Func and FT_Realloc_Func?
>
> Ping! (with a patch)
Looks good! Provided we can use it without breaking the ABI, please
proceed.
Werner
___
Freetype-devel
>> - FT_Alloc_Func and FT_Realloc_Func have "long" in the headers but
>> have FT_Long in the implementation of the debug pairs. (the
>> normal pair have "long"). Some consistency would be good. I
>> tried changing the header to FT_Long (and redefining FT_Long to
>> 64-bit) but
> I've successfully compiled freetype on Windows 10 within a Cygnus
> environment, creating an archive lib and then building the demos
> from that. When I execute ftview.exe,
> frinit.c/grInitDevices()/chain is null, causing grNewSurface() to
> return null, and generating the "could not
>> Yep. Alexei, do you want to take care?
>
> Done, without color.
Thanks for the quick action! I still would like to have an indication
somehow that we have a zero-width glyph – if not by color, then maybe
a suffix to the glyph name.
> Is it safe to say the zero-width glyphs do not have a
>> >> IMHO, there should be some default width for glyph having zero
>> >> width. What's your opinion?
>>
>> Another suggestion: zero-width glyphs get a default spacing (say,
>> the width of the space glyph), and are coloured.
>
> 0.5 Em is about the width of space but readily available.
> I suggest you wipe out your git repositories, get clean copies, and
> build everything from scratch. You have nothing to lose.
And you should check whether you can compile any other (simple) X11
program.
Werner
___
Freetype-devel mailing list
>> Please send the output of `ldd /path/to/installed/ftview'.
>
> linux-vdso.so.1 => (0x7ffd9c5fb000)
> libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x7f4019611000)
> libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f40192d7000)
> libc.so.6 =>
> After updating from git master this morning, I'm finding a
> compilation error in 'builds/windows/ftdebug.c' when I try to build
> with MSVC. It gives me an error at line 114:-
>
> /* array of trace levels, initialized to 0 */
> int ft_trace_levels[trace_count]; // <--- compilation
>> IMHO, there should be some default width for glyph having zero
>> width. What's your opinion?
>
> 1/2 ppem?
I don't understand that. Please elaborate.
Another suggestion: zero-width glyphs get a default spacing (say, the
width of the space glyph), and are coloured.
Werner
> Maybe an X11 library is missing.
Thanks for the files.
Please send the output of `ldd /path/to/installed/ftview'.
Please also send the result of
make &> make.log
(for the demo programs)
And finally, where is your `libX11.so' file (or files)?
Werner
> In freetype2-demo "ftview" program, for some character
> (unic300,301,302...) are clustering in OpenSans fonts. Is this
> intended behaviour or bug in the demo program.
It's intended behaviour (well, let's say that `ftview' is rather
dumb :-). Those glyphs all have zero width.
Werner
>> What do you think of calling this file `DOCGUIDE'?
>
> Sounds good, should I add it?
Yep.
> Any other formatting requirements?
I don't think so.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
>> Thanks. Just curious: Where can I find the fix for @foo to be
>> displayed with ...?
>
> Just released in docwriter 1.0.2.
OK, thanks.
>> I've just done some minor improvements in
>>
>> https://github.com/nikramakrishnan/freetype-docs/wiki/Documentation-Guidelines-for-The-FreeType-Project
>> Have you already pushed the changes to the repository?
>
> Not yet, will do it today.
Thanks. Just curious: Where can I find the fix for @foo to be
displayed with ...?
> Oh, and is there anything left to add in the `DOCUMENTATION' file?
I've just done some minor improvements in
>> Are you running an X server? Some GNU/Linux boxes use Wayland
>> instead; on such machines X11 must be handled separately.
>
> Yes, I am running X11, I checked with `echo $XDG_SESSION_TYPE',
> although many ubuntu distributions use wayland instead. Still, it
> is causing the same problem,
>> Currently, the options for demo programs are shown in the menu
>> opened by '?', so a readme for freetype2-demos programs explaining
>> the demo programs and their options would be great. Compared to
>> freetype2 library comments can be improved in freetype2-demos for
>> better readability
> Recently my pc got corrupted, so I had to format it, I currently
> have ubuntu 18.04 installed. Now, everytime I am using any demo
> program it is ending in,
>
> could not allocate display surface
> error = 0x, no error'
Are you running an X server? Some GNU/Linux boxes use Wayland
>> Attached is another example from the `note' section of the description
>> of `FT_GlyphSlotRec' (100% default size using Chrome).
>
> Ah, this is only reproducible on Chrome. Firefox ignores word break
> rules. A little searching and experimenting gave me the answer.
> Should be fixed now!
> A cursory search on GitHub
>
> https://github.com/search?q=FT_Outline_Done_Internal=Code
>
> says that the two functions at least seem to be part of Servo’s
> FreeType bindings
>
>
> https://github.com/servo/rust-freetype/search?q=FT_Outline_Done_Internal_q=FT_Outline_Done_Internal
Hmm,
> What would speak against going to 7?
AFAIK, using 7 implies that all applications using version 6 no longer
get DLL updates. Instead, they have to be relinked.
Note that FreeType uses 6 since almost 20 years.
Werner
___
Freetype-devel
>> The links `FT_Get_Char_Index' or `FT_Load_Char' point to functions
>> (i.e., defined with `@function:' and should thus be displayed with
>>
>
> Just implemented this. Please check.
Excellent, thanks!
>> BTW, I see
>>
>> face-
>> >num_charmaps
>>
>> i.e., a line break after the `-'
> I now wonder whether I should revert the patch. I'm almost 100%
> sure that no application uses it. However, removing a public API
> can be problematic since it normally implies a shift from
> `libfreetype.so.6' to `libfreetype.so.7'...
To ask differently: Is it OK to stay with
In commit 9be656b I've just removed FT_Outline_New_Internal and
FT_Outline_Done_Internal, two completely undocumented functions that
were in the public API by accident only (but this since many, many
years).
I now wonder whether I should revert the patch. I'm almost 100% sure
that no
I do really believe that the call to
> `FT_Done_Glyph' is the source of much confusion (at least for me).
Again, please provide a patch that we can work on.
Werner
2018-09-01 Werner Lemberg
* src/base/ftglyph.c (ft_bitmap_glyph_init): Disallow deep copying.
Right now, calling `FT_Get_Glyph
>> ??? FT_Renderer_GetCBoxFunc *is* documented and implemented.
>
> It only says that it is "a method used to access the glyph's cbox."
> Its arguments are not described. I wish it was the same as
> FT_Renderer_RenderFunc, as if it "renders" only bitmap dimesions,
> which is a sort of cbox.
>> Ah, this is a slight issue I'm not happy yet in the docs. I think
>> this should rather be
>>
>> /** ...
>>* ...
>>* @description:
>>* Uses `a` to meep `b`.
>>* ...
>>*/
>>
>> In general, `@foo' should also use a typewriter face if it links to
>> C stuff like
> I am thinking about breaking this function into pieces associated
> with different renderers. I am thinking of using
> FT_Renderer_GetCBoxFunc for that. Notice that it is neither
> documented nor actively used internally.
??? FT_Renderer_GetCBoxFunc *is* documented and implemented.
> I
> Thanks for the comfirmatoon; those index values are they valid for
> using as indices into the parent FT_Outline.points array?
It's a cumulative process.
(1) Start with an empty outline.
(2) Take subglyph 0 (with n0 points having indices 0, 1, 2, ..., n0-1)
and add it according to the
> // match l-th point of the newly loaded component to the k-th point
> // of the previously loaded components.
>
> so in this case, it means that p1 is the base_points[arg2] where
> base_points is the points of the outline of the parent glyph and p2
> is sub_glyph[arg1] where sub_glyph is
> I am trying to load glyph’s geometric data with FT_LOAD_NO_RECURSE.
> The entry point FT_GetSubGlyphInfo() has almost what I needed, but
> not quite. It does provide the 2x2 matrix, but not the translation
> (at least when I read the docs and FreeType source code). [...]
The FreeType
> If you take
> https://raw.githubusercontent.com/freetype/freetype2-testing/master/fuzzing/README.md
> as an example (I know it's markup, but still), "hard 72" (or 78 for
> that matter) has/would have several impacts:
Well, tabular material, URLs, etc. can't be represented within 78
lines in
> Cross referencing the other thread: should I change 'error_string'
> to `error_string`?
For consistency with the rest of the API documentation: Please no.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
>> Ah, this is due to my formatting using Emacs, which has a default
>> line width of 72 chars. For the sake of consistency the style
>> guide should rather mention to use 78 chars. On the other hand, a
>> well-formatted document with a shorter line length doesn't hurt...
>
> Nooo ://
>> I've attached the `docs/DOCUMENTATION' file (from the draft work at
>> https://github.com/nikramakrishnan/freetype-docs/wiki/Documentation-Guidelines-for-The-FreeType-Project).
>> This should cover everything needed to understand the basics and
>> the markdown formatting of the docs.
>
>
terrors.c b/src/base/fterrors.c
new file mode 100644
index ..476f20ff
--- /dev/null
+++ b/src/base/fterrors.c
@@ -0,0 +1,45 @@
+/
+ *
+ * fterrors.c
+ *
+ * FreeType API for error code handling.
+ *
> Please find my first proposal for `FT_Error_String' attached.
Nice, thanks!
> Feel free to request any changes; not only but especially regarding
> documentation.
We now use our special Markdown flavour for documentation (in
particular no longer `xxx' but either `xxx` or 'xxx', depending on
> i would like to know the status of the VF driver (which was a part
> of the work for GSoC if I'm not mistaken)
It's currently unfinished. Parth has just written to me that he wants
to continue with coding soon after finishing his current exams.
Hopefully, there will be something real within
>> Reason of the failure is that there isn't a `markdown'
>> subdirectory. To have a functional `reference' directory tree I
>> thus suggest that the files and directories from srcdir's
>> `reference' tree get copied to builddir.
>
> Should be fixed in the attached patch. Please test!
LGTM,
>> FT_Load_Glyph( face, 0, 0 );
>> FT_Get_Glyph( face->glyph, );
>>
>> FT_Glyph_Copy( reference, );
>> ...
>> FT_Done_Glyph( glyph1 );
>>
>> FT_Glyph_Copy( reference, );
>> ...
>> FT_Done_Glyph( glyph2 );
>>
>> FT_Done_Glyph( reference );
>
> Mhm; I mean I get it -- changing to deep
>>> Please keep FT_Get_Glyph light.
>>
>> Why?
>
> Because it is meant to be used once followed by as many
> FT_Glyph_Copy as you want.
OK. Armin, can you change your usage pattern to something like the
following?
FT_Load_Glyph( face, 0, 0 );
FT_Get_Glyph( face->glyph, );
>>> (3) Make `FT_Get_Glyph' always do a deep copy. Add new function
>>>`FT_Get_Glyph_Lazy' to do a lazy copy if it holds a bitmap
>>>object.
>>
>> I would like that very much :)
>
> FT_Glyph_Copy would do deep copy.
It already does. However, it isn't a replacement for `FT_Get_Glyph'
>> (1) Avoid lazy copying in `FT_Get_Glyph'.
>
> How frequently is `FT_Get_Glyph' used and in which context?
Within FreeType it's used only once. However, the demo programs use
it quite frequently.
>> (2) Update the documentation:
>>
>> By default, `FT_Get_Glyph' can be used only
> (2) Update the documentation:
>
> By default, `FT_Get_Glyph' can be used only once. If you
> want more copies, use either `FT_Copy_Glyph' or call
> `FT_GlyphSlot_Own_Bitmap' before calling `FT_Get_Glyph' again.
Oops! This must rather be the following.
By default,
> Sure, no worries; you can find a tiny C function + build script
> attached. Please make sure to build FreeType with `clang' and
> `-fsanitize=address' for it to work :)
Thanks. I see two possibilities to fix the bug.
(1) Avoid lazy copying in `FT_Get_Glyph'.
(2) Update the documentation:
The title says it all.
$ mkdir freetype2.compiled
$ cd freetype2.compiled
$ .../path/to/freetype2/configure
$ make refdoc
Running docwriter...
python3 -m docwriter \
--prefix=ft2 \
--title=FreeType-2.9.1 \
--output=.../freetype2.compiled/reference \
>> Looks like a bug. Please provide a simple compilable example that
>> I can use for debugging.
>
> Sorry, sure, I forgot! You could use `2018-08-20-bitmaps' on my private
> fork like:
>
> $ git clone https://github.com/cherusker/freetype2-testing.git
> cherusker-freetype2-testing
> $ cd
>> I've created 4 patches:
>>
>> 1. Script translation to markdown, line normalization and manual
>>fixes.
>>
>> 2. Add resources for docwriter.
>>
>> 3. Remove `docmaker' code.
>>
>> 4. Changes to the build system.
>>
>> Please see the attached compressed file.
>
> Will check soon, thanks.
> I've created 4 patches:
>
> 1. Script translation to markdown, line normalization and manual fixes.
>
> 2. Add resources for docwriter.
>
> 3. Remove `docmaker' code.
>
> 4. Changes to the build system.
>
> Please see the attached compressed file.
Will check soon, thanks.
>> Similarly, I ask
Nikhil,
let's do the conversion to Markdown! Please prepare a series of
patches for a final inspection (probably compressed to save
bandwidth).
(1) The mechanical translation with the python script(s).
(2) The necessary manual corrections and updates.
(3) The necessary script updates and
> I'm still working on the bitmaps and just ran into an interesting
> access violation that happens with using the API exactly (?) as it
> is intended to:
>
> FT_Load_Glyph( face, index, load_flags );
>
> FT_Get_Glyph( face->glyph, );
> FT_Done_Glyph( glyph );
>
> FT_Get_Glyph(
>> I wondered if I can feed it the same bitmap twice.
>
> The cost-benefit analysis is in order. Is it worth checking a great
> number of valid uses to capture the invalid one? [...]
I've now slightly improved the documentation. Please check whether it
is more clear.
Werner
> However, I am not sure if I completely understand the other thing:
> do you prefer the solution by `N. Yoda' on StackOverflow (1) or the
> solution presented in `fterrors.h' (2)? (the latter uses the array,
> the former uses a switch/case)
I don't care. What I dislike is that the #... lines
>> GF provides a natural order of glyphs within the font file, we call
>> this `glyph indices'. Each glyph index is associated with a file
>> offset. For each glyph, GF assigns a character code to it. We
>> thus have immediately a mapping from glyph indices to character
>> codes.
>
> My changes
>>> https://stackoverflow.com/questions/31161284/how-can-i-get-the-corresponding-error-string-from-an-ft-error-code
>>>
>>> is the best solution
>>
>> It is, but the code formatting in the link is extremely ugly and
>> thus hard to read and understand.
>
> What don't you like about the
> I wonder what's the best solution to get FreeType's error strings
> from its error numbers? E.g. "cannot open resource" from
> `FT_THROW( Cannot_Open_Resource )'. Since I cannot locate anything
> in the docs
This must be an oversight on your side, since FreeType comes with a
complete
ttload:2: tt_face_load_font_dir: 0x20aa9d0
ttload:2: -- Number of tables: 23
ttload:2: -- Format version: 0x0001
>>>
>>> It is ok, but a little bit redundant.
>>
>> What exactly do you mean with `redundant'? Sometimes, the tracing
>> output of `any:7' can be
1101 - 1200 of 5353 matches
Mail list logo
