Re: [ft-devel] [Doubt] Error with STREAM_FILE function.

[Parth Wazurkar]

>
> >`STREAM_FILE' is a macro!  In other words, it must *never* appear as
> >an undefined symbol in the DLL.  Doing `git grep STREAM_FILE', I get
> >  ...
> >  builds/unix/ftsystem.c:  /* We use the macro STREAM_FILE for
> convenience to extract the   */
> >  builds/unix/ftsystem.c:#define STREAM_FILE( stream )  (
> (FILE*)stream->descriptor.pointer )
> >  ...
> >  src/base/ftsystem.c:  /* We use the macro STREAM_FILE for convenience
> to extract the   */
> >  src/base/ftsystem.c:#define STREAM_FILE( stream )  (
> (FT_FILE*)stream->descriptor.pointer )
> >  src/base/ftsystem.c:ft_fclose( STREAM_FILE( stream ) );
> >  src/base/ftsystem.c:file = STREAM_FILE( stream );
>
> >As can be seen, `STREAM_FILE' is only locally defined in
> >`builds/unix/ftsystem.c' and `src/base/ftsystem.c'.  If you want to
> >have such an abbreviation in a different source file, you have to
> >#define it.
>
> >What are you trying to do?
>

Actually I want to extract the file pointer from the input stream.
For this I initially used (FILE*)stream->descriptor.pointer to get the
pointer but it
did not allocate the pointer and gave a segmentation fault with fseek.
Later I figured about this macro STREAM_FILE to do the work but it showed
undefined symbol in the o/p.
Now I thought that there might be a problem with the
(FILE*)stream->descriptor.pointer
i.e. it might not be allocated the pointer in the first place.
I then did an explicit fopen on the filename later and my code ran
properly.
Now the problem is that I cannot extract file pointer from the stream.
Also, if STREAM_FILE is already defined to be used to ease the process,
then why is it showing undefined symbol?

Thank you

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

Re: [ft-devel] [Doubt] Error with STREAM_FILE function.

[Werner LEMBERG]

> The function STREAM_FILE used to extract file pointer from input
> stream is not working.  I also tried to use
> stream->descriptor.pointer directly but it also gives the same error
> with ftview. *(Error:
> */home/parth/freetype-demos-deve/bin/.libs/ftview: symbol lookup
> error: /home/parth/freetype-devel/objs/.libs/libfreetype.so.6:
> undefined symbol: STREAM_FILE).

`STREAM_FILE' is a macro!  In other words, it must *never* appear as
an undefined symbol in the DLL.  Doing `git grep STREAM_FILE', I get

  ...
  builds/unix/ftsystem.c:  /* We use the macro STREAM_FILE for convenience to 
extract the   */
  builds/unix/ftsystem.c:#define STREAM_FILE( stream )  ( 
(FILE*)stream->descriptor.pointer )
  ...
  src/base/ftsystem.c:  /* We use the macro STREAM_FILE for convenience to 
extract the   */
  src/base/ftsystem.c:#define STREAM_FILE( stream )  ( 
(FT_FILE*)stream->descriptor.pointer )
  src/base/ftsystem.c:ft_fclose( STREAM_FILE( stream ) );
  src/base/ftsystem.c:file = STREAM_FILE( stream );

As can be seen, `STREAM_FILE' is only locally defined in
`builds/unix/ftsystem.c' and `src/base/ftsystem.c'.  If you want to
have such an abbreviation in a different source file, you have to
#define it.

What are you trying to do?


Werner

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

[ft-devel] completed CPAL/COLR support

[Werner LEMBERG]

Folks,


the CPAL/COLR interface is now implemented and committed to git.
However, it is still mainly untested; I'm working on it the next days
– be warned that there might be issues.


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

>>> I do not like `quoted' text.

Do you mean in the input or in the output?  Right now, `...' in the
input has two purposes.

(1) It is used as a poor-man's substitute for inline code snippets –
the thing Nikhil is talking.

(2) It is *really* used for quotations, i.e., `foo' should be
converted to ‘foo’.  Note that I prefer ‘foo’ over “foo”, since it
is less intrusive to my eyes.

This should be disentangled.  However, I don't want to throw away (2)
completely.

>> I do have a suggestion - Changing variable names and inline code
>> snippets to `foobar` instead of `foobar'.  Markdown will add an
>> inline code block around the text (see attached image).
> 
> Yes, I would prefer this.

Me too.

> There was a reason to use different quotes, which I do not remember.

See (2).  `foo' is good old TeX tradition for quotation input.  It's
OK with me to change the `foo' style to 'foo' for (2) in the source
code, as used by markdown.

> Do we have to change the quote style or your scripts can do it?

While the majority of `...' is case (1), we have a lot of (2) also.
In other words, a fully automated conversion is not possible IMHO.

BTW, there is a buglet in the conversion script: Have a look at the
`note' section of

  
https://nikramakrishnan.github.io/freetype-site/ft2-glyph_management/#ft_get_glyph

The current code in the header file starts with

  Because `*aglyph->advance.x' and '*aglyph->advance.y' are 16.16 ...

Note how the stuff between the two `*' gets incorrectly converted to
italics in the HTML output.


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Alexei Podtelezhnikov]

>> I do not like `quoted' text.

> I do have a suggestion - Changing variable names and inline code snippets
> to `foobar` instead of `foobar'. Markdown will add an inline code block
> around the text (see attached image).

Yes, I would prefer this. There was a reason to use different quotes,
which I do not remember. Do we have to change the quote style or your
scripts can do it?

Thanks!
Alexei

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> It is nice that most ordered and unordered lists are picked up. Is it
> described somewhere what is recognized as a list?


For now any list style supported by markdown should work except in
field tables (there is a problem with ordered lists right now, but I am
working to fix this). You can expect any format given in this
handy cheatsheet to work:
https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#lists


> I do not like
> `quoted' text. Can we use italics instead of quotes?
>

This depends on how we want to handle quoted text. There is already a
format for italics (underscore), and things like variable names would
look weird in italics.
I do have a suggestion - Changing variable names and inline code snippets
to `foobar` instead of `foobar'. Markdown will add an inline code block
around the text (see attached image).

Any thoughts?

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

>> * In the `fields' subsection of each element, please reduce the
>>   space between the elements.  In most cases, the descriptions are
>>   only a single line, and (at least with my Chrome browser) this
>>   takes too much vertical space IMHO, see attached image.
> 
> I have reduced the space. Please check!

Better, thanks!


Werner

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> Right now I've noticed only two issues.
>
> * Looking at
>
> https://nikramakrishnan.github.io/freetype-site/ft2-toc/
>
>   I wonder why the `Docs' link in
>
> Docs » Table of Contents
>
>   points to the index.  Is this intentional?  I assume this is a
>   temporary decision, since later on we mount the whole reference into
>   the FreeType tree so that `Docs' links to
>
> https://www.freetype.org/freetype2/docs/documentation.html
>
>   or something similar, right?
>

This is temporary. I wanted a valid internal link for now, and I will
point this to the documentation link later.


> * In the `fields' subsection of each element, please reduce the space
>   between the elements.  In most cases, the descriptions are only a
>   single line, and (at least with my Chrome browser) this takes too
>   much vertical space IMHO, see attached image.
>

I have reduced the space. Please check!


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

[ft-devel] [Doubt] Error with STREAM_FILE function.

[Parth Wazurkar]

Hi all,
The function STREAM_FILE used to extract file pointer from input stream is
not working. I also tried to use stream->descriptor.pointer directly but it
also gives the same error with ftview. *(Error:
*/home/parth/freetype-demos-deve/bin/.libs/ftview:
symbol lookup error: /home/parth/freetype-devel/objs/.libs/libfreetype.so.6:
undefined symbol: STREAM_FILE).
Please help.
Thank you

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Alexei Podtelezhnikov]

On Tue, Jun 12, 2018 at 8:26 AM, Nikhil Ramakrishnan
 wrote:
> * The complete API documentation site is now available on
> https://nikramakrishnan.github.io/freetype-site/ft2-toc/
> This was generated using docwriter with the header files
> updated to commit b18f5e7c62c0aa6f8d17cbb9a8fe687ed402569a.

This looks really nice. I can see all my errors in
https://nikramakrishnan.github.io/freetype-site/ft2-lcd_rendering/,
which I actually want to move from Support API to Controlling FreeType
Modules.

It is nice that most ordered and unordered lists are picked up. Is it
described somewhere what is recognized as a list? I do not like
`quoted' text. Can we use italics instead of quotes?

Thanks,
Alexei

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

Hello Nikhil!


> * Also, docwriter
>   (https://github.com/nikramakrishnan/freetype-docwriter) can now
>   output Markdown, and I am in the process of writing code to
>   automatically generate the `yml' configuration file required by
>   MkDocs.

Great!  Will check that within the next few days.

> Please also let me know of any problems you notice with the
> website, and any other comments.

Right now I've noticed only two issues.

* Looking at

https://nikramakrishnan.github.io/freetype-site/ft2-toc/

  I wonder why the `Docs' link in

Docs » Table of Contents

  points to the index.  Is this intentional?  I assume this is a
  temporary decision, since later on we mount the whole reference into
  the FreeType tree so that `Docs' links to

https://www.freetype.org/freetype2/docs/documentation.html

  or something similar, right?

* In the `fields' subsection of each element, please reduce the space
  between the elements.  In most cases, the descriptions are only a
  single line, and (at least with my Chrome browser) this takes too
  much vertical space IMHO, see attached image.


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

[ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

Hi all,

* It's been 4 weeks since the coding period for GSoC began and
I have written another status update for weeks 3 & 4:
https://github.com/nikramakrishnan/freetype-docs/wiki/GSoC-Status-Update:-Week-3-&-4

* Also, docwriter (https://github.com/nikramakrishnan/freetype-docwriter)
can now output Markdown, and I am in the process of writing
code to automatically generate the `yml' configuration file
required by MkDocs.

* The complete API documentation site is now available on
https://nikramakrishnan.github.io/freetype-site/ft2-toc/
This was generated using docwriter with the header files
updated to commit b18f5e7c62c0aa6f8d17cbb9a8fe687ed402569a

.

I am in the process of implementing changes and fixing
bugs suggested/reported on the mailing list previously.

Please also let me know of any problems you notice with the
website, and any other comments.

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