Re: [ft-devel] [Doubt] About reading a font file to check for its driver.

As the number of drivers is quite small it won't actually speed up FreeType. But having an initial guess for checking drivers can certainly remove some constant time complexity required to check through different drivers.. I doubt if there are any other issues with this approach? -- Parth On

[ft-devel] [Doubt] About reading a font file to check for its driver.

Hi all, while going through the code I found out that in file `src/base/ftobjs.c` in the function `ft_open_face_internal`, if the driver is not specified in the `FT_Open_Args' instance variable then it tries to open_face from all the installed available drivers for appropriate formats. Isn't this

Re: [ft-devel] [Doubt] About reading a font file to check for its driver.

> > > >> As the number of drivers is quite small it won't actually speed up > >> FreeType. But having an initial guess for checking drivers can > >> certainly remove some constant time complexity required to check > >> through different drivers.. > > >Yep. > Why hasn't this been included in

Re: [ft-devel] [Doubt] About reading a font file to check for its driver.

> > The actual numbers would be found in the file format specifications for > each > font format - you can find pointers to those in: > http://git.savannah.gnu.org/cgit/freetype/freetype2.git/ > tree/docs/formats.txt > http://fileformats.archiveteam.org/wiki/Fonts Yes! > > > And there's probably

Re: [ft-devel] [Doubt] About reading a font file to check for its driver.

> > >> I doubt if there are any other issues with this approach? > > >Most font formats have magic numbers. The drivers will fail just as > quickly as you check file name. What are these magic numbers? where can I find details about magic numbers. But, we are using the filename for just checking

Re: [ft-devel] [Doubt] About reading a font file to check for its driver.

Got that! Thank you On Tue, May 8, 2018 at 10:43 AM, Werner LEMBERG wrote: > > >> Most font formats have magic numbers. The drivers will fail just as > >> quickly as you check file name. > > > > What are these magic numbers? > > For example, OpenType/CFF fonts from Adobe have

[ft-devel] [Doubt] Significance of `0x10000L`

Hi all, In the `FT_Module_Class` structure the module version has been defined as `0x1L` and the required FT version as `0x2L`. Is there any specific significance of numbering the versions in hex? Please help. Thank you -- Regards Parth ___

[ft-devel] [Doubt]Meaning of `module_init` function

Hi all, The `FT_Module_Class` structure has a `module_init` function. Some font drivers have this function defined and some do not (`pcf` has it defined but `bdf` do not). I cannot understand the meaning and use of this function for font drivers. Please help. Thank you -- Regards Parth

[ft-devel] gf font files

Hi all, Can someone please provide me gf font files. I searched on the internet but could not find one. Thank you -- Regards Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [Typo]In file pcfread.c

Done! Thanks On Fri, May 11, 2018 at 11:13 PM, Werner LEMBERG wrote: > > > In line pcfread.c on line number 185: > > > > "* `bdftopcf' program to create PDF font files) has two special" > > > > it should be PCF instead of PDF. > > Thanks. Please fix in `master'! (Such a small

Re: [ft-devel] gf font files

> > You can easily create GF files by yourself, provided you have > METAFONT installed. Just say, for example, > > mf cmr10 > Yes will do that! > > and you get the file `cmr10.2602gf'. TeXLive also comes with at > least one GF test file, `cmr10.600gf': > >

[ft-devel] [Typo]In file pcfread.c

In line pcfread.c on line number 185: "* `bdftopcf' program to create PDF font files) has two special" it should be PCF instead of PDF. Thank you -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org

[ft-devel] [Doubt]About multiple ChangeLog files in the root repository

Hi all, I cannot understand the meaning of multiple ChangeLog files in the root repository. Please help. Thank you -- Regards Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [Doubt]About multiple ChangeLog files in the root repository

ach log file ChangeLogXY corresponds to freetype2-ver-X-Y. > And as new version is release new log file is create and previous one is > closed. Current log file is ChangeLog. > > > Regards, > Ankit > > On Fri, May 4, 2018 at 5:45 PM, Parth Wazurkar <parthwazur...@gmail.com> &g

[ft-devel] [GSoC] Status Update after community bonding period

Hi all, I have written a blog post about the community bonding period here . I am currently going through the VFlib's codebase and have started gaining insights for the GF driver, I have also started coding for the driver and

Re: [ft-devel] Regarding FT_CMap_ClassRec

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

[ft-devel] Regarding FT_CMap_ClassRec

Hi all, I am getting confused regarding the utility of functions defined in FT_CMap_ClassRec. Also I found that the structure is not properly documented in `ftobjs.h` . Please help. Thank you -- Parth ___ Freetype-devel mailing list

Re: [ft-devel] Updates for GF driver.

> > > * 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,

Re: [ft-devel] Updates for GF driver.

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

Re: [ft-devel] Updates for GF driver.

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

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

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

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

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

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

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

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

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

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:

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

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

[ft-devel] Review commits

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

Re: [ft-devel] Review commits

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

[ft-devel] Regarding FT_FACE_FLAG_FAST_GLYPHS

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

Re: [ft-devel] Regarding FT_FACE_FLAG_FAST_GLYPHS

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

Re: [ft-devel] Regarding FT_FACE_FLAG_FAST_GLYPHS

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

[ft-devel] About errors in gf driver.

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

Re: [ft-devel] About errors in gf driver.

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

Re: [ft-devel] About errors in 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 any other possibilities? > > > Most people allocate arrays in memory and initialize variables. > How many

Re: [ft-devel] About errors in 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

Re: [ft-devel] Issues regarding converting READ_UINT4 function into FT.

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

[ft-devel] Issues regarding converting READ_UINT4 function into FT.

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

[ft-devel] GSoC Status update

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

[ft-devel] Plan for resolving gf driver issues and updates.

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

Re: [ft-devel] About errors in gf driver.

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

Re: [ft-devel] [GitHub] Mirrors

Great!! Parth Wazurkar On Mon 30 Apr, 2018, 10:01 PM , <ar...@hasitzka.com> wrote: > As of today, FreeType has its own GitHub account [1] -- hurray :) > > Its main purpose for now is to prevent others from snatching it away (it > belongs to Werner now). That being said, I wi

Re: [ft-devel] Differences in gf files.

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

[ft-devel] Contribution to freetype

Sir, My name is Parth Wazurkar. I am a sophomore student at Indian Institute Of Information Technology Nagpur, India studying Computer Science and Engineering. I am interested in working for freetype. How should I start contributing? Please help

Re: [ft-devel] Contribution to freetype

I successfully compiled the example in this way: $gcc example1.c -I/home/parth/anaconda3/include/freetype2 -L/home/parth/anaconda3/lib -lfreetype -lm But, when I run $./a.out font sample-text for checking output it shows Segmentation fault (core dumped). Please help. On Fri, Feb 16, 2018 at 3:28

Re: [ft-devel] Contribution to freetype

on the internet and also the mail archives but could not find a solution. Please help. Regards Parth On Wed, Feb 14, 2018 at 3:14 AM, Werner LEMBERG <w...@gnu.org> wrote: > > > My name is Parth Wazurkar. I am a sophomore student at Indian > > Institute Of Information Technology N

Re: [ft-devel] Contribution to freetype

its working. Can you please help me how should I proceed further with the project. Thank You Regards Parth On Fri, Feb 16, 2018 at 1:02 PM, Parth Wazurkar <parthwazur...@gmail.com> wrote: > OK I will do that. > Actually I thought if there was any error in my installation or not.

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

[ft-devel] Possible typo in `FT_Module_Class' description.

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

[ft-devel] [GSoC] Updates for `pk' and `vf' driver.

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

Re: [ft-devel] [GSoC] Updates for `pk' and `vf' driver.

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

Re: [ft-devel] comments on GF driver

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

Re: [ft-devel] comments on GF driver

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

Re: [ft-devel] GF's cmap fails

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

Re: [ft-devel] GF's cmap fails

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

Re: [ft-devel] comments on GF driver

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

Re: [ft-devel] success?

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

Re: [ft-devel] GF's cmap fails

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

Re: [ft-devel] GF's cmap fails

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GSoC status update.

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

Re: [ft-devel] GSoC status update.

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

[ft-devel] GSoC status update.

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

Re: [ft-devel] GSoC status update.

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

Re: [ft-devel] GSoC status update.

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GSoC status update.

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

Re: [ft-devel] GSoC status update.

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

Re: [ft-devel] GSoC status update.

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] GF + TFM

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

Re: [ft-devel] [freetype2] parthw-cleaned 42890cf 2/2: [gf] Register gf services.

> > > +#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

Re: [ft-devel] GSoC status update.

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

Re: [ft-devel] Problem in ft2-demo compilation.

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

Re: [ft-devel] Problem in ft2-demo compilation.

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

Re: [ft-devel] Problem in ft2-demo compilation.

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

Re: [ft-devel] Problem in ft2-demo compilation.

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

Re: [ft-devel] Problem in ft2-demo compilation.

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

[ft-devel] Possible changes on tutorial page on FT website.

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

Re: [ft-devel] Differences in gf files.

> > >> `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'. > >> > >

Re: [ft-devel] Updates for gf driver.

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

[ft-devel] Problems with gfdriver in ftview.

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.

Re: [ft-devel] Updates for gf driver.

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

Re: [ft-devel] Updates for gf driver.

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

Re: [ft-devel] Problems with gfdriver in ftview.

> > > [...] 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

Re: [ft-devel] Problems with gfdriver in ftview.

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

Re: [ft-devel] Problems with gfdriver in ftview.

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

Re: [ft-devel] Problems in GF_Glyph_Load function.

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

[ft-devel] Problems in GF_Glyph_Load function.

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

Re: [ft-devel] Problems in GF_Glyph_Load function.

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

  1   2   >