Re: [ft-devel] [Doubt] Error with STREAM_FILE function.
> > > I have added the code to my branch `parthw-wip`. > > OK, but... > > > Kindly check the output. > > ... please describe what you expect (using code lines), and what you > get. > When the gf driver enters the gf_load_font in gflib.c, if we use stream->descriptor.pointer to get the file pointer and comment out the fopen I get a segmentation fault. And if the fopen is used it works fine. Like here: FT_FILE *fp = (FT_FILE*)stream->descriptor.pointer ;/* Errors with STREAM_FILE( stream ) stream->descriptor.pointer is not allocating the file pointer properly*/ char* st = (char*)stream->pathname.pointer; fp=fopen(st,"rb"); ___ 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.
> I have added the code to my branch `parthw-wip`. OK, but... > Kindly check the output. ... please describe what you expect (using code lines), and what you get. Werner ___ 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.
> > >> I just need the file pointer outside the stream to extract the font >> >> specific values from the font file. The problem which I am facing >> >> is that the `stream->descriptor.pointer` is not returning a correct >> >> pointer to the file and thus causing errors. I tried finding the >> >> error in the FT_Stream_Open function but could not find the problem. >> >> And using fopen explicitly twice might create errors later. Can you >> >> suggest a better way to get the file pointer from the input stream? >> >> >I can't do that without seeing the actual code. Please post what you >> >want to do. >> > > Ok I will do that. Thanks! > I have added the code to my branch `parthw-wip` Kindly check the output. This code is not yet clean, please ignore that. I noticed a new file `descriptor` was created, I cannot realy understand how this file is generated and what is its utility. Please help. 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.
> > >> I just need the file pointer outside the stream to extract the font >> >> specific values from the font file. The problem which I am facing >> >> is that the `stream->descriptor.pointer` is not returning a correct >> >> pointer to the file and thus causing errors. I tried finding the >> >> error in the FT_Stream_Open function but could not find the problem. >> >> And using fopen explicitly twice might create errors later. Can you >> >> suggest a better way to get the file pointer from the input stream? >> >> >I can't do that without seeing the actual code. Please post what you >> >want to do. >> > > Ok I will do that. Thanks! > I have added the code to my branch `parthw-wip` Kindly check the output. This code is not yet clean, please ignore that. 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.
> > >> I just need the file pointer outside the stream to extract the font > >> specific values from the font file. The problem which I am facing > >> is that the `stream->descriptor.pointer` is not returning a correct > >> pointer to the file and thus causing errors. I tried finding the > >> error in the FT_Stream_Open function but could not find the problem. > >> And using fopen explicitly twice might create errors later. Can you > >> suggest a better way to get the file pointer from the input stream? > > >I can't do that without seeing the actual code. Please post what you > >want to do. > Ok I will do that. Thanks! ___ 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.
> I just need the file pointer outside the stream to extract the font > specific values from the font file. The problem which I am facing > is that the `stream->descriptor.pointer` is not returning a correct > pointer to the file and thus causing errors. I tried finding the > error in the FT_Stream_Open function but could not find the problem. > And using fopen explicitly twice might create errors later. Can you > suggest a better way to get the file pointer from the input stream? I can't do that without seeing the actual code. Please post what you want to do. Werner ___ 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.
> > >> 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. > > >Don't use FreeType internals outside of the library. Look into the > >FreeType demo file `src/ftcommon.c' for an example of file handling. > OK. But I am not using this outside the library but in the driver itself. >> I then did an explicit fopen on the filename later and my code ran > >> properly. > > >This sounds like the right solution. > >> Now the problem is that I cannot extract file pointer from the > >> stream. > > >Why do you need it? What problem do you want to solve? > I just need the file pointer outside the stream to extract the font specific values from the font file. The problem which I am facing is that the ` stream->descriptor.pointer` is not returning a correct pointer to the file and thus causing errors. I tried finding the error in the FT_Stream_Open function but could not find the problem. And using fopen explicitly twice might create errors later. Can you suggest a better way to get the file pointer from the input stream? > Also, if STREAM_FILE is already defined to be used to ease the > > process, then why is it showing undefined symbol? > > >Again: It is a macro, only *locally* defined (in `ftsystem.c'). If > >you use it in another file, the compiler treats it as an undefined > >symbol. > Ok. Now I get that. Thanks. -- 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
>> 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.
>
> Should I look at only changing inline code blocks, or all quotes (in
> input), then?
Well, `...' should be eventually resolved into `...` and '...'.
> Also, in the output, should we retain and (‘... ’)
> or should I change those to just single quotes ('..')?
I prefer `lsquo' and `rsquo'.
>> 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.
>
> It seems like there are 981 instances of quoted text in the docs. I
> will try to come up with a method to automate this, if possible.
>
> We can always do a manual cleanup later.
OK.
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
> 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.
>
Should I look at only changing inline code blocks, or all quotes (in input),
then?
If you want to retain (2) in the input, that will not be a problem because
we can change it in the output. Further, using 'foo' directly in input
should
also not cause any problems.
Also, in the output, should we retain and (‘... ’ ) or
should
I change those to just single quotes ('..')?
> 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.
>
It seems like there are 981 instances of quoted text in the docs.
I will try to come up with a method to automate this, if possible.
We can always do a manual cleanup later.
> 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.
>
Will fix this, thanks.
--
Nikhil
___
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.
> 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. Don't use FreeType internals outside of the library. Look into the FreeType demo file `src/ftcommon.c' for an example of file handling. > I then did an explicit fopen on the filename later and my code ran > properly. This sounds like the right solution. > Now the problem is that I cannot extract file pointer from the > stream. Why do you need it? What problem do you want to solve? > Also, if STREAM_FILE is already defined to be used to ease the > process, then why is it showing undefined symbol? Again: It is a macro, only *locally* defined (in `ftsystem.c'). If you use it in another file, the compiler treats it as an undefined symbol. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
