Hi Werner,
I went through the GSoC 2017 implementation of the `test-famework' project.
* Some ideas like, using Murmur hash, using CSS sprite sheets for images
are well discussed previously and spending time again for them will just be
like reinventing the wheel.
* So, I feel instead of starting
>
> >> > 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. [...]
> >
> > any news about these drivers ? still unfinished ?
>
> Alas, no progress. Parth?
>
Yes, This semester has been a lot
>
> > 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.
>
Thanks :-)
Parth
___
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
> >
>
> > 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. I'm rather sure that this is
>> *not* a standard directory for X11 libraries. Are there no soft
>
> > 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. I'm rather sure that this is
> *not* a standard directory for X11 libraries. Are there no soft links
>
>
> > 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
>
> > 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
>
> > which when compared to a correct compilation, has a
> > difference of these libraries,
> >
> > libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
> (0x7f40192d7000)
> > libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
> (0x7f40188ac000)
> > libdl.so.2 =>
I tested the compilation on a fresh ubuntu 18.04 box,
and `ft2-demos' are not allocating a display surface.
Here is the output of `ldd path/to/installed/ftview':
linux-vdso.so.1 (0x7fff350b1000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(0x7f252ae51000)
>
> > 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.
>
It worked! :-)
I have been rigorously tweaking into it and don't know what
>
> >> 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 =>
>
> 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 =>
>
> > These are running totally fine.
> >
> >> Maybe an X11 library is missing. BTW, tracing with FT2_DEBUG doesn't
> >> help in this case, since the error is not located in the FreeType
> >> library.
> >
> >
> > Yes.
>
> Yes or no?
>
`libX11-devel' is properly installed and is up to date.
Your
>
> >> 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
>
> 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 of code.
Hi all,
Following are the changes to be completed in the GF
driver, which I will be implementing in the coming days:
1. Solving the `cmap' problem.
2. Adding artificial glyphs in the GF driver.
3. Using the `xxx' and `yyy' information to derive the `cmap'
scheme.
Please suggest any more changes
>
> Well, the glyphs aren't `loaded'; you are rather collecting the file
> offsets in an array.
>
Yes.
> > It loads glyphs in the increasing order of their character code.
>
> Not necessarily: The order of `char_loc' commands could be arbitrary,
> say,
>
> Character 3: dx 3801088 (58), width
>
> > After some debugging, I found out that, I was using binary search on
> > the encodings array in the `char_index' function, although it wasn't
> > sorted (so foolish of me :( ). Now, fixed! Thanks.
>
> In the commit message, you write
>
> Use `linear search' instead of `binary search' in
>
> >> ./ftview -e "" 20 cmr10.600gf
> >>
> >> only shows `A' glyphs. [...]
> >
> > Ok. Currently the GF's cmap is like, the first glyph in the file is
> > indexed to 0, and so on. So in cmr10.600gf, `ABCD...' appear first
> > so they are now indexed from `0,1,2..'
>
> This is correct.
>
> >
>
> [commit 401ce90 -> parthw-cleaned, origin/parthw-cleaned)]
>
> Parth,
>
>
> calling
>
> ./ftview -e "" 20 cmr10.600gf
>
> only shows `A' glyphs. This is incorrect. It should rather start
> with `ΓΔΘΛΞΠ...' since `-e ""' invokes the font's internal cmap (this
> is, the only cmap that GF
>
> > please test on the `cleaned' branch I have mostly fixed all the
> > bugs, please check there now, I did not push changes to the `wip'
> > branch.
>
> OK, will do, perhaps tomorrow morning. Now I'm going to watch the
> Perseid meteor shower :-)
>
No problem :-)
Btw, I have mostly fixed all
>
> * A missing TFM module is not a reason to abort loading of the GF
> file, cf. line 222 in `gfdrivr.c'. Or is it? Does loading a plain
> GF file (without a TFM file) needs code from the TFM module?
>
Yes, it is needed as we have not defined a macro like
`T1_CONFIG_OPTION_NO_AFM' for the
>
> [Now testing `wip' branch, commit b064189c9]
>
> > while debugging your code I've observed some issues.
>
> Here the next bunch of comments. There is so much still to do...
>
> * The code to compute `encoding' in function `gf_set_encodings' looks
> overly complicated. I don't think you
>
> >> But, even after setting all the metric values and bitmap, it is not
> >> displaying a glyph in `ftview' and just displaying a blank output.
>
> Thanks to your new branch in `freetype2-demos' I can finally test the
> GF+TFM combo...
>
> Assuming that you are running a GNU/Linux box: Have you
>
> > * PK driver is now working properly and displaying glyphs in
> > `ftview'. There was a bug in vflib's code, the problem is its code
> > does not follow `pktype' properly, I have made corrections in the
> > `pk driver'. I am attaching a screenshot of the output.
>
> Excellent! Please
Hi all,
Some quick updates:
* PK driver is now working properly and displaying glyphs
in `ftview'. There was a bug in vflib's code, the problem is
its code does not follow `pktype' properly, I have made
corrections in the `pk driver'.
I am attaching a screenshot of the output.
* Some `pk' files
>
> > On line 243 [of `ftcommon.c'], it checks for the extension of the
> > font file and proceeds further. Now `type1' files have fixed
> > extensions `pfa' or `pfb' so there is no problem, but `gf' or `pk'
> > files can have varied extensions and thus is not invoking the `tfm'
> > module, what
>
> > For testing the `tfm' module in `ftview', I tried to do some changes
>> > in the `ftcommon.c' file, but could not solve the problem, can you
>> > tell me what am I missing in this.
>> >
>> > Here is the diff of my changes in `ftcommon.c':[...]
>>
>
After adding some tracing calls, I compared
>
> > For testing the `tfm' module in `ftview', I tried to do some changes
> > in the `ftcommon.c' file, but could not solve the problem, can you
> > tell me what am I missing in this.
> >
> > Here is the diff of my changes in `ftcommon.c':
> >
> > diff --git a/src/ftcommon.c b/src/ftcommon.c
> >
Hi,
For testing the `tfm' module in `ftview', I tried to do some
changes in the `ftcommon.c' file, but could not solve the
problem, can you tell me what am I missing in this.
Here is the diff of my changes in `ftcommon.c':
diff --git a/src/ftcommon.c b/src/ftcommon.c
index 1ef3495..3526231
Hi all,
I came across the description of `FT_Module_Class' in
`ftmodapi.h', I found that there is no description of
`module_interface' field in its description. I doubt this is
intentional and maybe it is an oversight. Maybe its description
can be added too.
Thank you
Parth
>
> > I found out `T1_CONFIG_OPTION_NO_AFM' option, should we have such an
> > option like `TEX_CONFIG_OPTION_NO_TFM' for our tfm driver? What do
> > you suggest.
>
> I think this is not necessary. There are other possibilities to not
> compile the GF/PK/TFM/VF combo (namely, to omit the
>
> >> A separate TFM module makes sense IMHO, since exactly the same code
>> >> will be used for the PK module also. And VF will need this, too.
>> >> Compare this to the `psaux' module which provides routines for CFF,
>> >> Type1, Type42, and CID fonts.
>> >
>> > Can you please tell me which
>
> >> A separate TFM module makes sense IMHO, since exactly the same code
> >> will be used for the PK module also. And VF will need this, too.
> >> Compare this to the `psaux' module which provides routines for CFF,
> >> Type1, Type42, and CID fonts.
> >
> > Can you please tell me which files
>
> >> Please have a look how AFM files are attached to Type 1 fonts; it
> >> basically does the same, namely to add more metric information. I
> >> suggest that you use this as a template.
> >
> > If we use this as a template, then there is no need to have a
> > separate TFM driver, as VFlib's
>
> > Ok, then I have a pretty clear idea about how to accomplish it, I
> > will create some API functions in the `tfm' driver's service code
> > which will be used in the `gf', `pk' and `vf' drivers to extract the
> > tfm data.
>
> Please have a look how AFM files are attached to Type 1 fonts; it
>
> >> >> Yes, it has been already done.
> >>
> >> Hmm. Which commit is this? I don't see anything recent change in
> >> the `parthw-cleanup' branch related to this issue.
> >
> > Actually this was done from the start itself, I misunderstood
> > somethings and got confused myself and then I
>
> >>> And what about making GF loading the bitmaps on demand only?
> >>
> >> Yes, it has been already done.
>
> Hmm. Which commit is this? I don't see anything recent change in the
> `parthw-cleanup' branch related to this issue.
>
Actually this was done from the start itself, I misunderstood
>
> >> Please finish the GF + TFM combo first.
> >>
> >
> > Ok, then I have a pretty clear idea about how to accomplish it, I
> > will create some API functions in the `tfm' driver's service code
> > which will be used in the `gf', `pk' and `vf' drivers to extract the
> > tfm data.
>
> Please have
>
> >> the next step is `attaching' a TFM file to GF (and later on to PK),
> >> i.e., providing the internal code for `FT_Attach_File' and
> >> `FT_Attach_Stream' so that GF's metric data gets completed. Any
> >> estimate when you are done with this?
> >
> > I don't think that would be necessary,
>
> Parth,
>
>
> the next step is `attaching' a TFM file to GF (and later on to PK),
> i.e., providing the internal code for `FT_Attach_File' and
> `FT_Attach_Stream' so that GF's metric data gets completed. Any
> estimate when you are done with this?
>
I don't think that would be necessary, as
>
> >> I wonder whether it makes sense to add an artificial space glyph to
> >> the GF + TFM combo – most font formats have a space glyph for
> >> simple string support... What do you think?
> >>
> >> The width of such a space glyph could be derived from TFM's
> >> `param[2]' value.
> >
> > I
>
> Now `ftview' displays the gf glyphs too!
> I am attaching a screenshot of the output from `ftview' and `ftstring'!
> [...]
>
I have cleaned up the code for `gf driver' in the branch `parthw-cleaned',
removed all unnecessary typedefs and comments.
I have currently tested for many `gf' files,
>
> > +#define FT_SERVICE_GF_H
>
> Do you think there will be a new service special to GF? Otherwise a
> file `svgf.h' is not needed.
>
> To answer my own question: Probably yes, namely to make the `xxx' and
> `yyy' data publicly available. If you are going to do that, do you
> already have
>
> >> Now `ftview' displays the gf glyphs too! I am attaching a
> >> screenshot of the output from `ftview' and `ftstring'! [...]
>
> Looks good, thanks!
>
> I wonder whether it makes sense to add an artificial space glyph to
> the GF + TFM combo – most font formats have a space glyph for
>
> >>> Perhaps there is some missing documentation or a missing
> >>> explanatory comment in the code...
> >
> > Hmm, maybe a note on this could go into `FreeType Design / IV', as a
> > list of services all drivers are required to implement.
>
> Good idea! Parth, please file a bug report (with
> >>> I've still not found time to have a closer look at the issue, sorry
>>> >>> (still on vacation more or less). Please try to debug it by
>>> >>> yourself also – I can only assist, since it's actually your job to
>>> >>> find the bug...
>>> >>
>>> >> Yes, I am working on it. If you could
>
> >>> I've still not found time to have a closer look at the issue, sorry
> >>> (still on vacation more or less). Please try to debug it by
> >>> yourself also – I can only assist, since it's actually your job to
> >>> find the bug...
> >>
> >> Yes, I am working on it. If you could just give
>
> >> I've still not found time to have a closer look at the issue, sorry
> >> (still on vacation more or less). Please try to debug it by
> >> yourself also – I can only assist, since it's actually your job to
> >> find the bug...
> >
> > Yes, I am working on it. If you could just give me a
>
> > * GF Driver: I have added support for parsing the `xxx' and `yyy'
> > commands. Now the gf driver supports all the `gf' font files! I am
> > working on the possibilities of parsing information from these
> > commands.
>
> Good. Does `ftview' amd friends already work?
No not yet.
>
Hi all,
Here are some quick updates,
* GF Driver: I have added support for parsing the
`xxx' and `yyy' commands. Now the gf driver supports
all the `gf' font files! I am working on the possibilities
of parsing information from these commands.
* PK Driver: The `pk' driver is almost similar to the
>
> >> Well, simply follow the documentation, i.e., set `pitch' to
> >>
> >> w + 7) / 8) + 1) / 2) * 2
> >>
> >> (but with some better C code :-) and use this value for creating
> >> the bitmap.
> >
> > Ok, I did change the value of pitch (6) and tried to draw `a', it is
> > giving a wrong
>
> > [...] I still have a doubt about pitch value, currently it is set to
> > (w+7) / 8 (w: glyph width ). The documentation says `For the B/W
> > rasterizer, ‘pitch’ is always an even number.' but this is also
> > returning odd values. Is there any problem in this?
>
> Well, simply follow the
>
> > I have removed all the memory leak errors in the gf driver. But now
> > when I run `ftview', it is still not loading the glyphs.
>
> Before delving into this issue: Does your `ftexample' now work
> correctly?
>
Yes, I can't say for sure as I didn't draw every glyph by the gdb
method (It
Hi all,
I have removed all the memory leak errors in the gf
driver. But now when I run `ftview', it is still not loading
the glyphs. I did `valgrind ftview 20 /home/parth/cmr10
.600gf' and it is showing invalid reads in the `FTC...'
functions.
I am not able to understand the problem. Please help.
>
> >> No code. I manually called
>> >>
>> >> p /t buffer[0]
>> >> p /t buffer[1]
>> >> ...
>> >>
>> >> and did some paste & copy to produce the output (five bytes per
>> >> lines, according to the `pitch' value).
>> >
>> > When I do `p /t buffer[0]' I get `$1 = 0'.
>>
>> Yes, this is
>
> >> No code. I manually called
> >>
> >> p /t buffer[0]
> >> p /t buffer[1]
> >> ...
> >>
> >> and did some paste & copy to produce the output (five bytes per
> >> lines, according to the `pitch' value).
> >
> > When I do `p /t buffer[0]' I get `$1 = 0'.
>
> Yes, this is correct. The
>
> >> Please change the code to load a bitmap only on demand! There is
> >> absolutely no reason to load all 256 bitmaps at once.
> >
> > Yes, but it is not loading all the 256 bitmaps at once, like
> > `cmr10.600gf' has 128 glyphs, so it allocates metric values for
> > these 128 glyphs and we
>
> >> BTW, why are you allocating so much memory blocks? `ftexample.c'
> >> asks for a single character, I thus expect that the GF driver loads
> >> only a single glyph...
> >
> > Oh, this may be because of 128 glyph objects + 1 GF_Glyph object.
> > Actually, the GF driver always allocates 256
>
> > * If I display the 7 rows bit-wise, I get this:
> >>
> >> 00111000
> >> 0001
> >> 01101100
> >> 1010
> >>
>
> > ==5604== LEAK SUMMARY:
> > ==5604==definitely lost: 80 bytes in 2 blocks
> > ==5604==indirectly lost: 45,388 bytes in 129 blocks
>
> BTW, why are you allocating so much memory blocks? `ftexample.c'
> asks for a single character, I thus expect that the GF driver loads
> only a single
>
> [commit f7a27bf38847b4531164f042088535604d3cd2ec]
>
> > I am attaching the example program I am using for checking output,
> > its the same `example1.c' program but with some slight modifications
> > to see the num_glyphs allocated.
>
> Some comments.
>
> * Your `ftexample.c' can't work
>
> > I found the buglet, it was in `gf_free_font' function. Now, it is
> > properly allocating the `bitmap' and glyph metrics,
>
> Good!
>
> > but `ftexample' is not showing the image of the glyph. I am not
> > able to figure out why is it not showing an image. Can you point
> > out some
>
> >> > While debugging through the `GF_Glyph_Load' function in
>> >> > `gfdrivr.c', I found out that the typecasting of `FT_Face' into
>> >> > `GF_Face' is not working properly. In, `GF_Face gf =
>> >> > (GF_Face)FT_SIZE_FACE( size );', when I extract the `gf_glyph'
>> >> > element from `gf',
>
> >> > While debugging through the `GF_Glyph_Load' function in
> >> > `gfdrivr.c', I found out that the typecasting of `FT_Face' into
> >> > `GF_Face' is not working properly. In, `GF_Face gf =
> >> > (GF_Face)FT_SIZE_FACE( size );', when I extract the `gf_glyph'
> >> > element from `gf', it is
>
> > While debugging through the `GF_Glyph_Load' function in `gfdrivr.c',
> > I found out that the typecasting of `FT_Face' into `GF_Face' is not
> > working properly. In, `GF_Face gf = (GF_Face)FT_SIZE_FACE( size
> > );', when I extract the `gf_glyph' element from `gf', it is unable
> > to
Hi all,
While debugging through the `GF_Glyph_Load' function in
`gfdrivr.c', I found out that the typecasting of `FT_Face' into
`GF_Face' is not working properly.
In, `GF_Face gf = (GF_Face)FT_SIZE_FACE( size );',
when I extract the `gf_glyph' element from `gf', it is unable
to return the glyph
>
> Hi all,
> As of now the gf driver, when run with an example program
> is working[...]
> Please currently test for `cmr10.600gf' file. I am also attaching it
> here.
>
For other files with `xxx1' command after the postamble it will pass
through the checks and give a segfault at the `xxx1'
Hi all,
The tutorial page on FT website shows `freetype-config'
script as standard for retrieving compilation flags, and
`pkg-config' as an alternative solution. But as `freetype-config'
has been deprecated since version 2.9, `pkg-config' can be
made the standard instruction so that a newcomer
>
> >> `xxx' and `yyy' data can happen anywhere in a GF file; I thus suggest
> >> that you parse the data and check whether they contain important
> >> keywords like `fontid', `codingscheme', etc., which are very useful to
> >> classify the most important METAFONT fonts like `cm' or `ec'.
> >>
> >
>
> > I found some differences in gf files `cmr10.600gf' and
> > `cmr10.2602gf'. In the gftype output of `cmr10.600gf', in its
> > postamble the `loc' defines a pointer to the `boc' command which
> > directly points to the character's bitmap data. But, the file
> > `cmr10.2602gf' and most others,
Hi all,
As now all the problems about the gf driver are clear
to me I have decided to follow a plan in this week to
resolve errors in gf driver.
* Resolve compiler flag issues.(which I have already
completed)
* Add complete tracing and error handling support to
gf driver.
* The GF_Face_Done and
>
> >> > I have found that `ftview' is not allocating
> >> > `handle->current_font->num_indices' correctly for the gf driver,
> >> > [...]
> >>
> >> As a rule of thumb: The error is most certainly not in `ftview' but
> >> in your code. It is *very* unlikely that `ftview' works for all
> >>
>
>
>> This means that your gf driver did not initialize num_glyphs in FT_Face.
>>
>
> I checked in FTDemo_Install_Font it is properly allocating face->num_glyphs
> in FT_Face. Can there be any other possibilities?
>
>
> Most people allocate arrays in memory and initialize variables.
>
How many
>
> [commit 11969d558505c338f29b83bbac4d572fb85b3f2b]
>
> Sorry for the delay in answering your questions; I was abroad without
> the ability to update the git repository.
>
> > I have found that `ftview' is not allocating
> > `handle->current_font->num_indices' correctly for the gf driver,
> >
>
> > I have found that `ftview' is not allocating
> `handle->current_font->num_indices' correctly for the gf driver
>
> This means that your gf driver did not initialize num_glyphs in FT_Face.
>
I checked in FTDemo_Install_Font it is properly allocating face->num_glyphs
in FT_Face. Can there be
Hi all,
I have found that `ftview' is not allocating
`handle->current_font->num_indices' correctly for the gf driver, which is
causing errors in the
`Render_All' function in ftview. Please give me any idea about the
possible source of this error, which can help me.
Also, I think I am missing out
the
> display
> but after a while gives a segmentation fault. [...]
>
> When will you reach that point?
>
After this issue is resolved, the gf driver will be up and running.
Thank you.
--
Parth
On Thu, Jun 28, 2018 at 3:30 PM, Parth Wazurkar
wrote:
> > * About the testing
>
> > * About the testing of the gf driver, there are still some issues
> > left to be sorted out. I am working on them.
>
> What I want to have is code in your `gf' module so that `ftview' can
> display GF fonts. When will you reach that point?
>
I have cleaned up the code and now gf driver
Hi all,
* I had been working on the stream support for the gf driver
for quite a while now, and I have completed it.
* About the testing of the gf driver, there are still some issues
left to be sorted out. I am working on them.
* I have already started working on the tfm driver. I intend to work
>
> > I have been working on converting the file functions in the gf
> > driver into FT specific stream functions. [...]
> >
> > unsigned long
> > gf_read_uintn(FT_Stream stream, int size)
> > {
> > unsigned long v;
> > FT_Error error = FT_Err_Ok;
> > v = 0L;
> > while
Hi all,
I have been working on converting the file functions in the gf driver
into FT specific stream functions. Till now I have converted most
of the part and it is working fine. I am facing issues with `READ_UINT4'
function which is `gf_read_uintn' with size 4.
* This is the one with file
>
> >There is not a single font driver in FreeType that uses `FT_FILE'.
> >It's definitely the wrong interface. FreeType either accepts font
> >files or fonts that are preloaded into a memory buffer. For the
> >latter you can't use `fopen' and friends; this is another reason for
> >being the
>
> > 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
>
> >> 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
>>
>
> >> 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
>>
>
> >> 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
> >>
>
> >> 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
>
> >`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
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:
>
> >> I have already added checks for `post_post` instruction which checks
> >> for GF_ID and returns `Invalid_File_Format` if not found so, and
> >> some more checks which checks for GF files' validity in
> >> `gf_load_font`. Similar to what done in Vflib. Do you suggest
> >> anything more?
>
>
>
> * Run Nikhil's `docconverter.py' and `markify.py' scripts (from his
>> `freetype-docs' repository) to convert all block comments into the
>> `light' format. And please check whether the headers are correct –
>> for example, `gflib.c' identifies itself as `gfdrivr.h'...
>>
>
> Parth,
>
> >[Please send such e-mails to the mailing list also.]
>
Yes. Sorry for that. Actually I was going to send this as a reply to other
email but then turned to a new mail and just forgot about the cc'ing part.
>> Just a heads up that I have added a base code to all the functions
> >> required
>
> I also found this flag in `src/pcf/pcfread.c.' Maybe this can be removed
> too?
>
Yeah!
Thanks!
--
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
> >> I found that for the bdf driver in `bdfdrivr.c` the
> >> `FT_FACE_FLAG_FAST_GLYPHS` flag is active for face_flags. But in
> >> `freetype.h` it has been stated as `THIS FLAG IS DEPRECATED. DO NOT
> >> USE OR TEST IT`. I doubt if this has been done intentionally.
>
> >Right, it's an
Hi all,
I found that for the bdf driver in `bdfdrivr.c` the
`FT_FACE_FLAG_FAST_GLYPHS` flag is active for face_flags. But in
`freetype.h` it has been stated as `THIS FLAG IS DEPRECATED. DO NOT USE OR
TEST IT`. I doubt if this has been done intentionally. Does this cause any
difference? Please
>
> >Here they are. Note that I did a quick look only, and everything
> >looks fine.
>
> >* Please replace all tabs with spaces. It seems that you are using an
> > editor that represents a tab with two spaces: This is another reason
> > to use spaces only since this is non-standard (the
Hi all,
I have committed some changes in my branch `parthw-wip'. Please review it
and tell me any instructions you wish to give me.
P.S. Some part of the code can contain VFlib specific code please ignore
that,I will be changing it soon.
Thank you
--
Regards
Parth
>
> >Alexei gave you a link. To help you properly, however, we must know
> >the real problem you are facing. What do you want to do?
Actually I was studying the implementation of `gf_cmap_class`. While
understanding cerain things I got confused with the working of CMap_Class
of each driver.
1 - 100 of 136 matches
Mail list logo
