Hi all, I have just uploaded the archives for luatex 0.31.0. This is just an intermediate release so that some testing can be done on the updated fontforge embedding. * There are new fields being generated by fontforge.to_table(), and one or two old ones have been removed. These fields are / will be documented in the manual, but very briefly: - MATH table and associated information are now exported (the main reason for the new fontforge code) - Baseline data is now exported (perhaps usable in lua code) - Multiple Master / Glyph variation data is now exported (but useless, for now) - Mac Feature (AAT) information is now exported (perhaps usable in lua code) - If (lookup) names were saved via the PfED table, these will the exported instead of the default, generated names. (as requested by Yannis) * dfont is now treated as an archive format just like ttc when it comes to fontforge.info(). NOTE: that does not mean you can actually use them, because the backend doesn't know yet how to embed dfont fonts in the PDF, that is on the TODO list for the next big beta (0.40.0). * The executables are a lot larger than before. That is because much more of fontforge is included than before. Likely this will stay this way, because this makes upgrading the ff code much easier, and it means that luatex/FF potentially understands more font formats (after upgrading the backend, of course) The archives (just binaries this time) can be downloaded from supelec as usual: http://foundry.supelec.fr/projects/luatex/ If you need the sources, please check out via anonymous svn: svn co svn://scm.foundry.supelec.fr/svn/luatex/tags/beta-0.31.0 Bugs and feature requests can be added to the issue tracker at http://tracker.luatex.org Have fun, Taco _______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
On Fri, Dec 5, 2008 at 5:21 PM, Taco Hoekwater wrote:
Hi all,
I have just uploaded the archives for luatex 0.31.0.
Hello Taco, After all that negging about supporting solaris, here are some more reports from Mac OS X: g++ -o luatex luatexini.o luatex0.o luatex1.o luatex2.o luatex3.o luatexextra.o luatex-pool.o ../../libs/md5/md5.o ../../libs/slnunicode/slnunico.o ../../libs/luazip/src/luazip.o ../../libs/luafilesystem/src/lfs.o ../../libs/luapeg/lpeg.o ../../libs/luamd5/md5lib.o ../../libs/luamd5/md5.o ../../libs/luazlib/lgzip.o ../../libs/luazlib/lzlib.o mpdir/lmplib.o luatexdir/libpdf.a ../../libs/libpng/libpng.a ../../libs/zlib/libz.a ../../libs/xpdf/xpdf/libxpdf.a ../../libs/xpdf/goo/libGoo.a ../../libs/xpdf/fofi/libfofi.a ../../libs/obsdcompat/libopenbsd-compat.a ../../libs/lua51/liblua.a ../../libs/zziplib/zzip/libzzip.a ../../libs/luasocket/src/socket.a ../../libs/luafontforge/libff.a mpdir/.libs/libmplib.a lib/lib.a ../kpathsea/.libs/libkpathsea.a -lm /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: _libintl_gettext _FSCloseFork _FSCreateFileUnicode _FSCreateFork _FSGetResourceForkName _FSOpenFork _FSPathMakeRef _FSSetForkSize _FSWriteFork collect2: ld returned 1 exit status make: *** [luatex] Error 1 Mojca
Mojca Miklavec wrote:
On Fri, Dec 5, 2008 at 5:21 PM, Taco Hoekwater wrote:
Hi all,
I have just uploaded the archives for luatex 0.31.0.
Hello Taco,
After all that negging about supporting solaris, here are some more reports from Mac OS X:
g++ -o luatex luatexini.o luatex0.o luatex1.o luatex2.o luatex3.o luatexextra.o luatex-pool.o ../../libs/md5/md5.o ../../libs/slnunicode/slnunico.o ../../libs/luazip/src/luazip.o ../../libs/luafilesystem/src/lfs.o ../../libs/luapeg/lpeg.o ../../libs/luamd5/md5lib.o ../../libs/luamd5/md5.o ../../libs/luazlib/lgzip.o ../../libs/luazlib/lzlib.o mpdir/lmplib.o luatexdir/libpdf.a ../../libs/libpng/libpng.a ../../libs/zlib/libz.a ../../libs/xpdf/xpdf/libxpdf.a ../../libs/xpdf/goo/libGoo.a ../../libs/xpdf/fofi/libfofi.a ../../libs/obsdcompat/libopenbsd-compat.a ../../libs/lua51/liblua.a ../../libs/zziplib/zzip/libzzip.a ../../libs/luasocket/src/socket.a ../../libs/luafontforge/libff.a mpdir/.libs/libmplib.a lib/lib.a ../kpathsea/.libs/libkpathsea.a -lm /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: _libintl_gettext
This one is simple to fix, I forgot to suppress libintl (gettext) in fontforge's configuration. There are two lines containing #undef HAVE_LIBINTL_H inside src/libs/luafontforge/fontforge/inc/config.h.in (one is enough really, the other one is a fluke) If you put those in C comment tags (like the _HAS_LONGLONG is already) then this error will go away, I am sure.
_FSCloseFork _FSCreateFileUnicode _FSCreateFork _FSGetResourceForkName _FSOpenFork _FSPathMakeRef _FSSetForkSize _FSWriteFork
These are a bit trickier, they probably need an extra linked library. It is caused by the fontforge code for reading Mac fonts, and that of course has a if define(__MAC) in the C source, which is why it works fine on unix/win where the filesystems simpler. Can you send me the generated Makefiles in the fontforge subdirectory? Best wishes, Taco
"TH" == Taco Hoekwater writes:
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: _libintl_gettext
TH> This one is simple to fix, I forgot to suppress libintl (gettext)
TH> in fontforge's configuration. There are two lines containing
TH> #undef HAVE_LIBINTL_H
TH> inside src/libs/luafontforge/fontforge/inc/config.h.in (one is
TH> enough really, the other one is a fluke)
TH> If you put those in C comment tags (like the _HAS_LONGLONG is
TH> already) then this error will go away, I am sure.
maybe it fixed apple-darwin, but it broke sparc-solaris. :(
here is why:
* on solaris, there IS /usr/include/libintl.h, so HAVE_LIBINTL_H
would've been normally defined. but hardwiring "#undef HAVE_LIBINTL_H"
fools the libs/luafontforge/fontforge/inc/intl.h to believe that there
is no libintl.h in the system, and it executes the branch
"#if !defined( HAVE_LIBINTL_H )" which has:
# define bindtextdomain(domain,dir)
# define bind_textdomain_codeset(domain,enc)
# define textdomain(domain)
# define dgettext(domain,str) (str)
* then, many fontforge headers have #include
Vladimir Volovich wrote:
while this does not look like a right fix (the problem seems to be caused by fooling intl.h by "#undef HAVE_LIBINTL_H" above), it seems to fix the build process.
this was somehow lost during recent upgrade of fontforge in luatex.
is it possible to fix the problem upstream (in fontforge) so it won't re-appear again after another update of fontforge in luatex?
I've reinstated that fix (in trunk). I'll send a message to fontforge-devel once everything seems to work. Best wishes, Taco
Hi, Taco :
[yue@localhost ~]$ cd beta-0.31.0/
[yue@localhost ~/beta-0.31.0]$ ./build.sh
... lots of information ...
checking spiroentrypoints.h usability... no
checking spiroentrypoints.h presence... no
checking for spiroentrypoints.h... no
checking for xmlParseFile in -lxml2... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking ieeefp.h usability... yes
checking ieeefp.h presence... yes
checking for ieeefp.h... yes
checking for stdint.h... (cached) yes
checking fontconfig/fontconfig.h usability... no
checking fontconfig/fontconfig.h presence... no
checking for fontconfig/fontconfig.h... no
../../../../src/libs/luafontforge/fontforge/configure: 24004: Syntax
error: Bad fd number
[yue@localhost ~]$ uname -a
FreeBSD localhost 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Tue Nov 11
16:54:35 UTC 2008 root@localhost:/usr/obj/usr/src/sys/KERNEL i386
[yue@localhost ~]$
Yue Wang
On Fri, Dec 5, 2008 at 4:21 PM, Taco Hoekwater
Hi all,
I have just uploaded the archives for luatex 0.31.0.
This is just an intermediate release so that some testing can be done on the updated fontforge embedding.
* There are new fields being generated by fontforge.to_table(), and one or two old ones have been removed. These fields are / will be documented in the manual, but very briefly:
- MATH table and associated information are now exported (the main reason for the new fontforge code) - Baseline data is now exported (perhaps usable in lua code) - Multiple Master / Glyph variation data is now exported (but useless, for now) - Mac Feature (AAT) information is now exported (perhaps usable in lua code) - If (lookup) names were saved via the PfED table, these will the exported instead of the default, generated names. (as requested by Yannis)
* dfont is now treated as an archive format just like ttc when it comes to fontforge.info(). NOTE: that does not mean you can actually use them, because the backend doesn't know yet how to embed dfont fonts in the PDF, that is on the TODO list for the next big beta (0.40.0).
* The executables are a lot larger than before. That is because much more of fontforge is included than before. Likely this will stay this way, because this makes upgrading the ff code much easier, and it means that luatex/FF potentially understands more font formats (after upgrading the backend, of course)
The archives (just binaries this time) can be downloaded from supelec as usual:
http://foundry.supelec.fr/projects/luatex/
If you need the sources, please check out via anonymous svn:
svn co svn://scm.foundry.supelec.fr/svn/luatex/tags/beta-0.31.0
Bugs and feature requests can be added to the issue tracker at
Have fun, Taco
_______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex _______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Yue Wang wrote:
Hi, Taco :
[yue@localhost ~]$ cd beta-0.31.0/ [yue@localhost ~/beta-0.31.0]$ ./build.sh ... lots of information ... checking spiroentrypoints.h usability... no checking spiroentrypoints.h presence... no checking for spiroentrypoints.h... no checking for xmlParseFile in -lxml2... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking ieeefp.h usability... yes checking ieeefp.h presence... yes checking for ieeefp.h... yes checking for stdint.h... (cached) yes checking fontconfig/fontconfig.h usability... no checking fontconfig/fontconfig.h presence... no checking for fontconfig/fontconfig.h... no ../../../../src/libs/luafontforge/fontforge/configure: 24004: Syntax error: Bad fd number
Can you please post what is on line 24004 and its surroundings? Best wisses, Taco
Him I responded to Yue Wang by email already, but maybe someone else has an idea. Yue Wang wrote:
../../../../src/libs/luafontforge/fontforge/configure: 24004: Syntax error: Bad fd number
That line has a "fi" only, which makes absolutely no sense whatsoever. Maybe the script is too complex? I am baffled. The surrounding lines are: 23999- gww_haspango="done" 24000- break 24001- fi 24002- done 24003- fi 24004:fi 24005-if test "$gww_haspango" = "yes" ; then 24006- CFLAGS="$CFLAGS `pkg-config --cflags pangoxft`" 24007:fi 24008-if test "$gww_haspango" = "yes" -a "$gww_hascairo" = "yes" ; then 24009- if pkg-config --libs pangocairo >& /dev/null ; then Best wishes, Taco
Hi Taco, may I ask a completely uninformed question? I'm wondering whether it's also possible to access the glyphs' path data from within LuaTeX (and/ or MetaPost) ... Best, Oliver
Hi all,
I have just uploaded the archives for luatex 0.31.0.
This is just an intermediate release so that some testing can be done on the updated fontforge embedding.
* There are new fields being generated by fontforge.to_table(), and one or two old ones have been removed. These fields are / will be documented in the manual, but very briefly:
- MATH table and associated information are now exported (the main reason for the new fontforge code) - Baseline data is now exported (perhaps usable in lua code) - Multiple Master / Glyph variation data is now exported (but useless, for now) - Mac Feature (AAT) information is now exported (perhaps usable in lua code) - If (lookup) names were saved via the PfED table, these will the exported instead of the default, generated names. (as requested by Yannis)
* dfont is now treated as an archive format just like ttc when it comes to fontforge.info(). NOTE: that does not mean you can actually use them, because the backend doesn't know yet how to embed dfont fonts in the PDF, that is on the TODO list for the next big beta (0.40.0).
* The executables are a lot larger than before. That is because much more of fontforge is included than before. Likely this will stay this way, because this makes upgrading the ff code much easier, and it means that luatex/FF potentially understands more font formats (after upgrading the backend, of course)
The archives (just binaries this time) can be downloaded from supelec as usual:
http://foundry.supelec.fr/projects/luatex/
If you need the sources, please check out via anonymous svn:
svn co svn://scm.foundry.supelec.fr/svn/luatex/tags/beta-0.31.0
Bugs and feature requests can be added to the issue tracker at
Have fun, Taco
Oliver Buerschaper wrote:
Hi Taco,
may I ask a completely uninformed question? I'm wondering whether it's also possible to access the glyphs' path data from within LuaTeX (and/or MetaPost) ...
Not now. But that would be cool to have, so maybe someday. Best wishes, Taco
Hi, I have just uploaded luatex 0.31.1, hopefully fixing a bunch of compilation errors on various platforms, but with no other visible changes. The archives (just binaries this time, hopefully there will be a source package later) can be downloaded from supelec as usual: http://foundry.supelec.fr/projects/luatex/ If you need the sources, please check out via anonymous svn: svn co svn://scm.foundry.supelec.fr/svn/luatex/tags/beta-0.31.1 Bugs and feature requests can be added to the issue tracker at http://tracker.luatex.org Have fun, Taco
Hi, I have just uploaded luatex 0.31.2, in the ongoing attempt to fix build troubles. * I have now received succesful build reports from * linux on i386 * mingw32 (that is built by me) * freebsd on i386 * solaris on sparc * osx (intel & ppc) so it seems the source should be more or less ok now. Besides fixing building issues, this release has * A small fix for a crash that could happen when using external OCPs. * A fix in the format of fontforge.to_table output. (In 0.31.1 <font>.lookups was near-empty; the lookups were accidentally output as part of the gpos table). The archives (just binaries this time, hopefully there will be a source package later) can be downloaded from supelec as usual: http://foundry.supelec.fr/projects/luatex/ If you need the sources, please check out via anonymous svn: svn co svn://scm.foundry.supelec.fr/svn/luatex/tags/beta-0.31.2 Bugs and feature requests can be added to the issue tracker at http://tracker.luatex.org Have fun, Taco
On Wed, Dec 10, 2008 at 10:49:29AM +0100, Taco Hoekwater wrote:
* A small fix for a crash that could happen when using external OCPs.
Thanks for the fix. Another issue, with external OCPs, luatex easily exceeds maximum open files limit on linux an segfaults. A 20 pages ConTeXt file has around 3000 /tmp/__aleph__{in,out}* open files. I had to increase the max. limit to get around this. Regards, -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
Khaled Hosny wrote:
On Wed, Dec 10, 2008 at 10:49:29AM +0100, Taco Hoekwater wrote:
* A small fix for a crash that could happen when using external OCPs.
Thanks for the fix. Another issue, with external OCPs, luatex easily exceeds maximum open files limit on linux an segfaults. A 20 pages ConTeXt file has around 3000 /tmp/__aleph__{in,out}* open files. I had to increase the max. limit to get around this.
hm, why so many open files? ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Khaled Hosny wrote:
On Wed, Dec 10, 2008 at 10:49:29AM +0100, Taco Hoekwater wrote:
* A small fix for a crash that could happen when using external OCPs.
Thanks for the fix. Another issue, with external OCPs, luatex easily exceeds maximum open files limit on linux an segfaults. A 20 pages ConTeXt file has around 3000 /tmp/__aleph__{in,out}* open files. I had to increase the max. limit to get around this.
There was a missing fclose() in run_external_ocp. Fixed in SVN. Best wishes, Taco
On Thu, Dec 11, 2008 at 10:30:25AM +0100, Taco Hoekwater wrote:
Khaled Hosny wrote:
On Wed, Dec 10, 2008 at 10:49:29AM +0100, Taco Hoekwater wrote:
* A small fix for a crash that could happen when using external OCPs.
Thanks for the fix. Another issue, with external OCPs, luatex easily exceeds maximum open files limit on linux an segfaults. A 20 pages ConTeXt file has around 3000 /tmp/__aleph__{in,out}* open files. I had to increase the max. limit to get around this.
There was a missing fclose() in run_external_ocp. Fixed in SVN.
This actually fixes half the issue, luatex were keeping to open instants of each output file and one of each input file, now it keeps one of each. It turned out that each input and output file is opened twice because mkstemp() opens the newly created file and returns a file descriptor. The attached patch, almost copied from Omega's omegabis.c file, takes care of this. Regards, -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
Khaled Hosny wrote:
This actually fixes half the issue, luatex were keeping to open instants of each output file and one of each input file, now it keeps one of each. It turned out that each input and output file is opened twice because mkstemp() opens the newly created file and returns a file descriptor. The attached patch, almost copied from Omega's omegabis.c file, takes care of this.
Thanks, applied. Best wishes, Taco
Hi, I have just uploaded luatex 0.31.3. This release has a bunch of updates from the development trunk. It is intended as a bug release for 0.31.2 only, there are no new features. * Closing of files opened by \externalocp. * Fix for a locale-related bug that make PDF generation fail with a "Parsing CFF Dict failed" message when including opentype fonts. * The included metapost is now version 1.102. * PDF rules in vertical modes in RL direction where output in the wrong direction * Fix for a crash on Apple fonts that contain a 'bsln' table. * The handling of the second argument to fontforge.open() was broken * The included libpng is now 1.2.34 * Handling of ttc files on Windows was broken The archives (just binaries this time, hopefully there will be a source package later) can be downloaded from supelec as usual: http://foundry.supelec.fr/projects/luatex/ If you need the sources, please check out via anonymous svn: svn co svn://scm.foundry.supelec.fr/svn/luatex/tags/beta-0.31.3 Bugs and feature requests can be added to the issue tracker at http://tracker.luatex.org Have fun, Taco
Hi Taco,
I downloaded the code and compiled it on my Leopard 10.5.5 with gcc
4.0.1 from Xcode,
and I got a lot of, almost every one of, objects that have no symbols:
=================================================================
ranlib: file: ../.libs/libfontforge.a(autotrace.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(bezctx_ff.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(http.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(plugins.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(print.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(utils.o) has no symbols
ranlib ../.libs/libfontforge.a
ranlib: file: ../.libs/libfontforge.a(autotrace.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(bezctx_ff.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(http.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(plugins.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(print.o) has no symbols
ranlib: file: ../.libs/libfontforge.a(utils.o) has no symbols
creating ../libfontforge.la
(cd ../.libs && rm -f libfontforge.la && ln -s ../libfontforge.la
libfontforge.la)
sh -c "ar cru libff.a fontforge/fontforge/*.o fontforge/gutils/*.o
fontforge/Unicode/*.o ffdummies.o luafflib.o"
ranlib: file: libff.a(autotrace.o) has no symbols
ranlib: file: libff.a(bezctx_ff.o) has no symbols
ranlib: file: libff.a(http.o) has no symbols
ranlib: file: libff.a(plugins.o) has no symbols
ranlib: file: libff.a(print.o) has no symbols
ranlib: file: libff.a(utils.o) has no symbols
ranlib: file: libff.a(gimagereadgif.o) has no symbols
ranlib: file: libff.a(gimagereadjpeg.o) has no symbols
ranlib: file: libff.a(gimagereadpng.o) has no symbols
ranlib: file: libff.a(gimagereadtiff.o) has no symbols
ranlib: file: libff.a(gimagewritejpeg.o) has no symbols
ranlib: file: libff.a(gimagewritepng.o) has no symbols
ranlib: file: libff.a(gio.o) has no symbols
ranlib: file: libff.a(giofile.o) has no symbols
ranlib: file: libff.a(gioftp.o) has no symbols
ranlib: file: libff.a(giohosts.o) has no symbols
ranlib: file: libff.a(giothread.o) has no symbols
ranlib: file: libff.a(giotrans.o) has no symbols
ranlib libff.a
ranlib: file: libff.a(autotrace.o) has no symbols
ranlib: file: libff.a(bezctx_ff.o) has no symbols
ranlib: file: libff.a(http.o) has no symbols
ranlib: file: libff.a(plugins.o) has no symbols
ranlib: file: libff.a(print.o) has no symbols
ranlib: file: libff.a(utils.o) has no symbols
ranlib: file: libff.a(gimagereadgif.o) has no symbols
ranlib: file: libff.a(gimagereadjpeg.o) has no symbols
ranlib: file: libff.a(gimagereadpng.o) has no symbols
ranlib: file: libff.a(gimagereadtiff.o) has no symbols
ranlib: file: libff.a(gimagewritejpeg.o) has no symbols
ranlib: file: libff.a(gimagewritepng.o) has no symbols
ranlib: file: libff.a(gio.o) has no symbols
ranlib: file: libff.a(giofile.o) has no symbols
ranlib: file: libff.a(gioftp.o) has no symbols
ranlib: file: libff.a(giohosts.o) has no symbols
ranlib: file: libff.a(giothread.o) has no symbols
ranlib: file: libff.a(giotrans.o) has no symbols
=================================================================
I am a little scared. Would there be any potential risks or something?
On Tue, Dec 30, 2008 at 12:42 AM, Taco Hoekwater
Hi,
I have just uploaded luatex 0.31.3. This release has a bunch of updates from the development trunk. It is intended as a bug release for 0.31.2 only, there are no new features.
* Closing of files opened by \externalocp.
* Fix for a locale-related bug that make PDF generation fail with a "Parsing CFF Dict failed" message when including opentype fonts.
* The included metapost is now version 1.102.
* PDF rules in vertical modes in RL direction where output in the wrong direction
* Fix for a crash on Apple fonts that contain a 'bsln' table.
* The handling of the second argument to fontforge.open() was broken
* The included libpng is now 1.2.34
* Handling of ttc files on Windows was broken
The archives (just binaries this time, hopefully there will be a source package later) can be downloaded from supelec as usual:
http://foundry.supelec.fr/projects/luatex/
If you need the sources, please check out via anonymous svn:
svn co svn://scm.foundry.supelec.fr/svn/luatex/tags/beta-0.31.3
Bugs and feature requests can be added to the issue tracker at
Have fun, Taco
_______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
-- Best Regards Chen ---------------------------------------------------------------- Zhi-chu Chen | Shanghai Synchrotron Radiation Facility No. 2019 | Jialuo Rd. | Jiading | Shanghai | P.R. China tel: 086 21 5955 3405 | zhichu.chen.googlepages.com | www.sinap.ac.cn ----------------------------------------------------------------
Zhichu Chen wrote:
Hi Taco,
I downloaded the code and compiled it on my Leopard 10.5.5 with gcc 4.0.1 from Xcode, and I got a lot of, almost every one of,
Not even close to all of them, don't worry :) It is a small error on my side (every object file should define at least one symbol according to the C specification). I'll fix this for the next release, but it is a completely harmless warning message/error. Nothing is wrong with your executable. Best wishes, Taco
participants (8)
-
Hans Hagen -
Khaled Hosny -
Mojca Miklavec -
Oliver Buerschaper -
Taco Hoekwater -
Vladimir Volovich -
Yue Wang -
Zhichu Chen