Regarding `Test framework' project.
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 the project completely from scratch, a list of ideas which are already well discussed can be decided beforehand and the further project can be moved ahead accordingly. (This list shall be part of the proposal). * Some shortcomings like, the solution for comparison of images with different sizes, handling of different rendering modes, proper generation and presentation of output are needed to be addressed in a more proper way. * A new feature like, not only the framework will output the different images, but also show where the difference lies, like whether in hinting or rendering can also be added, which shall be very beneficial to the developer. I would also like to know, what were your expectations that missed out in the previous implementation of the project, which can be addressed in the project. Also, is there any specific area of project where I should focus on? Thank you Regards Parth
Re: [ft-devel] VF driver status
> > >> > 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 busier than I expected and I was not able to do work as planned and the task is still pending. I have a semester break in the next month and I had already planned to work on the project in this duration. Hopefully, I shall be able to produce some good results in the next month. I am also eager to complete it and see it get merged.. :-) Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem in ft2-demo compilation.
> > > 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 https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem in ft2-demo compilation.
> > > 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 ran. > > > > So I think for these ubuntu installations installing `libx11-dev' > > first and them `make X11_PATH=/usr/include' should work. > > Ah, we are getting nearer! In which directory is file `Xlib.h'? > Assuming that you have the `locate' program installed, you can simply > say > > locate Xlib.h > This gives : /usr/include/X11/Xlib.h to get all such files on your system. > > And please show use your PATH value: > > set | grep '^PATH=' | sed 's/:/:\\\n/g' > path.txt > Attached with this mail. Sorry, for the late reply I have been busy with some project submissions. Thank you Parth PATH=/usr/local/sbin:\ /usr/local/bin:\ /usr/sbin:\ /usr/bin:\ /sbin:\ /bin:\ /usr/games:\ /usr/local/games:\ /snap/bin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem in ft2-demo compilation.
> > > 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 >> within some standard directories (i.e., `/usr/lib' or `/usr/lib64') to >> this directory? Please do >> >> ls /usr/lib/x86_64-linux-gnu/X11/rstart/commands/x11r6 > ~/ls.txt >> >> and show us the file. >> > > Attached with this mail. > > >> >> Does compilation work with >> >> make X11_PATH=/usr/include >> >> also? >> > > No. > 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 ran. So I think for these ubuntu installations installing `libx11-dev' first and them `make X11_PATH=/usr/include' should work. Should I check any more cases? Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem in ft2-demo compilation.
> > > 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 > within some standard directories (i.e., `/usr/lib' or `/usr/lib64') to > this directory? Please do > > ls /usr/lib/x86_64-linux-gnu/X11/rstart/commands/x11r6 > ~/ls.txt > > and show us the file. > Attached with this mail. > > Does compilation work with > > make X11_PATH=/usr/include > > also? > No. @List LoadMonitor Terminal ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem in ft2-demo compilation.
> > > 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 X11 libraries and header files. >> This is a very simple setup and might fail easily. However, you can >> specify X11 libraries on the command line, for instance >> >> make X11_PATH="/X11/libraries /X11/header/files" >> >> If this works on your Ubuntu box please update the list of directories >> in `rules.mk' and provide a patch. >> > This `make X11_PATH="/usr/include /usr/lib/x86_64-linux-gnu/X11/rstart/commands/x11r6" ' worked for me. Thanks :-) Here is the diff: diff --git a/graph/x11/rules.mk b/graph/x11/rules.mk index c8a87ea..5492fc9 100644 --- a/graph/x11/rules.mk +++ b/graph/x11/rules.mk @@ -55,6 +55,7 @@ ifndef X11_PATH X11_XLIB := include/X11/Xlib.h X11_PATH := $(foreach dir,$(X11_DIRS),$(wildcard $(dir)/$(X11_XLIB))) X11_PATH := $(X11_PATH:%/$(X11_XLIB)=%) + X11_PATH := /usr/include /usr/lib/x86_64-linux-gnu/X11/rstart/commands/x11r6 endif endif Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem in ft2-demo compilation.
> > > 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 X11 libraries and header files. > This is a very simple setup and might fail easily. However, you can > specify X11 libraries on the command line, for instance > > make X11_PATH="/X11/libraries /X11/header/files" > > If this works on your Ubuntu box please update the list of directories > in `rules.mk' and provide a patch. > Yes, I will do. Thanks Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem in ft2-demo compilation.
> > > 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 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f40186a8000) > > /lib64/ld-linux-x86-64.so.2 (0x7f40198bb000) > > libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 > (0x7f401819b000) > > > > Also, `libx11-dev' is properly installed, and `libX11.so' files are > located in In > > `/usr/lib/x86_64-linux-gnu/'. > > > > What can be the problem? > > libXau-devel? > It is already installed and is up to date. It shows: `libxau-dev is already the newest version (1:1.0.8-1).' Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem in ft2-demo compilation.
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) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f252aa6) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x7f252a82e000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f252a611000) /lib64/ld-linux-x86-64.so.2 (0x7f252b323000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f252a273000) 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 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f40186a8000) /lib64/ld-linux-x86-64.so.2 (0x7f40198bb000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7f401819b000) Also, `libx11-dev' is properly installed, and `libX11.so' files are located in In `/usr/lib/x86_64-linux-gnu/'. What can be the problem? Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 worked, but now, the display is loaded properly. I think there might occur some X server issues with the demo programs, if the PC is not properly configured. I will test these on some different OS installations, so that some possible issues can be noted in the `ft2-demos' readme, which already contains a section for X11 issues for the other users. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4018f0d000) > > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f4018cf3000) > > libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 > (0x7f4018ace000) > > libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 > (0x7f40188ac000) > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f40186a8000) > > /lib64/ld-linux-x86-64.so.2 (0x7f40198bb000) > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f401839f000) > > libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 > (0x7f401819b000) > > libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 > (0x7f4017f95000) > > Everything looks right... > > >> Please also send the result of > >> > >> make &> make.log > > > > Attached. (makeft2_demos.log) > > This also. > > Sorry, I can't further help. I haven't any new ideas :-( > Ok. I will check. Thank you. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4018f0d000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f4018cf3000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7f4018ace000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7f40188ac000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f40186a8000) /lib64/ld-linux-x86-64.so.2 (0x7f40198bb000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f401839f000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7f401819b000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7f4017f95000) > Please also send the result of > > make &> make.log > Attached. (makeft2_demos.log) (for the demo programs) > > And finally, where is your `libX11.so' file (or files)? > In /usr/lib/x86_64-linux-gnu/ Thank you. Parth gcc -c -Wall -g -O2 -fvisibility=hidden -I/usr/include/libpng12 -DFT_CONFIG_CONFIG_H="" -pedantic -ansi -I../freetype-devel/builds/unix -I../freetype-devel/builds/unix -I/home/parth/freetype-devel/include -I/home/parth/freetype2-demos/src -DFT_CONFIG_MODULES_H="" -std=c99 -o /home/parth/freetype2-demos/objs/ftbench.o /home/parth/freetype2-demos/src/ftbench.c -DUNIX -DHAVE_POSIX_TERMIOS gcc -c -Wall -g -O2 -fvisibility=hidden -I/usr/include/libpng12 -DFT_CONFIG_CONFIG_H="" -pedantic -ansi -I../freetype-devel/builds/unix -I../freetype-devel/builds/unix -I/home/parth/freetype-devel/include -I/home/parth/freetype2-demos/src -DFT_CONFIG_MODULES_H="" -std=c99 -o /home/parth/freetype2-demos/objs/common.o /home/parth/freetype2-demos/src/common.c gcc -c -Wall -g -O2 -fvisibility=hidden -I/usr/include/libpng12 -DFT_CONFIG_CONFIG_H="" -pedantic -ansi -I../freetype-devel/builds/unix -I../freetype-devel/builds/unix -I/home/parth/freetype-devel/include -I/home/parth/freetype2-demos/src -DFT_CONFIG_MODULES_H="" -std=c99 -o /home/parth/freetype2-demos/objs/output.o /home/parth/freetype2-demos/src/output.c gcc -c -Wall -g -O2 -fvisibility=hidden -I/usr/include/libpng12 -DFT_CONFIG_CONFIG_H="" -pedantic -ansi -I../freetype-devel/builds/unix -I../freetype-devel/builds/unix -I/home/parth/freetype-devel/include -I/home/parth/freetype2-demos/src -DFT_CONFIG_MODULES_H="" -std=c99 -o /home/parth/freetype2-demos/objs/mlgetopt.o /home/parth/freetype2-demos/src/mlgetopt.c ../freetype-devel/builds/unix/libtool --mode=link gcc -lz -lpng12 -o /home/parth/freetype2-demos/bin/ftbench /home/parth/freetype2-demos/objs/ftbench.o /home/parth/freetype2-demos/objs/common.o /home/parth/freetype2-demos/objs/output.o /home/parth/freetype2-demos/objs/mlgetopt.o /home/parth/freetype-devel/objs/libfreetype.la libtool: link: gcc -o /home/parth/freetype2-demos/bin/.libs/ftbench /home/parth/freetype2-demos/objs/ftbench.o /home/parth/freetype2-demos/objs/common.o /home/parth/freetype2-demos/objs/output.o /home/parth/freetype2-demos/objs/mlgetopt.o -lz -lpng12 /home/parth/freetype-devel/objs/.libs/libfreetype.so gcc -c -Wall -g -O2 -fvisibility=hidden -I/usr/include/libpng12 -DFT_CONFIG_CONFIG_H="" -pedantic -ansi -I../freetype-devel/builds/unix -I../freetype-devel/builds/unix -I/home/parth/freetype-devel/include -I/home/parth/freetype2-demos/src -DFT_CONFIG_MODULES_H="" -std=c99 -o /home/parth/freetype2-demos/objs/ftdump.o /home/parth/freetype2-demos/src/ftdump.c -DFT2_BUILD_LIBRARY ../freetype-devel/builds/unix/libtool --mode=link gcc -lz -lpng12 -o /home/parth/freetype2-demos/bin/ftdump /home/parth/freetype2-demos/objs/ftdump.o /home/parth/freetype2-demos/objs/common.o /home/parth/freetype2-demos/objs/output.o /home/parth/freetype2-demos/objs/mlgetopt.o /home/parth/freetype-devel/objs/libfreetype.la libtool: link: gcc -o /home/parth/freetype2-demos/bin/.libs/ftdump /home/parth/freetype2-demos/objs/ftdump.o /home/parth/freetype2-demos/objs/common.o /home/parth/freetype2-demos/objs/output.o /home/parth/freetype2-demos/objs/mlgetopt.o -lz -lpng12 /home/parth/freetype-devel/objs/.libs/libfreetype.so gcc -c -Wall -g -O2 -fvisibility=hidden -I/usr/include/libpng12 -DFT_CONFIG_CONFIG_H="" -pedantic -ansi -I../freetype-devel/builds/unix -I../freetype-devel/builds/unix -I/home/parth/freetype-devel/include -I/home/parth/freetype2-demos/src -DFT_CONFIG_MODULES_H="" -std=c99 -o /home/parth/freetype2-demos/objs/ftlint.o /home/parth/freetype2-demos/src/ftlint.c ../freetype-devel/builds/unix/libtool --mode=link gcc -lz -lpng12 -o /home/parth/freetype2-demos/bin/ftlint /home/parth/freetype2-demos/objs/ftlint.o /home/parth/freetype2-demos/objs/common.o /home/parth/freetype2-demos/objs/output.o /home/parth/freetype2-demos/objs/mlgetopt.o /home/parth/freetype-devel/objs/libfreetype.la libtool: link: gcc -o
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 set up is clearly miscommunicating with X server. > Ok. I will check. Can you give any lead, how can I test it? Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 same problem, can there be any other problem? I am
> > attaching the debugged log.
>
> Can you run any other basic X program, for example, `xclock' or
> `xeyes'?
>
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.
You might get more information with
>
> strace ftview ... &> strace.log
>
I am not able to understand this file. I am attaching it with this mail.
You might also have a look into your local `.xsession-errors' file
> (for me, it's in my home directory) or the global `Xorg.log' file (see
> directory `/var/log' or something similar) for relevant messages.
>
I could not find these files in my ubuntu 18.04 installation, so I tried
to tweak with the X11 library, and it ended a disaster, I have now
newly installed ubuntu 16.04 and it still is giving the same problem,
I don't know why. I am attaching the `.xsession-errors' and `Xorg.log'
files
here. Please help.
Thank you
Parth
.xsession-errors
Description: Binary data
execve("./ftview", ["./ftview", "20", "6x13B.bdf"], [/* 67 vars */]) = 0
brk(NULL) = 0x2242000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=88383, ...}) = 0
mmap(NULL, 88383, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3f95193000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\310\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=167240, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3f95192000
mmap(NULL, 2264256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3f94d5b000
mprotect(0x7f3f94d8, 2093056, PROT_NONE) = 0
mmap(0x7f3f94f7f000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7f3f94f7f000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\r\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14608, ...}) = 0
mmap(NULL, 2109680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3f94b57000
mprotect(0x7f3f94b5a000, 2093056, PROT_NONE) = 0
mmap(0x7f3f94d59000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f3f94d59000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3f9478d000
mprotect(0x7f3f9494d000, 2097152, PROT_NONE) = 0
mmap(0x7f3f94b4d000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c) = 0x7f3f94b4d000
mmap(0x7f3f94b53000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3f94b53000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3f95191000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3f9519
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3f9518f000
arch_prctl(ARCH_SET_FS, 0x7f3f95190700) = 0
mprotect(0x7f3f94b4d000, 16384, PROT_READ) = 0
mprotect(0x7f3f94d59000, 4096, PROT_READ) = 0
mprotect(0x7f3f94f7f000, 16384, PROT_READ) = 0
mprotect(0x6f3000, 4096, PROT_READ) = 0
mprotect(0x7f3f951a9000, 4096, PROT_READ) = 0
munmap(0x7f3f95193000, 88383) = 0
open("/dev/tty", O_RDWR|O_NONBLOCK) = 3
close(3)= 0
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=10219008, ...}) = 0
mmap(NULL, 10219008, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3f93dce000
close(3)= 0
brk(NULL) = 0x2242000
brk(0x2243000) = 0x2243000
brk(0x2244000) = 0x2244000
brk(0x2245000) = 0x2245000
getuid()
Re: [ft-devel] Readme and comments for freetype2-demos
> > 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. > Any user running the `ft2-demo' programs will need to see the options only when the program is run, and having a readme explaining all the options beforehand shouldn't be necessary IMHO. Although some description explaining the utility of the demo programs can be added in the current readme. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Upcoming changes in the GF driver.
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 required. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 728179 (57.65427), loc 11007 > Character 4: dx 3604480 (55), width 699053 (55.34819), loc 11226 > Character 0: dx 3407872 (52), width 655362 (51.88892), loc 10368 > Character 1: dx 4521984 (69), width 873816 (69.18521), loc 10521 > Character 2: dx 4259840 (65), width 815562 (64.57289), loc 10736 > Character 5: dx 4063232 (62), width 786434 (62.2), loc 11365 > Yes. > And as the `indices table' is formed in such a way, it will remain > > unsorted, > > You have to do sorting again! I wrote in my last e-mail that you need > *two* *separate* arrays so that you can replace the `linear searching' > with accessing a pre-sorted array instead. > Oh yes! I get it. Thanks. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 the encoding table
> as it will always be unsorted.
>
> This really baffles me. I think you have an error in reasoning
> somewhere, still not really understanding how a cmap works. I'll
> retry.
>
> 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.
>
Really sorry for the late reply, I have been involved int some personal
issues.
My changes to `cmap' were done to load glyphs in the order they
appear in the font file, as the `gf driver' uses the offsets taken from the
`char_loc' commands in the `gf' file to get the metrics, now when the
driver
goes in the loop to get all the `char_loc' values ( the chardx and chardy
values ), it loads the glyphs in the order they appear in the `char_loc'
command, which is different from the order they appear in the font file.
It loads glyphs in the increasing order of their character code.
Now, what I did is, I took the offsets and sorted them and then in the same
order loaded the `glyph indices' thus fulfilling the goal. And as the
`indices table'
is formed in such a way, it will remain unsorted, i.e. the
enoding[0] maps to char code 65 and glyph `A'
enoding[1] maps to char code 66 and glyph `B'
enoding[2] maps to char code 67 and glyph `C'
... ... ...
enoding[57] maps to char code 0 and glyph `Γ'
enoding[58] maps to char code 1 and glyph `Δ'
enoding[59] maps to char code 2 and glyph `Θ'
[For simplicity, I'm ignoring the still missing artificial glyphs that
> must be inserted at glyph indices 0 and 1, as mentioned in a previous
> e-mail.]
>
This is in the pipeline and will be added soon :-)
Taking `cmr10.600gf' as an example, this yields the following.
>
>glyph index file offset character code
> --
> 034 65 (A)
> 1 247 66 (B)
> ... ... ...
>25 5813 90 (Z)
>26 6004 97 (a)
> ... ... ...
>51 10239 122 (z)
>52 10368 0 (Γ)
>53 10521 1 (Δ)
>54 10736 2 (Θ)
> ... ... ...
>
> What's needed for a cmap, however, is a mapping from character codes
> to glyph indices. In other words, you simply have to reverse the
> above mapping.
>
>character code file offset glyph index
> --
> 0 (Γ)10368 52
> 1 (Δ)10521 53
> 2 (Θ)10736 54
> ... ......
>65 (A) 34 0
>66 (B) 247 1
> ... ......
>90 (Z) 5813 25
> ... ......
>97 (a) 6004 26
> ... ......
>
> And this mapping is of course sorted!
>
> You should thus have two arrays.
>
> 1. A table of file offsets, ordered by glyph index:
>
> file_offsets[num_glyphs] = { 34, 247, ... };
>
>This array goes into `GF_Face'.
>
> 2. A table of glyph indices, ordered by character code:
>
> glyph_indices[num_chars] = { 52, 53, 54, ... };
>
> This eventually leads to
>
> typedef struct GF_CMapRec_
> {
> FT_CMapRec root;
> FT_UShort num_chars;
> FT_UShort* glyph_indices;
>
> } GF_CMapRec, *GF_CMap;
>
> (or something similar), and you do a binary search in `glyph_indices'.
>
This will load the glyphs in the same order as they would do previously
in the order of their charcodes because of the `char_loc' commands, I think
I will have to change the `gf_load_font' function according to the cmap
scheme above.
Thank you
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
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. > > > what happened previously is the glyphs were indexed according to > > their charcode values extracted from the `char_loc' command and this > > was the order `ΓΔΘΛΞΠ...'. I have properly set the encoding values, > > Obviously not. > > > [...] Other options with `-e' except `-e "" ' are giving proper > > output. > > Not at all. They always show the font without any cmap applied, > because there isn't a cmap with the tag you are specifying at the > command line. As soon as you will have implemented a Unicode cmap, > `-e unic' will work also. > > > Any specific reason why `-e "" ' is failing so that I can fix it? > > Set a break point at `FT_Get_Char_Index' and check the return value. > For example, the function returns 0 if argument `charcode' is zero. > This is wrong, of course, since it should return value 52 (which is > the glyph index of glyph `Γ'). Character code 1 should be mapped to > glyph index 53, code 2 to index 54, etc., etc. > 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. Although there is one more error, i.e even after displaying all the glyphs in the font file `ftview' is displaying extra `AAA...'s, any reason why this is happening? Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 currently implements). 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..' what happened previously is the glyphs were indexed according to their charcode values extracted from the `char_loc' command and this was the order `ΓΔΘΛΞΠ...'. I have properly set the encoding values, but I don't know why `-e ""' ' option is failing. Other options with `-e' except `-e "" ' are giving proper output. Any specific reason why `-e "" ' is failing so that I can fix it? Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 the bugs reported by you. Also, now the `pk' driver also loads glyphs in the order they appear in the font file. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 `tfm' module and the `ftview' always try to attach a `tfm' file to the `gf' file and if the module is not found it anyhow returns an error when it reaches the `TFM_READ_METRICS' function. This can be fixed by defining a macro which can determine whether to attach a `tfm' file or not. What do you suggest? * The proper way in FreeType to parse a contiguous block of data is to > define a `frame' using `FT_FRAME_ENTER' and `FT_FRAME_EXIT'. This > allows to access the data sequentially without doing error checking. > In other words, you should use this technique for GF, PK, and TFM > data after you've located the various file offsets and backwards > file seek operations are no longer necessary. There are plenty of > examples in `winfnt.c' how to do that. > > [Of course, this is future work to be done after GSoC.] > Yes! This can be changed later. * In `gflib.c', line 564, you are allocating the `bm_table' array with > 256 elements. However, not all GF fonts have this much glyphs. > IMHO, you should thus reallocate the array to the final size as soon > as you know how many elements are really in the font. > Fixed. * It's not necessary to assign NULL in a loop to `bitmap' (file > `gflib.c', lines 569f) since a call to `FT_ALLOC_MULT' already > initializes all elements to zero. > Fixed. > * It's not necessary to assign `-1' in a loop to `char_offset' (file > `gflib.c', lines 587f), since `char_offset' can never be zero in a > GF file. > Yes, I set that because initially I was allocating the metric values according to the charcode from the font file and then setting up the encodings, so it was needed to differentiate amongst the `set' and `unset' character_offsets. Now its not necessary and fixed. * Serious: In `gf_set_encodings' you are always using 256 iterations > in loops to handle `tosort' and friends. However, those arrays only > have `nencoding' elements! Please think of such issues from the > very beginning since they are potential security risks. > Same reason for setting it as above. Now fixed! Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 need two nested loops for
> that.
>
> * The test in gfdrivr.c:455 is completely wrong. First of all, the
> values `code_min' and `code_max' don't reflect the real values in
> the GF font; right now they are hard-coded. Please fix that.
>
> Second, you must not compare glyph indices with `code_{min,max}' at
> all, since the latter reflect *encoding* values, not glyph indices!
> Glyph indices always start with value 0 and would normally go up to
> the number of glyphs - 1. However, as discussed earlier, there
> should be two artifical characters added, namely a bitmap shape for
> the `.notdef' character at index 0, and a `space' glyph at index 1.
> This is still missing...
>
> * gfdrivr.c:463: `metric' should be a pointer! Right now, you are
> uselessly copying the whole structure.
>
> * And most important: Where do you (re)allocate the bitmap for the
> current glyph? `slot->bitmap' is always NULL, and `gf_read_glyph'
> has no buffer to store the data it is reading...
>
> No wonder that no glyphs get displayed.
>
> Sigh. Giving up right now. Hopefully, you can quickly fix the most
> glaring bugs.
>
No no, 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.
Thank you
Parth
On Sun, Aug 12, 2018 at 11:06 PM, Werner LEMBERG wrote:
>
> [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 need two nested loops for
> that.
>
> * The test in gfdrivr.c:455 is completely wrong. First of all, the
> values `code_min' and `code_max' don't reflect the real values in
> the GF font; right now they are hard-coded. Please fix that.
>
> Second, you must not compare glyph indices with `code_{min,max}' at
> all, since the latter reflect *encoding* values, not glyph indices!
> Glyph indices always start with value 0 and would normally go up to
> the number of glyphs - 1. However, as discussed earlier, there
> should be two artifical characters added, namely a bitmap shape for
> the `.notdef' character at index 0, and a `space' glyph at index 1.
> This is still missing...
>
> * gfdrivr.c:463: `metric' should be a pointer! Right now, you are
> uselessly copying the whole structure.
>
> * And most important: Where do you (re)allocate the bitmap for the
> current glyph? `slot->bitmap' is always NULL, and `gf_read_glyph'
> has no buffer to store the data it is reading...
>
> No wonder that no glyphs get displayed.
>
> Sigh. Giving up right now. Hopefully, you can quickly fix the most
> glaring bugs.
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 ever used
> `valgrind', as I've recommended to you a few times?
>
Yes I have :-), Also if you see the `cleaned' branch and debug it with
`valgrind'
you will find it completely error free. These errors by `valgrind' are
reported
after I changed the logic to load bitmaps on demand, and as reported by you
because of the double free in `tfm module'. Sorry for that, I'll fix it :-)
FT2_DEBUG=any:7 valgrind ./ftview 20 cmr10.600gf &> cmr10.600gf.log
>
> Doing this you can immediately see in `cmr10.600gf.log' that there is
> a double free:
>
> ...
> TFM_Read_Metrics: TFM Metric Information:
> Check Sum : 1274110073
> Design Size: 10
> Begin Char : 0
> End Char : 127
> font_bbx_w : 10
> font_bbx_h : 10
> slant : 0
> Invalid read of size 8
> at 0x412F6D: FT_Stream_Free (ftobjs.c:251)
> by 0x41718E: FT_Attach_Stream (ftobjs.c:2711)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
>Address 0x79a80c8 is 56 bytes inside a block of size 80 free'd
> at 0x4C2B35C: free (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DF876: ft_free (ftsystem.c:138)
> by 0x42256C: ft_mem_free (ftutil.c:174)
> by 0x4DDE84: tfm_close (tfmobjs.c:136)
> by 0x47F8F1: TFM_Read_Metrics (gfdrivr.c:511)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
>Block was alloc'd at
> at 0x4C2A110: malloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DF82B: ft_alloc (ftsystem.c:76)
> by 0x42229F: ft_mem_qalloc (ftutil.c:76)
> by 0x40: ft_mem_alloc (ftutil.c:55)
> by 0x412E2C: FT_Stream_New (ftobjs.c:197)
> by 0x41710B: FT_Attach_Stream (ftobjs.c:2698)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
>
> `FT_Attach_Stream' frees the stream passed as an argument to
> `TFM_Read_Metrics' by itself. While you have modeled your code after
> `afm_parser_init', you've missed that this function allocates a new
> stream but your code doesn't. This means that in `tfm_close' you must
> not close the stream since this happens later on.
> Applying this fix
>
> diff --git a/src/tfm/tfmobjs.c b/src/tfm/tfmobjs.c
> index 8cd3b5bf5..c03873e7a 100644
> --- a/src/tfm/tfmobjs.c
> +++ b/src/tfm/tfmobjs.c
> @@ -131,9 +131,10 @@
> FT_LOCAL( void )
> tfm_close( TFM_Parser parser )
> {
> -FT_Memory memory = parser->memory;
> +FT_UNUSED( parser );
>
> -FT_FREE( parser->stream );
> +
> +/* nothing */
> }
>
> helps.
>
Done!
>
> Note that there are still memory leaks in your driver.
>
> FT2_DEBUG=any:7 \
> valgrind --leak-check=full \
>--show-leak-kinds=all \
>./ftview 20 cmr10.600gf
>
> 80 bytes in 1 blocks are definitely lost in loss record 42 of 73
> at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DE498: tfm_parse_metrics (tfmobjs.c:282)
> by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
>
> 128 bytes in 1 blocks are definitely lost in loss record 44 of 73
> at 0x4C2C240: calloc (in
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 report bugs to the VFlib author also, just for > completeness. > Ok. > Note that in your image it is still possible to see a bug: Glyphs are > `jumping' vertically (cf. `abcdef...'). Please fix that, using a > common baseline for all glyphs. > Yes. > > * TFM module is working fine but returning incorrect metric values, > > there are some conflicts between vflib's code and the `tftopl' > > implementation, I will solve this and get it resolved. > > As soon as this gets fixed, TFM files can be attached to both GF and > PK files, right? > Indeed :-) Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 ( mostly files with large resolutions ) are giving errors in the `pk_read_n14' function and not displaying proper glyphs in `ftview'. I am working on it and will be fixed. * TFM module is working fine but returning incorrect metric values, there are some conflicts between vflib's code and the `tftopl' implementation, I will solve this and get it resolved. * I will add the complete code for the VF driver by tomorrow, and this will also be working soon :-) Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 do you suggest? > > Well, simply extend the code to expect file names of the form > > '.' [] 'gf' > Ok. Thanks. Parth > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 the debugging output of `pfa + afm' files and `gf + tfm' files, and I found out that the problem is in the `ftcommon.c' file. On line 243, 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 do you suggest? Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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
> > index 1ef3495..3526231 100644
> > --- a/src/ftcommon.c
> > +++ b/src/ftcommon.c
> > @@ -236,7 +236,7 @@
> >const char* format = FT_Get_Font_Format( *aface );
> >
> >
> > - if ( !strcmp( format, "Type 1" ) )
> > + if ( !strcmp( format, "Type 1" ) || !strcmp( format, "gf" ) )
>
> [Not pertinent to the issue, but... Please do
>
>#define FT_FONT_FORMAT_GF "GF"
>
> (in `svfntfmt.h' to get uppercase font format name.)]
>
Done. Thanks.
>
> >{
> > char orig[5];
> > char* suffix= (char*)strrchr( font->filepathname, '.'
> );
> > @@ -251,10 +251,18 @@
> >/* we have already allocated four more bytes */
> >suffix = (char*)font->filepathname + strlen(
> font->filepathname );
> >
> > -memcpy( suffix, ".afm", 5 );
> > -if ( FT_Attach_File( *aface, font->filepathname ) )
> > +if( !strcmp( format, "Type 1" ) )
> > {
> > - memcpy( suffix, ".pfm", 5 );
> > + memcpy( suffix, ".afm", 5 );
> > + if ( FT_Attach_File( *aface, font->filepathname ) )
> > + {
> > +memcpy( suffix, ".pfm", 5 );
> > +FT_Attach_File( *aface, font->filepathname );
> > + }
> > +}
> > +else if( !strcmp( format, "gf" ) )
> > +{
> > + memcpy( suffix, ".tfm", 5 );
> >FT_Attach_File( *aface, font->filepathname );
> > }
>
> This looks correct.
Ok. Thanks.
> say? If you don't get meaningful debug output from the GF and TFM
> drivers, you obviously haven't added enough FT_TRACE[0-9] calls :-)
Yes!, adding tracing calls to the `tfm' module is left, I will do it.
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 100644
--- a/src/ftcommon.c
+++ b/src/ftcommon.c
@@ -236,7 +236,7 @@
const char* format = FT_Get_Font_Format( *aface );
- if ( !strcmp( format, "Type 1" ) )
+ if ( !strcmp( format, "Type 1" ) || !strcmp( format, "gf" ) )
{
char orig[5];
char* suffix= (char*)strrchr( font->filepathname, '.' );
@@ -251,10 +251,18 @@
/* we have already allocated four more bytes */
suffix = (char*)font->filepathname + strlen( font->filepathname
);
-memcpy( suffix, ".afm", 5 );
-if ( FT_Attach_File( *aface, font->filepathname ) )
+if( !strcmp( format, "Type 1" ) )
{
- memcpy( suffix, ".pfm", 5 );
+ memcpy( suffix, ".afm", 5 );
+ if ( FT_Attach_File( *aface, font->filepathname ) )
+ {
+memcpy( suffix, ".pfm", 5 );
+FT_Attach_File( *aface, font->filepathname );
+ }
+}
+else if( !strcmp( format, "gf" ) )
+{
+ memcpy( suffix, ".tfm", 5 );
FT_Attach_File( *aface, font->filepathname );
}
Thank you
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 corresponding > modules). > Ok. Thanks Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 should I look upon in the `psaux' >> > module to get an understanding of its structure so that the `tfm' >> > module can be constructed on its lines. >> >> Check the `T1_Read_Metrics' files as described in my previous e-mail >> and look up the used interface calls. Start with a `tfm_module_class' >> (modelled after `psaux_module_class') and set up a module-specific >> `tfm_interface' (modelled after `psaux_interface'), which collects all >> necessary functions to parse a TFM. I can imagine that you need, say, >> >> tfm_open >> tfm_read >> tfm_parse_metrics >> tfm_parse_kerns >> tfm_close >> >> In the GF module, you have to define a function for the `attach_file' >> interface (modelled after `T1_Read_Metrics') which in turn checks that >> the TFM module interface is available, and which then calls the >> necessary functions to handle a TFM file.[...] > > 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. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 should I look upon in the `psaux' > > module to get an understanding of its structure so that the `tfm' > > module can be constructed on its lines. > > Check the `T1_Read_Metrics' files as described in my previous e-mail > and look up the used interface calls. Start with a `tfm_module_class' > (modelled after `psaux_module_class') and set up a module-specific > `tfm_interface' (modelled after `psaux_interface'), which collects all > necessary functions to parse a TFM. I can imagine that you need, say, > > tfm_open > tfm_read > tfm_parse_metrics > tfm_parse_kerns > tfm_close > > In the GF module, you have to define a function for the `attach_file' > interface (modelled after `T1_Read_Metrics') which in turn checks that > the TFM module interface is available, and which then calls the > necessary functions to handle a TFM file. > Thanks. > PS: Have you seen my e-mail from Fri, 20 Jul 2018 11:21:36 +0200 > (CEST)? I've discussed some more bugs in your code... > Yes, I have. Two bugs or improvements are remaining, one is adding artificial glyphs and other is allocating bitmap values only on demand. My previously attempted solutions failed and I am working on it. I will solve them soon. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 TFM driver only provides functions > > to extract the TFM metric data for the `vf' format, which we can > > constitute like in the `afm' files. > > 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. > Yes. Can you please tell me which files should I look upon in the `psaux' module to get an understanding of its structure so that the `tfm' module can be constructed on its lines. > The AFM code handling is restricted to Type1 fonts; it thus doesn't > make sense to have a separate module. > Ok. > > Although, this driver computes some glyph metric data using this tfm > > data, which essentially draws some glyph only having bounding box. > > I am confused like if we proceed with the `afm' style should there > > be TFM driver or not? > > Well, the TFM driver will be a *passive* module, similar to the AFM > handling code. This means that it won't be called in the loop that > tries to find out an input font's file format; instead, it becomes > only active if a TFM gets attached to a GF or PK file. > Yes Indeed! This will be another auxiliary module which will facilitate the `gf', `pk' and `vf' formats. > The job of the TFM module is to parse a TFM file and to fill metrics > and/or kerning structures (cf. `T1_Read_Metrics', lines 266-282). If > everything's OK, it will overwrite and/or add data to `GF_Face' or > `PK_Face' (cf. `T1_Read_Metrics', lines 296-316). > > Does this help? Yes. Thanks. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 > 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 TFM driver only provides functions to extract the TFM metric data for the `vf' format, which we can constitute like in the `afm' files. Although, this driver computes some glyph metric data using this tfm data, which essentially draws some glyph only having bounding box. I am confused like if we proceed with the `afm' style should there be TFM driver or not? Please help. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 figured out that it > > was fine. You can check in the `GF_Glyph_Load' function in > > `gfdrivr.c', in the latest source tree. > > No, no, you are mistaken. In `gfdrivr.c', line 398 (function > `GF_Glyph_Load') there is > > bm = gf->gf_glyph->bm_table[glyph_index]; > > which means that you don't load the glyph on demand from the font file > stream. Instead, you have already loaded *all* bitmaps into > `bm_table'[*] while creating the GF face object, and you simply get a > pointer into this array and copy the bitmap into the glyph slot. > > This wastes a lot of memory; it also makes `GF_Init_Face' > unnecessarily slow. I asked you to change this code so that > `GF_Init_Face' only loads file stream *offsets* to an array. The > actual bitmap (namely a *single* one for a given glyph index, and not > all together) should then be loaded by `GF_Glyph_Load', seeking to the > stored offset and starting the parsing of the GF data. > Oh, I see. I'll change it. Thanks. BTW, BDF driver too does the same, this might have to be changed too. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 somethings and got confused myself and then I figured out that it was fine . You can check in the `GF_Glyph_Load' function in `gfdrivr.c', in the latest source tree. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 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. > Ok. > > > I have some doubts, I have already filled all the data in `FT_Face' > > and `FT_Glyphslot' with the glyph data. I cannot understand which > > metric data is wrongly filled. Please help. > > What exactly do you mean with `wrongly filled'? Please give an > example that I can look at with the debugger. > I mean that the which metric data is wrongly allotted in the `GF_Glyph_Load' function which is causing these errors in the gf output. Is it only ascender and descender values in the `GF_Size_Select' function or anything else. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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, > > It is *absolutely* necessary. GF/TFM (and PK/TFM) are *always* to be > used in tandem! > > > as `Vflib' already switched from using a TFM file for `gf' and `pk' > > formats, and also `gftype' does not use a TFM file. So why do we > > need to implement this? > > As your `ftview' snapshot clearly demonstrates, GF fonts don't contain > metrics – the glyphs `jump' vertically. In particular, a glyph > normally has a height, a depth, and a typographic width. The GF data > does neither contain the height nor the depth; it only holds the bbox > and the width. Only with the TFM data you can align the glyphs > vertically to sit on the baseline. > > The GF fonts also lack some metadata like the slant of the font or the > width of a (normal) space. > > BTW, `gftype' is a GF dumper, nothing else; it doesn't show how to use > GF fonts correctly. > > > `vf' fonts are required to use TFM files for metric information and > > I am going to implement the required functions for this. > > 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. I have some doubts, I have already filled all the data in `FT_Face' and `FT_Glyphslot' with the glyph data. I cannot understand which metric data is wrongly filled. Please help. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 `Vflib' already switched from using a TFM file for `gf' and `pk' formats, and also `gftype' does not use a TFM file. So why do we need to implement this? `vf' fonts are required to use TFM files for metric information and I am going to implement the required functions for this. > And what about making GF loading the bitmaps on demand only? > Yes, it has been already done. You can check GF driver loads bitmaps on demand only. It has been implemented similar to as done in the `bdf' driver. 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.
> > >> 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 don't really know how to work that out. Can you suggest any > > format which does this? > > FreeType already does that for some formats: The glyph with index 0 > must be the equivalent to the `.notdef' glyph (also known as the > `undefined glyph' or `default glyph') – cf. the WINFNT or BDF driver. > Oh, I always wondered what was this `notdef' glyph in the WINFNT driver. I thought this was something format specific. I get that now. Thanks :-) BTW, it seems this feature is still missing in the GF driver, so > please add it. The actual shape of the glyph with index zero doesn't > matter; for example, you could construct it on the fly (i.e., while > loading the GF file), say, a bitmap that contains a hollow box as with > most TrueType fonts, scaled to the proper font size. > >X >X X >X X >X X >X > > Similarly to the above you should construct a second artificial > character to hold the space glyph (i.e., an empty bitmap which only > has an advance width); for convenience, I suggest this glyph gets > index 1. As a consequence, you would have to shift all (native) glyph > indices by two; a GF font with 128 glyphs becomes a font with 130 > glyphs, etc., etc. > > In case no TFM file is attached to the GF file, please use the font > size to derive a heuristic width for both the `.notdef' and the > `space' glyphs. > Ok. I will do it. 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.
> > 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, like cmr1, cmr2, cmr10, with different options in `ftview' and `ftgrid' and it is working fine. Can you please once test the driver so that if there are any further changes required, I can complete that. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 an idea how such an API should look like? > Yes, this can be done. Although I don't have any idea yet, but I can surely work on it. 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.
> > >> 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 simple > string support... What do you think? The width of such a space glyph > could be derived from TFM's `param[2]' value. > I don't really know how to work that out. Can you suggest any format which does this? Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 item group > `wishlist') so that it won't be forgotten. > Yes sure. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 lead like
>>> >> where should I look upon and like possible sources of errors, it
>>> >> will be great help.
>>> >
>>> > I'm quite sure this is not a problem of `ftview'. Similarly, I'm
>>> > quite sure it is not a problem of FreeType's caching code either.
>>>
>>> I've now done some debugging:
>>>
>>> gdb --args /home/wl/git/freetype/freetype2-demos.parth/bin/ftstring
>>> 20 cmr10.600gf
>>> (gdb) r
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x76817ea6 in __strcmp_ssse3 () from /lib64/libc.so.6
>>> (gdb) up
>>> #1 0x004088af in my_face_requester (face_id=0x762110,
>>> lib=0x747df0, request_data=0x0, aface=0x770118) at
>>> src/ftcommon.c:239
>>> 239 if ( !strcmp( format, "Type 1" ) )
>>> (gdb) p format
>>> $1 = 0x0
>>> (gdb) l
>>> 234 if ( !error )
>>> 235 {
>>> 236 const char* format = FT_Get_Font_Format( *aface );
>>> 237
>>> 238
>>> 239 if ( !strcmp( format, "Type 1" ) )
>>> 240 {
>>> 241 char orig[5];
>>> 242 char* suffix= (char*)strrchr(
>>> font->filepathname, '.' );
>>> 243 inthas_extension = suffix
>>> &&
>>>
>>> This clearly shows that the problem is in `FT_Get_Font_Format'; this
>>> function returns zero which looks very fishy according to its
>>> documentation.
>>>
>>> (gdb) b FT_Get_Font_Format
>>> (gdb) r
>>> Breakpoint 1, FT_Get_Font_Format (face=0x7703c0) at
>>> /home/wl/git/freetype/freetype2.parth/src/base/ftfntfmt.c:30
>>> 30 const char* result = NULL;
>>> (gdb) n
>>> 33 if ( face )
>>> (gdb)
>>> 34FT_FACE_FIND_SERVICE( face, result, FONT_FORMAT );
>>> (gdb)
>>> 36 return result;
>>> (gdb) p result
>>> $2 = 0x0
>>>
>>> Obviously, there is a problem with the `FONT_FORMAT' service in the GF
>>> driver; let's check the winfnt driver for comparison.
>>>
>>> cd winfonts
>>> git grep FONT_FORMAT
>>> winfnt.c:#include FT_SERVICE_FONT_FORMAT_H
>>> winfnt.c:{ FT_SERVICE_ID_FONT_FORMAT, FT_FONT_FORMAT_WINFNT },
>>>
>>> cd gf
>>> git grep FONT_FORMAT
>>> gfdrivr.c:#include FT_SERVICE_FONT_FORMAT_H
>>>
>>> Ouch, the service is completely missing...
>>>
>>> Tadaa!
>>>
>>> Have a look into `include/freetype/internal/services/svfntfmt.h'.
>>>
>>
>> Yes! indeed! Thank you so much for that.
>>
>>
>>> Please tell me why you wasn't able to identify the problem by
>>> yourself!
>>
>>
>> Actually, I thought that these services are not a regular part of the
>> module
>> and are defined only if there are functions of the driver required
>> outside the
>> driver, so I did not define them. But, I was unaware that the services
>> are
>> used by the demo program. As I was first debugging with `ftview' and I
>> was
>> going function by function to debug it and I was stuck at the `FTC'
>> functions.
>> Then when you told to debug through `ftstring', I thought to do it later
>> as I was in middle of learning about the `vf' fonts.
>>
>>
>>> Perhaps there is some missing documentation or a missing
>>> explanatory comment in the code...
>>>
>>
> Now `ftview' displays the gf glyphs too!
> I am attaching a screenshot of the output from `ftview' and `ftstring'!
> [...]
>
Attaching a cropped image.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 lead like
> >> where should I look upon and like possible sources of errors, it
> >> will be great help.
> >
> > I'm quite sure this is not a problem of `ftview'. Similarly, I'm
> > quite sure it is not a problem of FreeType's caching code either.
>
> I've now done some debugging:
>
> gdb --args /home/wl/git/freetype/freetype2-demos.parth/bin/ftstring 20
> cmr10.600gf
> (gdb) r
> Program received signal SIGSEGV, Segmentation fault.
> 0x76817ea6 in __strcmp_ssse3 () from /lib64/libc.so.6
> (gdb) up
> #1 0x004088af in my_face_requester (face_id=0x762110,
> lib=0x747df0, request_data=0x0, aface=0x770118) at src/ftcommon.c:239
> 239 if ( !strcmp( format, "Type 1" ) )
> (gdb) p format
> $1 = 0x0
> (gdb) l
> 234 if ( !error )
> 235 {
> 236 const char* format = FT_Get_Font_Format( *aface );
> 237
> 238
> 239 if ( !strcmp( format, "Type 1" ) )
> 240 {
> 241 char orig[5];
> 242 char* suffix= (char*)strrchr(
> font->filepathname, '.' );
> 243 inthas_extension = suffix
> &&
>
> This clearly shows that the problem is in `FT_Get_Font_Format'; this
> function returns zero which looks very fishy according to its
> documentation.
>
> (gdb) b FT_Get_Font_Format
> (gdb) r
> Breakpoint 1, FT_Get_Font_Format (face=0x7703c0) at
> /home/wl/git/freetype/freetype2.parth/src/base/ftfntfmt.c:30
> 30 const char* result = NULL;
> (gdb) n
> 33 if ( face )
> (gdb)
> 34FT_FACE_FIND_SERVICE( face, result, FONT_FORMAT );
> (gdb)
> 36 return result;
> (gdb) p result
> $2 = 0x0
>
> Obviously, there is a problem with the `FONT_FORMAT' service in the GF
> driver; let's check the winfnt driver for comparison.
>
> cd winfonts
> git grep FONT_FORMAT
> winfnt.c:#include FT_SERVICE_FONT_FORMAT_H
> winfnt.c:{ FT_SERVICE_ID_FONT_FORMAT, FT_FONT_FORMAT_WINFNT },
>
> cd gf
> git grep FONT_FORMAT
> gfdrivr.c:#include FT_SERVICE_FONT_FORMAT_H
>
> Ouch, the service is completely missing...
>
> Tadaa!
>
> Have a look into `include/freetype/internal/services/svfntfmt.h'.
>
Yes! indeed! Thank you so much for that.
> Please tell me why you wasn't able to identify the problem by
> yourself!
Actually, I thought that these services are not a regular part of the module
and are defined only if there are functions of the driver required outside
the
driver, so I did not define them. But, I was unaware that the services are
used by the demo program. As I was first debugging with `ftview' and I was
going function by function to debug it and I was stuck at the `FTC'
functions.
Then when you told to debug through `ftstring', I thought to do it later
as I was in middle of learning about the `vf' fonts.
> Perhaps there is some missing documentation or a missing
> explanatory comment in the code...
>
Yes. I think so too.
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.
> > >> 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 lead like > > where should I look upon and like possible sources of errors, it > > will be great help. > > I'm quite sure this is not a problem of `ftview'. Similarly, I'm > quite sure it is not a problem of FreeType's caching code either. > Ok. > What about trying `ftstring' instead? IIRC, it doesn't use the > caching code; debugging it should thus be simpler. > Yes! I'll do 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.
> > > * 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. > 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 lead like where should I look upon and like possible sources of errors, it will be great help. > > * PK Driver: The `pk' driver is almost similar to the `gf' driver. > > I have added all the code for the pk driver in the branch > > `parthw-pk-vf'. The driver is running properly and allocating > > bitmap values like the gf driver! > > Good, too :-) Still waiting for an image from `ftview'... > Will get it running soon! :-) > Please let me know if there are any instructions for me :-) > > I suggest that you get rid of `UINT' and friends, replacing it with > `FT_UInt' and similar FreeType entities. This should (a) make the > source code appearance more uniform, and (b) it should make debugging > easier since you have to remember less typedefs. > Ok. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 `gf' driver. I have added all the code for the pk driver in the branch `parthw-pk-vf'. The driver is running properly and allocating bitmap values like the gf driver! * TFM Driver: Some changes are remaining and it will be working soon! * VF Driver: I have started working on the code, and will get it running soon! Please let me know if there are any instructions for me :-) Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 glyph, then I changed the value to previous value(5), > > it drew a correct one. I think that this might be the problem, that > > gf uses odd pitch value to draw glyph and ftview requires a even > > one? > > With `set the pitch' I mean of course that you also adjust the code to > insert a trailing null byte each line *in the output buffer* if the > number of input bytes per line is uneven... > Oh, I get it! Thanks. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 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 glyph, then I changed the value to previous value(5), it drew a correct one. I think that this might be the problem, that gf uses odd pitch value to draw glyph and ftview requires a even one? Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 takes a lot of time too.), but I changed the values of rows and width and now it seems correct, 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? I thought that ftview had problems because of memory leak errors in gfdriver, that is why I asked this problem. > > ==11084== Invalid read of size 1 > > ==11084==at 0x10E758: my_face_requester (ftcommon.c:221) > > What git commit ID of the `freetype2-demos' repository are you using? > I am using freetype2-demos' VER 2.9.1. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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. This is what I am getting: ==11084== Memcheck, a memory error detector ==11084== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==11084== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==11084== Command: ftview 20 /home/parth/cmr10.600gf ==11084== FT_Open_Face: Requesting number of faces and named instances FT_Stream_Open: opened `/home/parth/cmr10.600gf' (24148 bytes) successfully TTF driver SFNT driver not a font using the SFNT container format [...] GF driver gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found gf_load_font: GF Postamble found gf_load_font: Allocated bitmap table number of glyphs: allocated 128 FT_Open_Face: New face object, adding to list FT_Open_Face: Creating glyph slot FT_Open_Face: The font has 1 face and 0 named instances for face 0 FT_Open_Face: Return 0x0 FT_Open_Face: Requesting number of faces and named instances FT_Stream_Open: opened `/home/parth/cmr10.600gf' (24148 bytes) successfully TTF driver SFNT driver not a font using the SFNT container format [...] GF driver gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found gf_load_font: GF Postamble found gf_load_font: Allocated bitmap table number of glyphs: allocated 128 FT_Open_Face: New face object, adding to list FT_Open_Face: Creating glyph slot FT_Open_Face: The font has 1 face and 0 named instances for face 0 FT_Open_Face: Return 0x0 FT_Open_Face: Requesting face 0 FT_Stream_Open: opened `/home/parth/cmr10.600gf' (24148 bytes) successfully TTF driver SFNT driver not a font using the SFNT container format [...] not a BDF file GF driver gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found gf_load_font: GF Postamble found gf_load_font: Allocated bitmap table number of glyphs: allocated 128 FT_Open_Face: New face object, adding to list FT_Open_Face: Creating glyph slot FT_New_GlyphSlot: Creating new slot object FT_New_GlyphSlot: Return 0x0 FT_Open_Face: Creating size object FT_Open_Face: Return 0x0 FT_Open_Face: Requesting face 0 FT_Stream_Open: opened `/home/parth/cmr10.600gf' (24148 bytes) successfully TTF driver SFNT driver not a font using the SFNT container format [...] not a BDF file GF driver gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found gf_load_font: GF Postamble found gf_load_font: Allocated bitmap table number of glyphs: allocated 128 FT_Open_Face: New face object, adding to list FT_Open_Face: Creating glyph slot FT_New_GlyphSlot: Creating new slot object FT_New_GlyphSlot: Return 0x0 FT_Open_Face: Creating size object FT_Open_Face: Return 0x0 ==11084== Invalid read of size 1 ==11084==at 0x10E758: my_face_requester (ftcommon.c:221) ==11084==by 0x4EC0836: ftc_face_node_init (ftcmanag.c:243) ==11084==by 0x4EBF8D6: FTC_MruList_New (ftcmru.c:269) ==11084==by 0x4EC1A0E: FTC_Manager_LookupFace (ftcmanag.c:325) ==11084==by 0x10F81B: FTDemo_Set_Current_Charsize (ftcommon.c:601) ==11084==by 0x10D790: event_font_change (ftview.c:1007) ==11084==by 0x10B39C: main (ftview.c:1832) ==11084== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==11084== ==11084== ==11084== Process terminating with default action of signal 11 (SIGSEGV) ==11084== Access not within mapped region at address 0x0 ==11084==at 0x10E758: my_face_requester (ftcommon.c:221) ==11084==by 0x4EC0836: ftc_face_node_init (ftcmanag.c:243) ==11084==by 0x4EBF8D6: FTC_MruList_New (ftcmru.c:269) ==11084==by 0x4EC1A0E: FTC_Manager_LookupFace (ftcmanag.c:325) ==11084==by 0x10F81B: FTDemo_Set_Current_Charsize (ftcommon.c:601) ==11084==by 0x10D790: event_font_change (ftview.c:1007) ==11084==by 0x10B39C: main (ftview.c:1832) ==11084== If you believe this happened as a result of a stack ==11084== overflow in your program's main thread (unlikely but ==11084== possible), you can try to increase the size of the ==11084== main thread stack using the --main-stacksize= flag. ==11084== The main thread stack size used in this run was 8388608. ==11084== ==11084== HEAP SUMMARY: ==11084== in use at exit: 2,334,374 bytes in 653 blocks ==11084== total heap usage: 1,496 allocs, 843 frees, 3,811,806 bytes allocated ==11084== ==11084== LEAK SUMMARY: ==11084==definitely lost: 0 bytes in 0 blocks ==11084==indirectly lost: 0 bytes in 0 blocks ==11084== possibly lost: 0 bytes in 0 blocks ==11084==still reachable: 2,334,374 bytes in 653 blocks ==11084== suppressed: 0 bytes in 0 blocks ==11084== Rerun with --leak-check=full to see details of leaked memory ==11084== ==11084== For counts of detected and suppressed errors, rerun with: -v ==11084==
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 first eight bits are zero – just have a >> look at the set bits :-) >> >> > What am I missing? >> >> There are more bytes to look at, for example >> >> (gdb) p /t bitmap->buffer[1] >> $3 = 11 >> (gdb) p /t bitmap->buffer[2] >> $4 = 1000 >> >> etc., etc. >> > > I rendered the glyph `A' in this way and I am attaching the glyphs > rendered with the `gfdriver' and `gftype'[...] > Resending in txt format. Parth 00111000 00111000 00111000 0100 0100 0100 1110 1110 0001 0001 0001 00111000 001100111000 001100111000 01110000 01111100 01111100 1100 11001110 11001110 00011111 00011111 00011111 001100111000 001100111000 001100111000 01111100 01111100 01111100 11001110 11001110 11001110 00011111 00011111 00111000 001100111000 001100111000 0100 0100 0100 1110 11001110 11001110 00011000 00011111 00011111 001100111000 001100111000 001100111000 01111100 0111 11001110 1110 11100011 1111 10001111 11101111 11101111 *** *** *** * * * *** *** * * * *** ** *** ** *** *** ***** ***** ** ** *** ** *** ***** ***** ***** ** *** ** *** ** *** ***** **
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 first eight bits are zero – just have a > look at the set bits :-) > > > What am I missing? > > There are more bytes to look at, for example > > (gdb) p /t bitmap->buffer[1] > $3 = 11 > (gdb) p /t bitmap->buffer[2] > $4 = 1000 > > etc., etc. > I rendered the glyph `A' in this way and I am attaching the glyphs rendered with the `gfdriver' and `gftype'. As seen in their glyphs, the problem is with the glyph's pitch, width and rows . I'll fix them up :-) Thanks. Parth glyphAbitmap_gfdriver Description: Binary data glyphAbitmap_gftype Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates for gf driver.
> > >> 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 extract the data for required glyph > > according to its `glyph_index' from the table, like the `bdf' > > format. Then how can this be changed? > > The steps should be as follows. > > gf_load_font: > Check whether the file in question is using the GF format. If yes, > load all character locators into an array, together with some other > useful global data like `hppp' or the global bounding box. > > GF_Face_Init: > Initialize a `GF_Face' structure with the data loaded by > `gf_load_font' and construct additional stuff like a charmap. > > GF_Glyph_Load: > Look up the character locator, load the corresponding GF glyph, > parse it, and fill up the face's `FT_GlyphSlot' object. > Yes! I get that. Thanks. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates for gf driver.
> > >> 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 blocks for the glyph > > bitmaps to be loaded and then according to the font file it > > initializes the required blocks. So, when `ftexample.c' asks for a > > character it first loads all the initialised glyphs and then > > extracts the correct one. > > This is bad. 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 extract the data for required glyph according to its `glyph_index' from the table, like the `bdf' format. Then how can this be changed? Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates for gf driver.
> > > * If I display the 7 rows bit-wise, I get this: > >> > >> 00111000 > >> 0001 > >> 01101100 > >> 1010 > >> 00101000 > >> 00000000 > >> 01000100 > >> > >> Whatever this is, it looks cut off. > > > > I don't know how to display such bit-wise rows, can you please share > > the code for this? > > 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'. What am I missing? Please help. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates for gf driver.
> > > ==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 glyph... Oh, this may be because of 128 glyph objects + 1 GF_Glyph object. Actually, the GF driver always allocates 256 blocks for the glyph bitmaps to be loaded and then according to the font file it initializes the required blocks. So, when `ftexample.c' asks for a character it first loads all the initialised glyphs and then extracts the correct one. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates for gf driver.
>
> [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 correctly. In function `draw_bitmap'
> there is the following comment:
>
> /* for simplicity, we assume that `bitmap->pixel_mode' */
> /* is `FT_PIXEL_MODE_GRAY' (i.e., not a bitmap font) */
>
> Surprise, surprise! GF *is* a bitmap font, where
> `bitmap->pixel_mode' is FT_PIXEL_MODE_MONO...
>
> In other words, you have to adapt both `draw_bitmap' and
> `show_image' to handle the mono format, having 1bit per pixel.
>
> Honestly spoken, it's kind of disappointing that you completely
> ignored this comment while modifying `ftexample.c'.
>
Uh Oh, Really sorry, It was an oversight.
* Irrespective of that, there are big memory leaks. Calling
>
> FT2_DEBUG=any:7 \
> valgrind --leak-check=full \
> ./ftexample cmr10.600gf 0 \
> 2> ftexample.log
>
> gives the attached log (using a `make devel; make' compilation).
>
I think this is because of the `gf_free_font' function which certainly has,
some problems I am working on a patch, and will work it out soon.
> * The next peculiarity is the size of the created bitmap. I'm not
> sure what glyph gets displayed at index 48 (the charcode value of
> `0' as used in the command above), but the height of the resulting
> bitmap size, 4x7, looks far too small.
>
Ok. I'll check this.
* Showing `bitmap' at begin of `draw_bitmap' with the debugger, I see
>
> (gdb) p *bitmap
> $1 = {
> rows = 7,
> width = 4,
> pitch = 5,
> buffer = 0x76f440 "",
> num_grays = 0,
> pixel_mode = 1 '\001',
> palette_mode = 0 '\000',
> palette = 0x0
> }
>
> which is also strange: A pitch of 5 implies at least a width of
>
> 4 * 8 + 1 = 33
>
> pixels (since we have 8 pixels per byte). However, `width' has
> value 4...
>
I'll fix this.
* If I display the 7 rows bit-wise, I get this:
>
> 00111000
> 0001
> 01101100
> 1010
> 00101000
> 00000000
> 01000100
>
> Whatever this is, it looks cut off.
>
>
I don't know how to display such bit-wise rows, can you please
share the code for this?
Please fix these issues ASAP!
>
Yes! I will :-)
Thank you
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problems in GF_Glyph_Load function.
> > > 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 possible error? Please help. > > Right now I'm on vacation, doing some hiking in Tyrol. Maybe today > evening I can have a look – in case I'm not too tired. No promises, > sorry. > Ok. No problem. Thanks. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 return the glyph bitmap table.
>> >> > Can anyone please point out where the error can be.
>> >>
>> >> Obviously, the size object doesn't contain the right GF_Face
>> >> object.
>> >
>> > But, then this way works for bdf and winfont. Why is it so?
>>
>> I guess there is a buglet somewhere...
>
>
> I checked through gdb, it shows that the address of `GF_Face' does not
> change
> and is the same as returned by `FT_SIZE_FACE', Can there be any
> other problem? please help.
> Here is the output of gdb...
>
>
> Breakpoint 1, main (argc=3, argv=0x7fffdb78) at ftexample.c:72
> 72{
> (gdb) watch -l face
> Hardware watchpoint 2: -location face
> (gdb) c
> Continuing.
> Hi I am here1
> Hi I am here2
> FT_Open_Face: Requesting face 0
> FT_Stream_Open: opened `cmr10.600gf' (24148 bytes) successfully
> TTF driver
> SFNT driver
> not a font using the SFNT container format
> Type 1 driver
> not a Type 1 font
> CFF driver
> SFNT driver
> not a font using the SFNT container format
> not a CFF font header
> CID driver
> not a CID-keyed font
> PFR driver
> not a PFR font
> Type 42 driver
> not a Type42 font
> Windows FNT driver
> not a Windows FNT file
> PCF driver
> ... try gzip stream
> ... try LZW stream
> ... try Bzip2 stream
> not a PCF file
> BDF driver
> not a BDF file
> GF driver
> gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found
> gf_load_font: GF Postamble found
> gf_load_font: Allocated bitmap table
> number of glyphs: allocated 128 go->code_min is 0 and go->code_max is 255
> FT_Open_Face: New face object, adding to list
> FT_Open_Face: Creating glyph slot
> FT_New_GlyphSlot: Creating new slot object
> FT_New_GlyphSlot: Return 0x0
> FT_Open_Face: Creating size object
>
> Hardware watchpoint 2: -location face
>
> Old value = (struct FT_FaceRec_ *) 0x7
> New value = (struct FT_FaceRec_ *) 0x557a9360
> 0x77b22c8d in ft_open_face_internal (library=0x557a84c0,
> args=args@entry=0x7fffd990, face_index=0,
> aface=0x7fffda28, test_mac_fonts=test_mac_fonts@entry=1 '\001')
> at /home/parth/freetype-devel/src/base/ftobjs.c:2623
> 2623 *aface = face;
> (gdb) c
> Continuing.
> FT_Open_Face: Return 0x0
> Hi I am here3 face->num_glyphs is 128
> FT_Request_Size (gf driver):
> x scale: 0 (0.00)
> y scale: 0 (0.00)
> ascender: 0.00
> descender: 0.00
> height: 0.00
> max advance: 0.00
> x ppem: 0
> y ppem: 0
> Hi I am here
> Hi I am here in transform
> HI I am here in FT_Load_Char and glyph_index1 is 65
> HI I am here in FT_Load_Char and glyph_index2 is 65
> Hi I reached GF_Load_Glyph gf is 0x557a9360 face is 0x557a9360 /*
> In FT_SIZE_FACE */
> GF_Glyph_Load: glyph index 65
> invalid glyph index
> go->code_min is 0 and go->code_max is 0 /* here go->code_max should be 255
> if the GF_Face is properly extracted */
>
>
>
>
>
>
> FT_Done_Library: close faces for type42
> FT_Done_Library: close faces for truetype
> FT_Done_Library: close faces for type1
> FT_Done_Library: close faces for cff
> FT_Done_Library: close faces for t1cid
> FT_Done_Library: close faces for pfr
> FT_Done_Library: close faces for type42
> FT_Done_Library: close faces for winfonts
> FT_Done_Library: close faces for pcf
> FT_Done_Library: close faces for bdf
> FT_Done_Library: close faces for gf
>
> Hardware watchpoint 2: -location face
>
> Old value = (struct FT_FaceRec_ *) 0x557a9360
> New value = (struct FT_FaceRec_ *) 0x0
> 0x773b5872 in __GI___call_tls_dtors () at
> cxa_thread_atexit_impl.c:145
> 145cxa_thread_atexit_impl.c: No such file or directory.
> (gdb) Quit
> (gdb)
>
I found the buglet, it was in `gf_free_font' function. Now, it is properly
allocating the
`bitmap' and glyph metrics, 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
possible error? Please help.
This is the output from `ftexample':
FT_Request_Size (gf driver):
x scale: 0 (0.00)
y scale: 0 (0.00)
ascender: 0.00
descender: 0.00
height: 0.00
max advance: 0.00
x ppem: 0
y ppem: 0
Hi I am here
Hi I am here in transform
GF_Glyph_Load: glyph index 65
FT_Load_Glyph: index 65, flags 0x4
x advance: 6.343750
y advance: 2.953125
linear x advance: 0.00
linear y advance: 0.00
bitmap 7x7, monochrome bitmap (mode 1)
Thank you
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 return the glyph bitmap table.
> >> > Can anyone please point out where the error can be.
> >>
> >> Obviously, the size object doesn't contain the right GF_Face
> >> object.
> >
> > But, then this way works for bdf and winfont. Why is it so?
>
> I guess there is a buglet somewhere...
I checked through gdb, it shows that the address of `GF_Face' does not
change
and is the same as returned by `FT_SIZE_FACE', Can there be any
other problem? please help.
Here is the output of gdb...
Breakpoint 1, main (argc=3, argv=0x7fffdb78) at ftexample.c:72
72{
(gdb) watch -l face
Hardware watchpoint 2: -location face
(gdb) c
Continuing.
Hi I am here1
Hi I am here2
FT_Open_Face: Requesting face 0
FT_Stream_Open: opened `cmr10.600gf' (24148 bytes) successfully
TTF driver
SFNT driver
not a font using the SFNT container format
Type 1 driver
not a Type 1 font
CFF driver
SFNT driver
not a font using the SFNT container format
not a CFF font header
CID driver
not a CID-keyed font
PFR driver
not a PFR font
Type 42 driver
not a Type42 font
Windows FNT driver
not a Windows FNT file
PCF driver
... try gzip stream
... try LZW stream
... try Bzip2 stream
not a PCF file
BDF driver
not a BDF file
GF driver
gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found
gf_load_font: GF Postamble found
gf_load_font: Allocated bitmap table
number of glyphs: allocated 128 go->code_min is 0 and go->code_max is 255
FT_Open_Face: New face object, adding to list
FT_Open_Face: Creating glyph slot
FT_New_GlyphSlot: Creating new slot object
FT_New_GlyphSlot: Return 0x0
FT_Open_Face: Creating size object
Hardware watchpoint 2: -location face
Old value = (struct FT_FaceRec_ *) 0x7
New value = (struct FT_FaceRec_ *) 0x557a9360
0x77b22c8d in ft_open_face_internal (library=0x557a84c0,
args=args@entry=0x7fffd990, face_index=0,
aface=0x7fffda28, test_mac_fonts=test_mac_fonts@entry=1 '\001') at
/home/parth/freetype-devel/src/base/ftobjs.c:2623
2623 *aface = face;
(gdb) c
Continuing.
FT_Open_Face: Return 0x0
Hi I am here3 face->num_glyphs is 128
FT_Request_Size (gf driver):
x scale: 0 (0.00)
y scale: 0 (0.00)
ascender: 0.00
descender: 0.00
height: 0.00
max advance: 0.00
x ppem: 0
y ppem: 0
Hi I am here
Hi I am here in transform
HI I am here in FT_Load_Char and glyph_index1 is 65
HI I am here in FT_Load_Char and glyph_index2 is 65
Hi I reached GF_Load_Glyph gf is 0x557a9360 face is 0x557a9360 /*
In FT_SIZE_FACE */
GF_Glyph_Load: glyph index 65
invalid glyph index
go->code_min is 0 and go->code_max is 0 /* here go->code_max should be 255
if the GF_Face is properly extracted */
FT_Done_Library: close faces for type42
FT_Done_Library: close faces for truetype
FT_Done_Library: close faces for type1
FT_Done_Library: close faces for cff
FT_Done_Library: close faces for t1cid
FT_Done_Library: close faces for pfr
FT_Done_Library: close faces for type42
FT_Done_Library: close faces for winfonts
FT_Done_Library: close faces for pcf
FT_Done_Library: close faces for bdf
FT_Done_Library: close faces for gf
Hardware watchpoint 2: -location face
Old value = (struct FT_FaceRec_ *) 0x557a9360
New value = (struct FT_FaceRec_ *) 0x0
0x773b5872 in __GI___call_tls_dtors () at
cxa_thread_atexit_impl.c:145
145cxa_thread_atexit_impl.c: No such file or directory.
(gdb) Quit
(gdb)
Thank you
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 return the glyph bitmap table. Can anyone please point out where > > the error can be. > > Obviously, the size object doesn't contain the right GF_Face object. > But, then this way works for bdf and winfont. Why is it so? Hard to say more without running the debugger. I suggest that you > check the address of the created GF_Face object; it should be the same > as returned by FT_SIZE_FACE. If you get a different address you have > to find out where the FT_Face object within FT_Size is set and > possibly changed. To track changes, you can probably use the > > watch -l ... > > command within gdb. > Ok, I'll do that. Thanks. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 bitmap table. Can anyone please point out where the error can be. Please help. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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' command. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 does not get confused for `freetype-config'. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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'. > >> > > > > Ok, so if the `xxx' commands are found at the beginning I will skip > > over them and for `xxx' and `yyy' commands at the end I' ll parse > > them. > > No. Please always parse them and skip the unknown (or uninteresting) > ones. > Ok. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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, in their postambles the `loc' > > defines a pointer to the `xxx1' command which defines some extra > > information about the character and then later gives the character > > bitmap. Now, Vflib handles fonts only of the type `cmr10.600gf', > > i.e., it does not have provision of handling `xxx1' commands after > > coming from the postamble. What should I do to solve this problem? > > Should I provide a support for `xxx1' commands? I have been using > > `cmr10.600gf' for testing and that is why I did not encounter this > > earlier. > > *Any* type of GF files should be readable by the FreeType driver. > Yes > Most of the `xxx' and `yyy' data at the beginning of the characters > are not useful in general (IIRC, they are only parsed by the `gftodvi' > driver to provide tags and positions for named points). This is > different to the `xxx' and `yyy' data at the end of the file, which > (by convention only) holds very useful information to classify the > font. > `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'. > Ok, so if the `xxx' commands are found at the beginning I will skip over them and for `xxx' and `yyy' commands at the end I' ll parse them. Thanks Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 gf_free_font functions are malformed, I will redefine them. * Complete check through all the parent fields which are allocated from the font file as there are some issues in their unit conversions. * Do a single step debugging through the code with a debugger, so that there remains no error in the functions. * Define a program derived from `example1.c' to check for the output of the driver. Please tell me if there are any other instructions which I should follow. Thank you. -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 > >> formats but GF... > > > > I did not mean that the error was in ftview, but I wanted to know > > where the driver was failing to allocate proper values in ftview. > > I have no idea. You should single-step through the code with a > debugger... – at least this is what I would do. > Ok. > > Yes, I was working on it, as I did `make devel; make', but could not > > figure out why this was not working, I thought first I give a try to > > learn it and then ask for doubts. > > Well, we are six weeks after starting the project – this seems rather > a long time for learning... > > Also, I am not well acquainted with valgrind, so I was learning it > > first and then I was going to reply you. > > Actually, there is nothing to learn except calling it! The produced > output is almost self-explanatory IMHO. > Ok. > >> BTW, what simple program are you using to check whether the GF > >> module works? > > > > No, I am not using them. I am directly using ftview to check for > > its working. > > This is not optimal, since `ftview' uses the caching code, making > everything a bit more complicated (as you have already notived). I > strongly suggest to use a small program derived from the tutorial's > `example1.c' program. Then you can do two debugger sessions in > parallel, one opening a PCF file, say, the other one opening a GF > file. It should then quickly become obvious where the problems in > your code are. > Ok. This is nice. Thank you -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 glyphs are in your font? > 128 > How does the failure in ftview looks like? > No, there is no error in ftview, I wanted to know what can be the reasons that the driver is not allocating it properly like possible error sources in the driver code. Thanks. -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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, > > [...] > > 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 formats > but GF... > I did not mean that the error was in ftview, but I wanted to know where the driver was failing to allocate proper values in ftview. > Attached you can find small fixes to make output of the first `make' > call prettier, and to allow `make devel; make' actually work. I've > also attached the log output of `make devel'; as you can see there are > zillions of warnings that you still have to take care of – if I > remember correctly, I advised you to use `make devel; make' for > development, and it is not clear to me why you didn't follow this > advice... Yes, I was working on it, as I did `make devel; make', but could not figure out why this was not working, I thought first I give a try to learn it and then ask for doubts. Also, I am not well acquainted with valgrind, so I was learning it first and then I was going to reply you. At least you should have analyzed what it does and transfer > the used compiler flags to your build environment. > My bad, really sorry for this, I was in the zeal of moving ahead and as the program was compiling and I ignored those flags. I will fix those asap. Thanks. > After fixing those buglets I compiled the demo programs, and the call > > ftview 20 cmr10.2602gf > > crashed immediately. Running with valgrind gives > > Conditional jump or move depends on uninitialised value(s) > at 0x47D79D: gf_free_font (gflib.c:466) > by 0x47D962: GF_Face_Done (gfdrivr.c:145) > by 0x414CA0: open_face (ftobjs.c:1404) > by 0x416971: ft_open_face_internal (ftobjs.c:2447) > by 0x414D53: FT_New_Face (ftobjs.c:1438) > by 0x40AB1B: FTDemo_Install_Font (ftcommon.c:396) > by 0x408B7C: main (ftview.c:1887) > > Use of uninitialised value of size 8 > at 0x47D7A3: gf_free_font (gflib.c:468) > by 0x47D962: GF_Face_Done (gfdrivr.c:145) > by 0x414CA0: open_face (ftobjs.c:1404) > by 0x416971: ft_open_face_internal (ftobjs.c:2447) > by 0x414D53: FT_New_Face (ftobjs.c:1438) > by 0x40AB1B: FTDemo_Install_Font (ftcommon.c:396) > by 0x408B7C: main (ftview.c:1887) > > Invalid read of size 8 > at 0x47D7A3: gf_free_font (gflib.c:468) > by 0x47D962: GF_Face_Done (gfdrivr.c:145) > by 0x414CA0: open_face (ftobjs.c:1404) > by 0x416971: ft_open_face_internal (ftobjs.c:2447) > by 0x414D53: FT_New_Face (ftobjs.c:1438) > by 0x40AB1B: FTDemo_Install_Font (ftcommon.c:396) > by 0x408B7C: main (ftview.c:1887) >Address 0x20008 is not stack'd, malloc'd or (recently) free'd > > So you have to find out why this happens. Note that the problem > happens with *any* file not recognized by other drivers as a font. > Yes I will work on it. For example, you can say > > ftview 20 make.log > > to trigger the bug... > > If I remember correctly I also advised you to add calls to the various > `FT_TRACEX' macros, which both helps you and the user in debugging > issues. Now is the time to do that! > Ok. > BTW, what simple program are you using to check whether the GF module > works? For example, have you adapted > > https://www.freetype.org/freetype2/docs/tutorial/example1.c > > to your needs? Please post it. > No, I am not using them. I am directly using ftview to check for its working. > You should work hard to resolve those issues. Second evaluation is > coming soon... > Yes! I will :-) Thanks. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 any other possibilities? > Also, I think I am missing out on the understanding about the > > idea of cache in FT. Please help me with this. > > Do not worry about it. It will work once you fixed errors like the one > above and ftview displays glyphs. > Ok . 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 on the understanding about the idea of cache in FT. Please help me with this. Also, have you tested the gf driver? Did you find any direct errors, which needs to be addressed first, please let me know? 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
> > > * 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. >> > > I have cleaned up the code and now gf driver has all the code required > to run the driver, the driver is now properly extracting the information > correctly from the font file. All the `gf_driver_class' functions are also > complete now. > But, when I run `ftview' it is giving errors somewhere, it loads 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 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 has all the code required > to run the driver, the driver is now properly extracting the information > correctly from the font file. All the `gf_driver_class' functions are also > complete now. > But, when I run `ftview' it is giving errors somewhere, it loads the > display > but after a while gives a segmentation fault. After some debugging I found > out that the error is in the `FTC_Manager_LookupFace' function. I am > unable > to figure out the error here. Please help me with this. > I have added final code with printf flags to the branch `parthw-wip'. This > code is > unclean, 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] GSoC Status update
> > > * 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 has all the code required to run the driver, the driver is now properly extracting the information correctly from the font file. All the `gf_driver_class' functions are also complete now. But, when I run `ftview' it is giving errors somewhere, it loads the display but after a while gives a segmentation fault. After some debugging I found out that the error is in the `FTC_Manager_LookupFace' function. I am unable to figure out the error here. Please help me with this. I have added final code with printf flags to the branch `parthw-wip'. This code is unclean, please ignore that. Thank you -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 on it as I move ahead with the testing of gf driver. * There still remains the error checking and tracing part of the gf driver, which I will eventually add. Please let me know if there are any instructions or feedback you wish to give me. Thank you -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 (size >= 1)
> > {
> > v = v*256L + (unsigned long)FT_Stream_ReadULong(stream, );
> > stream->pos-=3;
>
> ??? The `v*256' only makes sense if you read a single byte in the
> loop! If you read 4 bytes in a loop, the value must be
> v*256*256*256*256.
>
> > --size;
> > }
> > return v;
> > }
>
> You also have to take care of the byte order in GF files if you read
> more than a single byte.
>
> Finally, it's not clear to me why you directly use
> `FT_Stream_ReadULong' and not one of the many macros like
> `FT_READ_ULONG' (or `FT_READ_ULONG_LE').
Uh Oh, Sorry for that I just got carried away. I'll change it.
I strongly suggest that you
> imitate code present in other font modules. Don't reinvent the
> wheel...
>
Yes.
Thanks.
--
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 functions,...
unsigned long
gf_read_uintn(FILE* fp, int size)
{
unsigned long v;
v = 0L;
while (size >= 1)
{
v = v*256L + (unsigned long)getc(fp);
--size;
}
return v;
}
...used to read different number of bytes with different size values from
the i/p file.
* Now the problem is I converted it to this...
unsigned long
gf_read_uintn(FT_Stream stream, int size)
{
unsigned long v;
FT_Error error = FT_Err_Ok;
v = 0L;
while (size >= 1)
{
v = v*256L + (unsigned long)FT_Stream_ReadULong(stream, );
stream->pos-=3;
--size;
}
return v;
}
...for using stream, it works fine for size 1, but returns errors with size
4. I tried figuring
the error but could not do so. I am getting confused about the relation
between file pointer
and stream position and the usage of getc vs FT_Stream_ReadULong.
Please help me with this.
Thanks.
--
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.
> > >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 wrong interface. >Function `gf_load_font' gets an `FT_Stream' object; this means you can > >use the FT_STREAM_XXX macros, for example `FT_STREAM_SEEK'. Oh, I was planning to get the driver first running by using the file functions directly and then eventually convert to the FT specific stream macros. Currently I was also facing issues when ftview went into FTC_Manager_LookupFace and it was giving a segmentation fault, I was just figuring out what was the error, but it seems the usage of file functions here is causing problems. Now I can first focus on converting the stream usage. Thanks! >I suggest that you have a look (again :-) into `winfnt.c'. > Yes! Will do. Thanks! -- 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 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 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.
> > >> 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] [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 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
[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: /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] 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? > > >I don't know yet. I would have to study the GF format in detail to > >find out such issues – I forward this to you :-) > Yes! I will do it. * There is no code yet in `gf_load_font' to recognize the GF > format (returning `not a GF font' otherwise). > >> > >> Isn't this same as done above, for `Invalid_File_Format`? > > >No, it's not. If the format is not recognized, this is, the GF driver > >has decided that the font in question is not a GF font, the driver > >should return `Unknown_File_Format'. > >Later on, if the GF drvier has come to the decision: `Yes, this is > >definitely a GF font', all problems that can't be sanitized should > >lead to `Invalid_File_Format' (or one of the more specific error > >codes). > Oh! I didn't differentiate amongst these two. I will do the necessary changes. Thanks! -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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, please mail me if you need any help with comment formatting
> and the scripts.
>
Yeah! Thanks!
>
>
>> * `GF_Face_Init':
>>
>> - you have isolated code blocks `{ ... }' (not part of `if', `for',
>> etc.) that are indented too much. [...]
>>
>> * Minor formatting nit: Please indent switch statements as
>>
>> switch (foo)
>> {
>> bar:
>> blabla();
>> baz:
>> urgh();
>> }
>>
>> In general, labels are outdented by two spaces.
>> [...]
>> * There are still some tab characters in the source code...
>>
>
> Looking at this and previous formatting related discussions on the
> mailing list, I believe we should have a separate code formatting guide
> for developers :-)
>
Actually as explained by Werner they were not actually formatting related
changes,
but errors due to my unconfigured editor for tabs and spaces (Which I have
configured now :-) ). Which I understood after the discussions here.
--
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 for the GF driver. I have also made most of the changes
> >> which you instructed in the last mail.
>
> >Great!
>
> >> Currently I am working on the possibilities of filling the parent
> >> fields from the driver specific variables. Once I complete this I
> >> will move to building the driver and removing the possible errors.
>
> >OK.
>
> >> Now for checking the output I wish to use the example code for
> >> testing. I wanted to ask if you suggest any other way to check the
> >> output of the driver.
>
> >What about adding a lot of tracing messages to get output similar (but
> >not necessarily identical or as detailed) to `gftype -mnemonics' and
> >later on `pktype'? This should simplify verification of the code.
>
Yes! Will do.
> >Later on, I suggest that you simply build `ftview'; it should
> >automatically handle GF files if the driver is properly installed into
> >FreeType.
>
Ok
>
> >> Also I want to ask you for any feedback or instructions you wish to
> >> give me. [...]
>
> >I did
>
> > git diff f999375 1c48e9a
>
> >to compare `master' with `parthw-wip'. Here are my remarks.
>
> >* Does your code already compile? If not, I suggest to add dummy code
> > to achieve that. In general, it is always a good idea to have only
> > compilable code in the repository, since it makes `git bisect' much
> > easier later on.
>
Ok.
> >* Run Nikhil's `docconverter.py' and `markify.py' scripts (from his
> > `freetype-docs' repository) to convert all block comments into the
> > `light' format.
Yes.
> And please check whether the headers are correct –
> > for example, `gflib.c' identifies itself as `gfdrivr.h'...
>
Uh oh, Sorry I missed that.
> >* `GF_Face_Init':
>
> > - you have isolated code blocks `{ ... }' (not part of `if', `for',
> >etc.) that are indented too much.
>
Ok.
> > - Setting the PID/EID values of the cmap to `Apple Unicode/Apple ID
> >default' is just dummy code, right?
Yes ;)
> >Most certainly you need to
> >parse
>
> > xxx 'codingscheme=TeX text'
>
> >(as shown by `gftype' if present in the GF file) to get the right
> > character to glyph mapping – those tables are missing, too.
>
Yes. I think I will have to study this part a bit. Thanks.
>Please mark such code as preliminary so that I know that something
> >is still missing.
>
Will take care from next time
> >* Minor formatting nit: Please indent switch statements as
>
> >switch (foo)
> >{
> >bar:
> > blabla();
> >baz:
> > urgh();
> >}
>
> > In general, labels are outdented by two spaces.
>
Ok
> >* Robustness: Please have always in mind that malformed GF files must
> > be either sanitized or properly rejected. Not sure whether this is
> > an issue, but GF commands like `paint3' can handle quite large
> > values...
>
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? And yes I'll check for the paint3 part.
> >* There is no code yet in `gf_load_font' to recognize the GF format
> > (returning `not a GF font' otherwise).
Isn't this same as done above, for `Invalid_File_Format`?
> > According to `texdoc gftype'
> > it seems that you should test for (GF_PRE,131) as the first two
> > bytes, followed by some more tests to be rather sure that the font
> > is a GF file at all.
>
Ok.
It currently checks for GF_POST_POST, GF_POST and GF_ID. I will also add
functionality for GF_PRE.
>* There are still some tab characters in the source code...
>
Uh Oh. Sorry for that.
Thank you
--
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
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
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 oversight. Please prepare a patch for master to remove > >the corresponding code – together with a ChangeLog entry :-) > Thanks! Will do! ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 help. Thank you -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 default is > > 8 spaces = 1 tab). > Yes I'll do. I also had this doubt about why did the code lost proper indentation when I looked it on cgit. > > [I know that this is your branch where you can do whatever you like, > > but you asked for review, and good indentation similar to the rest > > of the FreeType code makes a review simpler for me :-)] > I'll take care about it in future :) > >* There are some comments of the form > > >/*foo*/ > > > Please replace this eventually with > > >/* foo */ > > (And please don't use `//' comments in the final code.) > Yes will do! > >* Avoid trailing spaces, which stick out in ugly red if I use `git > > diff' :-) Many editors can be configured to automatically remove > > trailing spaces as soon as you are saving the file. > I'll take care of it. btw which editor you suggest to use? > >* gf.h: `INT1', `UINT1', etc. should be removed. The code should then > > use `FT_Int', `FT_UInt', etc. This is a minor issue and not urgent. > > >* Maybe you can replace `READ_INT1' and friends with similar macros > > and functions already defined in FreeType? This is another minor > > issue. > > >* It might make sense to replace `int' and friends with smaller data > > types like `FT_UShort' in structure arrays where possible to get a > > smaller memory footprint. (The stress is on `might' – maybe this is > > overkill.) > > >* Please avoid the use of `float' and `double'. Right now, FreeType > > uses integer arithmetic only; `double' is only used for defining > > compile-time constants and in debug mode for displaying tracing > > messages. > I'll do it eventually. > > Theoretically, this shouldn't be very difficult since all parts of > > TeX are using integer arithmetic only – GF, PK, and TFM are no > > exception. > Yes! Thank you -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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. Now after some research, I understand certain points they are: 1. Each font file may have multiple charmaps for different charachters. 2. The functions in FT_CMap_ClassRec i.e cmap_init, cmap_done, etc. Initializes the charmaps of different characters in FT_Face according to the font file. Now bdf fonts are ASCII encoded, then why is their a provision of multiple encodings in its implementation? Also, bdf fonts maintain a table for character wise encodings, whereas winfonts just maintains a pointer to the first charachter and a counter of number of characters to return character wise charmaps. Now gf files are ASCII encoded, then what type of implementation should it have? Thank you -- Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
