You can subscribe to this list here.
2007 |
Jan
(24) |
Feb
(85) |
Mar
(32) |
Apr
(1) |
May
(7) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(3) |
Feb
(15) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(20) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
(1) |
Jun
(4) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alan W. I. <ir...@be...> - 2011-10-01 04:36:58
|
For what it is worth.... Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ---------- Forwarded message ---------- Date: Fri, 30 Sep 2011 04:05:02 -0400 (EDT) From: Softpedia Editorial Team <sof...@so...> To: ai...@us... Subject: libLASi included in the Softpedia software database Congratulations, libLASi, one of your products, has been added to Softpedia's database of software programs for the Windows operating system. It is featured with a description text, screenshots, download links and technical details on this page: http://www.softpedia.com/get/Programming/Components-Libraries/libLASi.shtml The description text was created by our editors, using sources such as text from your product's homepage, information from its help system, the PAD file (if available) and the editor's own opinions on the program itself. Your developer page on Softpedia can be reached at the URL below. It contains the list of software products and a link to your website. http://www.softpedia.com/developer/Alan-W-Irwin-Edward-H-Trager-81280.html If you feel that having your product listed on Softpedia is not a benefit for you or simply need something changed or updated, please contact us via email at web...@so... and we will work with you to fix any problem you may have found with the product's listing. -- Sincerely, The Softpedia Team ----------------------------------------------------------------------- Softpedia is a library of over 400,000 free and free-to-try software programs for Windows, Mac OS and Linux, games and gaming tools, Windows device drivers, mobile devices and IT-related articles. ----------------------------------------------------------------------- Softpedia - the encyclopedia of free software downloads http://www.softpedia.com/ |
From: Alan W. I. <ir...@be...> - 2011-09-21 21:57:37
|
See https://sourceforge.net/news/?group_id=187113&id=303547 for the release announcement. Ed, will you update http://www.unifont.org/lasi/ appropriately? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2011-09-20 07:10:37
|
On 2011-09-20 07:49+0200 Werner Smekal wrote: > Hi Allan, > > I got the latest svn and made a quick Mac OS X check. Attached is the output > of the cmake and make command, as well as output of the examples. It compiled > without problems, but didn't find some fonts I think. My cairo/pango stack is > a little mess I think, it seems cmake takes pango/cairo from different > sources (X11, homebrew), but it seems to work. Windows is a little bit more > complicated I try to test today. > Hi Werner: Thanks very much for that Mac OS X check. If you compare your example 2 results with examples/Example_2_Result.png (produced years ago by Ed Trager as the definitive check concerning how that example should look), the first two words of the long horizontal brown text (whatever that script is) are rendered incorrectly on your Mac OS X platform. I ascribe that to some problem for the pango/cairo version you use on Mac OS X which does not occur here for either the Linux or Wine platforms. In any case, this rendering issue (and the obvious missing font issue for your example 1 result) does not have anything to do with libLASi so I think we can count your report as a good libLASi-1.1.1 test result for Mac OS X. Thanks, again, for your report. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2011-09-20 03:17:49
|
Hi Werner (again): I now plan to release 1.1.1 tomorrow (Tuesday) because I confirmed today libLASi produces good build-tree and install-tree tests on both Linux and Wine. Furthermore, the Linux valgrind results showed no memory management issues other than some leftover memory allocations (which I presume are issues with pango/cairo since we also get extremely similar valgrind results for PLplot using -dev pscairo). However, if you or anyone still lurking on this lasi-devel list could do a quick test of libLASi svn for Microsoft Windows and/or Mac OS X while I am asleep tonight, that would be a useful and much appreciated complement to my current good testing results on Linux and MinGW/MSYS/Wine. I got the Wine platform to work perfectly by following up a general suggestion to modify fonts.conf that was made on the fontconfig mailing list. The change to $gtkplus_prefix/gtkplus-2.22.1/etc/fonts/fonts.conf that finally worked for me was as follows: --- fonts.conf.original 2010-02-05 12:55:42.000000000 -0800 +++ fonts.conf 2011-09-19 15:58:14.000000000 -0700 @@ -23,8 +23,8 @@ <!-- Font directory list --> + <dir>z:/usr/share/fonts</dir> <dir>WINDOWSFONTDIR</dir> - <dir>~/.fonts</dir> <!-- where $gtkplus_prefix is the directory where I unpacked the zip installation file for the all-in-one zip package. The drive-letter form z:/usr/share/fonts is essential in the above file. (MSYS-bash also honors the /z/usr/share/fonts name form for that directory, _but fontconfig does not_.) After that change I ran "fc-cache" under Wine with no options, and that allowed fonts to be found by subsequent "fc-list" commands and by the three examples that currently test libLASi under Wine. The resulting PostScript files look pretty good, although there are some serif-to-sans changes compared to the same files produced on Linux which I assume have to do with how the Windows version of GTK+ sets up fontconfig (since the same set of font files are used on both systems). Anyhow, that Wine result is good enough, and I am happy to take it! If/when you do a Microsoft Windows test, you may also have to edit font.conf like above and run fc-cache afterward so that fonts that happen to be in non-standard locations for the platform can still be found by fontconfig. Or none of that may be necessary if you have a good set of Windows fonts in the standard location for Windows. Here is a summary of my test procedure on Wine. Do the above change to fonts.conf, put $gtkplus_prefix/bin on the PATH, and run "fc-cache". (fc-cache only needs to be run once per fonts.conf change). Run "cmake -DCMAKE_INSTALL_PREFIX=$lasi_install_prefix ..." and "make" in the build_dir, where $lasi_install_prefix is some convenient installation prefix for libLASi. Put the absolute pathname of build_dir/dll on your PATH, and run ctest. That completes the build-tree test. To complete the install-tree test, run "make install", and replace the absolute pathname of build_dir/dll on the PATH with $lasi_install_prefix/bin. Change directory (cd) to $install_prefix/share/lasi1.1.1/examples and run "make >& make.out". The install-tree test gives identical example[0-2].ps files as the build-tree ctest results for Wine. Therefore, I plan to release 1.1.1 tomorrow (Tuesday). It may take me quite a bit of the day because the cookbook in the README.Release_Manager_Cookbook file for libLASi-1.1.1 needs a lot of updating. On the other hand, it might be early tomorrow (my time) because I just went through a release for ephcom-2.0.2 so I am pretty familiar with what has to be done now at SourceForge for releases. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2011-09-19 19:50:37
|
Hi Werner: libLASi is quite a success story at SourceForge with substantial numbers of downloads so it has always been on my agenda to continue to maintain it. Some time ago I was just about ready to release libLASi-1.1.1, but the absence of all Windows testing for that release concerned me so I "temporarily" put it off, and then forgot about the whole thing! Andrew has recently reminded me that the libLASi-1.1.1 release never happened. So today I have been trying to test the svn version of libLASi on Wine, but it fails on that platform with fonts issues. Therefore, until we can get at mininum some good results on Wine and/or Microsoft Windows platforms, the libLASi-1.1.1 release continues to be on hold. I was actually able to build libLASi OK under Wine, but the problem is the various examples generate an internal Wine error because no TrueType fonts are accessible with fonconfig supplied by the all-in-one GTK+ 2.22.1 download recommended at http://www.gtk.org/download/win32.php. It appears to me from the man page that fc-cache (an application which I can run from Wine) should inform fontconfig of the non-standard font location. Therefore, under Wine I ran fc-cache --really-force --verbose /z/usr/share/fonts where that directory is the Wine equivalent of /usr/share/fonts where I have large numbers of TrueType fonts located on my system. The results from that command seemed quite promising. There was lots of output about fonts being found in that tree and many font cache files were written to C:/users/wine/Temp/fontconfig/cache. BUT a subsequent fc-list command shows no fonts are accessible, and the libLASi examples (which indirectly use fontconfig) still error out because of lack of fonts. So my next stops are the wine and fontconfig mailing lists to see what the issue is, but meanwhile, do you have any trouble with running fc-list from Windows for GTK+ 2.22.1? Furthermore, do you have any trouble with the "ctest" step (with dll on your PATH) for the cmake make ctest commands for the svn version of libLASi from your Windows platform? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-05-14 02:51:04
|
On 2010-05-13 22:09-0400 Ed Trager wrote: > Hi, Alan and everyone, > >> >> I suspect the only way we can increase our immunity to internal pango/cairo >> changes is to move from the low-level way we currently access pango/cairo to >> the recommended high-level method of interfacing with pango/cairo. >> >> Ed has promised to ask Larry Siden (the original developer for libLASi) >> about that possibility, but he hasn't got back to me yet with Larry's reply. >> > > OK, I talked with Larry and he said he is willing to take a look and > investigate how Pango's high-level interface compares to what is going > on in LASi. He has some projects on his plate currently, but still > has some free hours at the moment which he can use to look at LASi. > He did indicate that if certain contract projects come through, then > things could change, but for the moment he's got some time and will be > happy to take a look. Sounds good. Thanks, Ed, for talking with him. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Ed T. <ed....@gm...> - 2010-05-14 02:09:40
|
Hi, Alan and everyone, > > I suspect the only way we can increase our immunity to internal pango/cairo > changes is to move from the low-level way we currently access pango/cairo to > the recommended high-level method of interfacing with pango/cairo. > > Ed has promised to ask Larry Siden (the original developer for libLASi) > about that possibility, but he hasn't got back to me yet with Larry's reply. > OK, I talked with Larry and he said he is willing to take a look and investigate how Pango's high-level interface compares to what is going on in LASi. He has some projects on his plate currently, but still has some free hours at the moment which he can use to look at LASi. He did indicate that if certain contract projects come through, then things could change, but for the moment he's got some time and will be happy to take a look. Best - Ed > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > > _______________________________________________ > Lasi-devel mailing list > Las...@li... > https://lists.sourceforge.net/lists/listinfo/lasi-devel > |
From: Andrew R. <and...@us...> - 2010-05-13 22:42:23
|
On Thu, May 06, 2010 at 04:47:38PM -0700, Alan Irwin wrote: > On 2010-05-04 14:03-0600 Orion Poplawski wrote: > > > [libLASi] Compiles and ctest runs fine on Fedora 13 w/ cmake 2.8.0 and pango 1.28.0. > > Thanks, Orion. Since then there has been one more important change (see next > post) which I hope is the last one before release. So it would probably > be worthwhile to test once again. Compiles fine and passes the tests here on a (recently released) Ubuntu Lucid system. I've also updated the debian files ready for the release. I did notice a couple of doxygen warnings when building the documentation. Andrew |
From: Alan W. I. <ir...@be...> - 2010-05-13 22:02:19
|
On 2010-05-13 22:03+0200 Werner Smekal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Alan, > >> Hi Werner: >> >> Thanks very much for running that test. >> >> If you do exactly the same thing with lasi-1.1.0 do you get the same >> segfault with your current pango/cairo stack? > > I downloaded the 1.1.0 sources and the same problem occurs, so very > likely this is the problem of the pango stack I'm using. At least it is > not due to the recent changes. Thanks, Werner, for that test. Since your test has proved this is not a regression, I won't stop the release because of this issue, but I doubt the issue is due to some pango/cairo development error. Instead, one likely possibility to explain your results is that there has been a deliberate recent change to the low-level pango/cairo stack that libLASi is no longer compatible with. Your stack corresponds to GTK+2.18.5 which was released in 2009-12 while it looks like mine (pango-1.20.5-5+lenny1 and cairo-1.6.4-7) corresponds to gtk+2.12.12 which was released in 2008-09. So other testers here should also look for this segfault to see if it correlates with a recent version of gtk+. I suspect the only way we can increase our immunity to internal pango/cairo changes is to move from the low-level way we currently access pango/cairo to the recommended high-level method of interfacing with pango/cairo. Ed has promised to ask Larry Siden (the original developer for libLASi) about that possibility, but he hasn't got back to me yet with Larry's reply. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2010-05-13 20:03:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alan, > Hi Werner: > > Thanks very much for running that test. > > If you do exactly the same thing with lasi-1.1.0 do you get the same > segfault with your current pango/cairo stack? I downloaded the 1.1.0 sources and the same problem occurs, so very likely this is the problem of the pango stack I'm using. At least it is not due to the recent changes. Regards, Werner > > What I am concerned with is whether this is a regression due to our recent > changes or something that was present in lasi-1.1.0 as well. > > If it is a regression can you bisect it (manually or with svn-bisect) to > find which of our recent commits caused the issue? > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (GPG: EDCAF4A79) web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL7FsEAAoJEG1QQcXtyvSndgsH/15oMEhHEiBbG33HukFVewcg IvrJZBBxFgBHiWjD+o7mRtM45UNnw8k31ljMJJO/otM99/mnTh2ITvOhVpEjhDWX 5xgVFNIY250XaJCAZJv2GhnRg8Fhz7zYJrvw8LHs04Ael2u+AJj81jhS5vV6zRzk J7i5UIpY93V4U9X4aJF2WLvaCzg1tBgjp4SNzRQezgd0ODFR+fm/IIXmO4mEExOM y/lov+oo3+oiD/AnwvFz07P5A1Daks3RkeMirhuw+Lwho8A57PUb6OhA1HlRnTIQ Us4lrmjRLRbrAt0nU4ked9DcSDqfTMVSKJdeUn9u14/cnZ8JwDbTbQdufsRkzic= =cqzr -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2010-05-13 16:51:53
|
On 2010-05-13 09:09-0600 Orion Poplawski wrote: > On 05/12/2010 07:11 PM, Alan W. Irwin wrote: >> Thus, I believe the problem is that cmake cannot find libpangoft2-1.0.so in >> what it considers to be a standard location (which probably does not >> include /usr/lib64). What happens if you set CMAKE_LIBRARY_PATH to >> /usr/lib64 ? > > That works. Good. I think that is the solution that should be used, then. To answer your prior question about release timing, it is still open-ended depending on whether the issue Werner found is a regression (which we will need time to fix) or an on-going problem (which we will probably put off fixing until after the release if indeed it turns out to be a libLASi problem as opposed to a problem in the specific pango/cairo stack that Werner was using). Also, I have been distracted by other things so I haven't yet had a chance to test MinGW/MSYS/Wine and MinGW/Wine platforms. So I am hoping for a release on the weekend of May 22, but we will see. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Orion P. <or...@co...> - 2010-05-13 15:10:03
|
On 05/12/2010 07:11 PM, Alan W. Irwin wrote: > Thus, I believe the problem is that cmake cannot find libpangoft2-1.0.so in > what it considers to be a standard location (which probably does not > include /usr/lib64). What happens if you set CMAKE_LIBRARY_PATH to > /usr/lib64 ? That works. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2010-05-13 01:11:11
|
On 2010-05-12 12:20-0600 Orion Poplawski wrote: > Scratch that. On 64-bit fedora (Fedora 12 w/ cmake 2.6.4 and rawhide with > cmake 2.8.1) I get: > > -- Looking for pkg-config - found > -- checking for modules 'pangoft2;pango;freetype2' > -- found pangoft2, version 1.28.0 > -- found pango, version 1.28.0 > -- found freetype2, version 10.0.4 > Cannot find library corresponding to linker option -lpangoft2-1.0 > original link flags delivered by pkg-config = > -pthread;-lpangoft2-1.0;-lfontconfig;-lpango-1.0;-lgobject-2.0;-lgmodule-2.0;-lgthread-2.0;-lrt;-lglib-2.0;-lfreetype > CMake Error at cmake/modules/pkg-config.cmake:184 (message): > FATAL ERROR in cmake_link_flags macro > Call Stack (most recent call first): > cmake/modules/pkg-config.cmake:34 (cmake_link_flags) > cmake/modules/lasi.cmake:53 (pkg_check_pkgconfig) > CMakeLists.txt:26 (include) > $ ls -l /usr/lib64/libpangoft2-1.0.so* > lrwxrwxrwx. 1 root root 27 May 12 11:30 /usr/lib64/libpangoft2-1.0.so -> > libpangoft2-1.0.so.0.2800.0 > lrwxrwxrwx. 1 root root 27 May 12 11:30 /usr/lib64/libpangoft2-1.0.so.0 > -> libpangoft2-1.0.so.0.2800.0 > -rwxr-xr-x. 1 root root 173240 Mar 30 16:31 > /usr/lib64/libpangoft2-1.0.so.0.2800.0 > > Aren't there better pkg-config macros built into cmake these days? I have now looked further at this, and also run some test cases, and it appears the macro for doing this search for libraries is working fine here for the exact original link flags you have there. The result here is -pthread;/usr/lib/libpangoft2-1.0.so;/usr/lib/libfontconfig.so;/usr/lib/libpango-1.0.so;/usr/lib/libgobject-2.0.so;/usr/lib/libgmodule-2.0.so;/usr/lib/libgthread-2.0.so;/usr/lib/librt.so;/usr/lib/libglib-2.0.so;/usr/lib/libfreetype.so IOW, all those -l options in the original link flags delivered by pkg-config on your system are turned into explicit full pathnames to libraries on my system because I happen to have the same library versions installed here. The leading -pthread in the list is unaffected by all of this. Thus, I believe the problem is that cmake cannot find libpangoft2-1.0.so in what it considers to be a standard location (which probably does not include /usr/lib64). What happens if you set CMAKE_LIBRARY_PATH to /usr/lib64 ? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-05-12 21:57:16
|
On 2010-05-12 22:38+0200 Werner Smekal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I just got the latest lasi version from svn and compiled the source on > Mac OS X 10.5.8 using the gtk stack as explained here > > http://www.miscdebris.net/blog/2010/02/19/gtk-framework-for-mac-os-x-as-well-as-cairo-pango/ > > The cmake configuration stage and the compilation works without > problems, running the examples scripts 0 and 1 works, but example2 > segfaults. The backtrace in gdb is: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0269404e > 0x00045fbb in hb_ot_layout_script_find_language () > (gdb) bt > #0 0x00045fbb in hb_ot_layout_script_find_language () > #1 0x000419e9 in pango_ot_info_find_language () > #2 0x00042848 in pango_ot_ruleset_new_for () > #3 0x00042906 in pango_ot_ruleset_new_from_description () > #4 0x00042a88 in pango_ot_ruleset_get_for_description () > #5 0x003fce09 in basic_engine_shape () > #6 0x000ca038 in pango_shape () > #7 0x0001b5e6 in LASi::PostscriptDocument::for_each_glyph_do () > #8 0x0001ba76 in LASi::show::apply () > #9 0x000082de in LASi::operator<< () > #10 0x000077bf in main () > > Seems to be a pango problem, so it could be the gtk stack I was using. Hi Werner: Thanks very much for running that test. If you do exactly the same thing with lasi-1.1.0 do you get the same segfault with your current pango/cairo stack? What I am concerned with is whether this is a regression due to our recent changes or something that was present in lasi-1.1.0 as well. If it is a regression can you bisect it (manually or with svn-bisect) to find which of our recent commits caused the issue? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2010-05-12 20:38:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just got the latest lasi version from svn and compiled the source on Mac OS X 10.5.8 using the gtk stack as explained here http://www.miscdebris.net/blog/2010/02/19/gtk-framework-for-mac-os-x-as-well-as-cairo-pango/ The cmake configuration stage and the compilation works without problems, running the examples scripts 0 and 1 works, but example2 segfaults. The backtrace in gdb is: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0269404e 0x00045fbb in hb_ot_layout_script_find_language () (gdb) bt #0 0x00045fbb in hb_ot_layout_script_find_language () #1 0x000419e9 in pango_ot_info_find_language () #2 0x00042848 in pango_ot_ruleset_new_for () #3 0x00042906 in pango_ot_ruleset_new_from_description () #4 0x00042a88 in pango_ot_ruleset_get_for_description () #5 0x003fce09 in basic_engine_shape () #6 0x000ca038 in pango_shape () #7 0x0001b5e6 in LASi::PostscriptDocument::for_each_glyph_do () #8 0x0001ba76 in LASi::show::apply () #9 0x000082de in LASi::operator<< () #10 0x000077bf in main () Seems to be a pango problem, so it could be the gtk stack I was using. Regards, Werner On 5/7/10 7:25 AM, Alan W. Irwin wrote: > On 2010-05-03 17:19-0700 Alan W. Irwin wrote: > >> One remaining issue for this forthcoming release is the alignment of >> diacritic marks. That issue was discussed by an e-mail to this list two >> years ago (one of the latest posts to this list before it became quiet). The >> subject line was "LASi: bug&fix diacritic marks alignment". I am now trying >> to regain contact with that guy since the genesis.txt file he attached was >> clobbered by the mail chain so his result cannot be replicated. However, >> his patch attachment "lasi-20080223.patch" came through fine to the list and >> appears to say if geometrical offsets are specified for the glyph, then >> libLASi should use them. Could some of you here with libpango/libcairo >> experience review that patch? I will apply that patch for the release >> (probably with applyOffset dropped so we always do the check) if you think >> this is the correct thing to do. > > Ed has kindly reviewed, tested, and applied the patch from Yotam Medini to > fix diacritical mark alignment issues. The patch necessarily includes an > extra bool applyOffset argument for PostscriptDocument::for_each_glyph_do so > that libLasi can do the right thing internally (it calls that method with > applyOffset set to both true and false as appropriate to get the right > offsets for diacritical marks). > > I have tested this solution using the new > examples/python/test_hebrew_diacritic.py special test (PLplot revision > 10976) which displays Genesis Chapter 1 verse 3 in Hebrew. Yotam has given > us an example of this verse with proper alignment of the diacritical marks, > and this special python example agrees with that good alignment example for > -dev psttfc (now that libLASi has been updated with Yotam's patch), -dev > epsqt, -dev pscairo, and -dev xcairo. Also, this same verse at > http://www.mechon-mamre.org/p/pt/pt0101.htm is displayed with the same > diacritical alignment for konqueror (version 4:4.3.2-1~bpo+1) and iceweasel > (the Debian version of firefox version 2.0.0.14-2). Because of this > complete diacritical mark alignment consistency for Qt4-based konqueror and > -dev epsqt (and all the rest of the devices) it was something of a surprise > that the Qt4-based -dev qtwidget continues to have (small) diacritic mark > alignment issues, but that is a different story that has nothing to do with > libLASi. > > Although the PLplot psttfc device does not use the > PostscriptDocument::for_each_glyph_do method externally, it is externally > accessible for users. Thus, as Ed and Andrew have confirmed the added > argument to this method that is a necessary part of the Yotam Medini patch > that has been applied is a backwards-incompatible API change that we cannot > avoid. I have bumped the library soversion appropriately from 0 to 1 to be > consistent with this change, and I have also remarked on this API change in > the release notes. I hope we are now (revision 159) at the last change > before the release, but lots more testing is needed at this point to prove > that! :-) > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > > _______________________________________________ > Lasi-devel mailing list > Las...@li... > https://lists.sourceforge.net/lists/listinfo/lasi-devel - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (GPG: EDCAF4A79) web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL6xG6AAoJEG1QQcXtyvSn6XgH/0WbM8Xh19mJ9SBc1uGX6sTb FREGTGQ9RYNl7nxWYHMUQsDkRWc9MYpbNssWFlIw0GXELxJAmqGjOrN+jd626nHq gPj+OT60iZVv3v+4GjCuXQ8XX7JuCq1SR3Bnl2OOyFq5yfVnNRBLCNB2I8+bouZV 97L0fgUIxC1zwbjLVDX0sCJF5U0X7D3kPlWlj+kKaH2CKNTIgYu7Xi6tVr/2cwcf x71ByvKYoArnWG4LxKOVzKi4IxOYujauT/dQ5LWZG7EvAlweIqY2KNisZdbvks3g a20a0cNbwqs4pTKrSAGFA46qKMPq0HMRTz/2X3i93aUd9GcIeOXK8uZr59D/zUQ= =sX0G -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2010-05-12 19:38:29
|
On 2010-05-12 12:20-0600 Orion Poplawski wrote: > On 05/12/2010 11:24 AM, Orion Poplawski wrote: >> On 05/06/2010 11:25 PM, Alan W. Irwin wrote: >>> >>> Although the PLplot psttfc device does not use the >>> PostscriptDocument::for_each_glyph_do method externally, it is externally >>> accessible for users. Thus, as Ed and Andrew have confirmed the added >>> argument to this method that is a necessary part of the Yotam Medini patch >>> that has been applied is a backwards-incompatible API change that we >>> cannot >>> avoid. I have bumped the library soversion appropriately from 0 to 1 to be >>> consistent with this change, and I have also remarked on this API change >>> in >>> the release notes. I hope we are now (revision 159) at the last change >>> before the release, but lots more testing is needed at this point to prove >>> that! :-) >> >> Compiles and runs fine on Fedora 13 and Fedora rawhide. Any idea on when >> 1.1.1 will be released? >> > > Scratch that. On 64-bit fedora (Fedora 12 w/ cmake 2.6.4 and rawhide with > cmake 2.8.1) I get: > > -- Looking for pkg-config - found > -- checking for modules 'pangoft2;pango;freetype2' > -- found pangoft2, version 1.28.0 > -- found pango, version 1.28.0 > -- found freetype2, version 10.0.4 > Cannot find library corresponding to linker option -lpangoft2-1.0 > original link flags delivered by pkg-config = > -pthread;-lpangoft2-1.0;-lfontconfig;-lpango-1.0;-lgobject-2.0;-lgmodule-2.0;-lgthread-2.0;-lrt;-lglib-2.0;-lfreetype > CMake Error at cmake/modules/pkg-config.cmake:184 (message): > FATAL ERROR in cmake_link_flags macro > Call Stack (most recent call first): > cmake/modules/pkg-config.cmake:34 (cmake_link_flags) > cmake/modules/lasi.cmake:53 (pkg_check_pkgconfig) > CMakeLists.txt:26 (include) > > $ ls -l /usr/lib64/libpangoft2-1.0.so* > lrwxrwxrwx. 1 root root 27 May 12 11:30 /usr/lib64/libpangoft2-1.0.so -> > libpangoft2-1.0.so.0.2800.0 > lrwxrwxrwx. 1 root root 27 May 12 11:30 /usr/lib64/libpangoft2-1.0.so.0 > -> libpangoft2-1.0.so.0.2800.0 > -rwxr-xr-x. 1 root root 173240 Mar 30 16:31 > /usr/lib64/libpangoft2-1.0.so.0.2800.0 > > Aren't there better pkg-config macros built into cmake these days? Probably, but I stuck with the "tried and true" that we use with PLplot. Moving to the official cmake pkg-config macros will require some changes in other parts of our PLplot and libLASi build systems so I am going to hold off doing that until the start of the next release cycle (for both PLplot and libLASi) to give full testing. For now, you might get a similar error with, say, the cairo device driver on PLplot since similar libraries and pkg-config are involved there as well. Anyhow, thanks very much for your report which includes enough information in the error message that it should be straightforward to figure out what is going wrong and deal with it. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Orion P. <or...@co...> - 2010-05-12 18:21:07
|
On 05/12/2010 11:24 AM, Orion Poplawski wrote: > On 05/06/2010 11:25 PM, Alan W. Irwin wrote: >> >> Although the PLplot psttfc device does not use the >> PostscriptDocument::for_each_glyph_do method externally, it is externally >> accessible for users. Thus, as Ed and Andrew have confirmed the added >> argument to this method that is a necessary part of the Yotam Medini patch >> that has been applied is a backwards-incompatible API change that we cannot >> avoid. I have bumped the library soversion appropriately from 0 to 1 to be >> consistent with this change, and I have also remarked on this API change in >> the release notes. I hope we are now (revision 159) at the last change >> before the release, but lots more testing is needed at this point to prove >> that! :-) > > Compiles and runs fine on Fedora 13 and Fedora rawhide. Any idea on when > 1.1.1 will be released? > Scratch that. On 64-bit fedora (Fedora 12 w/ cmake 2.6.4 and rawhide with cmake 2.8.1) I get: -- Looking for pkg-config - found -- checking for modules 'pangoft2;pango;freetype2' -- found pangoft2, version 1.28.0 -- found pango, version 1.28.0 -- found freetype2, version 10.0.4 Cannot find library corresponding to linker option -lpangoft2-1.0 original link flags delivered by pkg-config = -pthread;-lpangoft2-1.0;-lfontconfig;-lpango-1.0;-lgobject-2.0;-lgmodule-2.0;-lgthread-2.0;-lrt;-lglib-2.0;-lfreetype CMake Error at cmake/modules/pkg-config.cmake:184 (message): FATAL ERROR in cmake_link_flags macro Call Stack (most recent call first): cmake/modules/pkg-config.cmake:34 (cmake_link_flags) cmake/modules/lasi.cmake:53 (pkg_check_pkgconfig) CMakeLists.txt:26 (include) $ ls -l /usr/lib64/libpangoft2-1.0.so* lrwxrwxrwx. 1 root root 27 May 12 11:30 /usr/lib64/libpangoft2-1.0.so -> libpangoft2-1.0.so.0.2800.0 lrwxrwxrwx. 1 root root 27 May 12 11:30 /usr/lib64/libpangoft2-1.0.so.0 -> libpangoft2-1.0.so.0.2800.0 -rwxr-xr-x. 1 root root 173240 Mar 30 16:31 /usr/lib64/libpangoft2-1.0.so.0.2800.0 Aren't there better pkg-config macros built into cmake these days? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Orion P. <or...@co...> - 2010-05-12 17:25:14
|
On 05/06/2010 11:25 PM, Alan W. Irwin wrote: > > Although the PLplot psttfc device does not use the > PostscriptDocument::for_each_glyph_do method externally, it is externally > accessible for users. Thus, as Ed and Andrew have confirmed the added > argument to this method that is a necessary part of the Yotam Medini patch > that has been applied is a backwards-incompatible API change that we cannot > avoid. I have bumped the library soversion appropriately from 0 to 1 to be > consistent with this change, and I have also remarked on this API change in > the release notes. I hope we are now (revision 159) at the last change > before the release, but lots more testing is needed at this point to prove > that! :-) Compiles and runs fine on Fedora 13 and Fedora rawhide. Any idea on when 1.1.1 will be released? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2010-05-07 05:25:36
|
On 2010-05-03 17:19-0700 Alan W. Irwin wrote: > One remaining issue for this forthcoming release is the alignment of > diacritic marks. That issue was discussed by an e-mail to this list two > years ago (one of the latest posts to this list before it became quiet). The > subject line was "LASi: bug&fix diacritic marks alignment". I am now trying > to regain contact with that guy since the genesis.txt file he attached was > clobbered by the mail chain so his result cannot be replicated. However, > his patch attachment "lasi-20080223.patch" came through fine to the list and > appears to say if geometrical offsets are specified for the glyph, then > libLASi should use them. Could some of you here with libpango/libcairo > experience review that patch? I will apply that patch for the release > (probably with applyOffset dropped so we always do the check) if you think > this is the correct thing to do. Ed has kindly reviewed, tested, and applied the patch from Yotam Medini to fix diacritical mark alignment issues. The patch necessarily includes an extra bool applyOffset argument for PostscriptDocument::for_each_glyph_do so that libLasi can do the right thing internally (it calls that method with applyOffset set to both true and false as appropriate to get the right offsets for diacritical marks). I have tested this solution using the new examples/python/test_hebrew_diacritic.py special test (PLplot revision 10976) which displays Genesis Chapter 1 verse 3 in Hebrew. Yotam has given us an example of this verse with proper alignment of the diacritical marks, and this special python example agrees with that good alignment example for -dev psttfc (now that libLASi has been updated with Yotam's patch), -dev epsqt, -dev pscairo, and -dev xcairo. Also, this same verse at http://www.mechon-mamre.org/p/pt/pt0101.htm is displayed with the same diacritical alignment for konqueror (version 4:4.3.2-1~bpo+1) and iceweasel (the Debian version of firefox version 2.0.0.14-2). Because of this complete diacritical mark alignment consistency for Qt4-based konqueror and -dev epsqt (and all the rest of the devices) it was something of a surprise that the Qt4-based -dev qtwidget continues to have (small) diacritic mark alignment issues, but that is a different story that has nothing to do with libLASi. Although the PLplot psttfc device does not use the PostscriptDocument::for_each_glyph_do method externally, it is externally accessible for users. Thus, as Ed and Andrew have confirmed the added argument to this method that is a necessary part of the Yotam Medini patch that has been applied is a backwards-incompatible API change that we cannot avoid. I have bumped the library soversion appropriately from 0 to 1 to be consistent with this change, and I have also remarked on this API change in the release notes. I hope we are now (revision 159) at the last change before the release, but lots more testing is needed at this point to prove that! :-) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-05-06 23:47:45
|
On 2010-05-04 14:03-0600 Orion Poplawski wrote: > [libLASi] Compiles and ctest runs fine on Fedora 13 w/ cmake 2.8.0 and pango 1.28.0. Thanks, Orion. Since then there has been one more important change (see next post) which I hope is the last one before release. So it would probably be worthwhile to test once again. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Orion P. <or...@co...> - 2010-05-04 20:03:23
|
On 05/03/2010 06:19 PM, Alan W. Irwin wrote: > Testing simply involves running "make" and "ctest" in the build tree and > (after "make install" in the build tree) running "make" in the installed > examples tree ($prefix/share/lasi1.1.1/examples) and making sure there are > no errors, the example[0-2].ps results look okay, etc. When I do that here > for Debian Lenny all is well. I plan further testing of the build for > MinGW/MSYS under Wine, but I hope others here will do their own testing as > well on as many platforms as possible. The PLplot developers on this list > know we are also going through the late stages of a release cycle there with > similar testing required. Fortunately, you can easily test both libLASi and > PLplot at once. :-) Compiles and ctest runs fine on Fedora 13 w/ cmake 2.8.0 and pango 1.28.0. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2010-05-04 16:05:37
|
Yotam Medini was kind enough to send his previous attachments again, and I forward that e-mail below. This time genesis.txt has come through unscathed, and I completely verify the bad diacritical alignment as follows with the svn trunk version of libLASi and version 1.20.5-5+lenny1 of libpango: g++ `env PKG_CONFIG_PATH=/home/software/lasi_svn/install/lib/pkgconfig pkg-config --libs --cflags lasi` mylasi.cc -o mylasi ./mylasi genesis-latest.ps genesis.txt DejaVuSans 20 The resulting alignment in genesis-latest.ps is visually identical with the bad alignment of genesis-old.ps, and quite different from the good alignment in genesis-new.ps. Also, if you take any random text from http://www.mechon-mamre.org/p/pt/pt0101.htm and cut and paste to a text file that you feed through mylasi as above, you can see disagreements between how libLASi aligns the diacritical remarks and how konqueror does it. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ---------- Forwarded message ---------- Date: Tue, 4 May 2010 10:03:32 +0300 From: Yotam Medini יותם מדיני <yot...@gm...> To: Alan W. Irwin <ir...@be...> Subject: Fwd: LASi: bug&fix diacritic marks alignment Hello Alan, Forwarding again this two-years old message with attachments. By now, I do not remember all the details. But since then I know that Lilypond fixed its handling of diacritics, using a higher level API. This old problem of Lilypond was the reason I dived into this issue. But in any case, I believe my suggestions for enhancing the 'paps' program are still good. But my implementation should be changed as you see fit. regards -- yotam ---------- Forwarded message ---------- From: Yotam Medini יותם מדיני <yot...@gm...> Date: 2008/2/23 Subject: LASi: bug&fix diacritic marks alignment To: las...@li... Hello LASi developpers, While trying to debug diacritic marks alignment problem in the music-typesetting system 'Lilypond' (www.lilypond.org) - I looked for free code that does a similar thing and compare. The software packages I found were: paps (paps.sourceforge.net) and LASi. Running some example, showed that paps correctly aligns diacritic marks, but LASi suffers from similar problem as Lilypond. Attached are fix and an example. lasi-20080223.patch - patch for include/LASi.h src/psDoc.cpp mylasi.cc - Enhancement for the SimpleLASiExample.cpp example, adding more optional parameters: cerr << "Usage:\n" << argv[0] << " [ <outfn> [ <inpfn> [ <font> [ <size> ]]]]\n"; genesis.txt Some words from the Bible - with diacritic marks. genesis-old.ps Output of: ./mylasi genesis-old.ps genesis.txt DejaVuSans 20 before the patch. genesis-new.ps Result of: ./mylasi genesis-new.ps genesis.txt DejaVuSans 20 after the patch. genesis-oldnew.jpeg - screenshot of both The patch I have done is not in the 'generic programming' style of libLASi. But I needed to pass an extra flag, and I wanted to minimize the size of the change. regards -- yotam |
From: Ed T. <ed....@gm...> - 2010-05-04 15:37:39
|
Hi, Alan, I'm *very* skeptical about why a LASi patch would be needed for diacritic alignment? All of the glyph and diacritic placement work should be done by Pango's OpenType font engine. If there really are problems with diacritic alignment, one must first and foremost find out what font was used to generate the problematic text layout? And what version of Pango? Any new version of Pango with a high-quality extended-Latin font such as SIL's Gentium font should not exhibit diacritic alignment problems. And again, if there are problems with diacritic alignment, it really is not libLASi's problem to solve them -- the problem needs to be solved at the lower-level libraries. For example, HarfBuzz --which is what is really driving Pango these days-- is the right place to investigate and fix problems with diacritic alignment. Best - Ed > One remaining issue for this forthcoming release is the alignment of > diacritic marks. That issue was discussed by an e-mail to this list two > years ago (one of the latest posts to this list before it became quiet). The > subject line was "LASi: bug&fix diacritic marks alignment". I am now trying > to regain contact with that guy since the genesis.txt file he attached was > clobbered by the mail chain so his result cannot be replicated. However, > his patch attachment "lasi-20080223.patch" came through fine to the list and > appears to say if geometrical offsets are specified for the glyph, then > libLASi should use them. Could some of you here with libpango/libcairo > experience review that patch? I will apply that patch for the release > (probably with applyOffset dropped so we always do the check) if you think > this is the correct thing to do. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > _______________________________________________ > Lasi-devel mailing list > Las...@li... > https://lists.sourceforge.net/lists/listinfo/lasi-devel > |
From: Alan W. I. <ir...@be...> - 2010-05-04 07:02:46
|
Hi Ed: One question for you below. On 2010-05-03 17:19-0700 Alan W. Irwin wrote: > One remaining issue for this forthcoming release is the alignment of > diacritic marks. That issue was discussed by an e-mail to this list two > years ago (one of the latest posts to this list before it became quiet). The > subject line was "LASi: bug&fix diacritic marks alignment". I am now trying > to regain contact with that guy since the genesis.txt file he attached was > clobbered by the mail chain so his result cannot be replicated. However, > his patch attachment "lasi-20080223.patch" came through fine to the list and > appears to say if geometrical offsets are specified for the glyph, then > libLASi should use them. Could some of you here with libpango/libcairo > experience review that patch? I will apply that patch for the release > (probably with applyOffset dropped so we always do the check) if you think > this is the correct thing to do. I tried one test using Hebrew text from the book of Genesis, and it appears via comparisons with how konqueror rendered the text that we do have an alignment problem with diacritical marks. Lilypond had a similar issue, but note this quote from the thread at http://code.google.com/p/lilypond/issues/detail?id=541 by Dov Grobgeld who I understand is something of an expert on diacritical mark alignment and pango. <quote> Shalom Yotam, As you have seen the use of pango by itself does not guarantee that you will get the right rendering. The problem is caused by the fact that you can enter the pango rendering chain at different levels. paps uses the high level PangoLayout level. If lilypond was using that level it wouldn't have any problem. Nor would it need to any special processing for different languages and use their different backends. </quote> Ed, how difficult would it be for libLASi to change to the recommended high-level PangoLayout level? If I recall correctly this recommendation has come up before during discussions of libLASi on the pango list. Lilypond has since fixed this issue (which also fixed a similar issue with Khmer/Cambodian), but it wasn't clear whether they took the recommendation to move to high-level PangoLayout level or did something else. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-05-04 00:26:33
|
This list has been quiet for the ~two years since the release of lasi-1.1.0, but I discovered recently release had almost 1000 (!) downloads from SourceForge. I was quite surprised and gratified by that popularity. Andrew Ross's best guess for the reason is that libLASi has an API that is easy to work with. Whatever the cause of that popularity, it means we should continue to maintain this library rather than abandoning it. I am willing to do most of that maintenance work, but I do need some help from the rest of you as well on the platform testing front and also evaluating a patch (see below). Here is what I have done so far in my present flurry of svn commits. Modern cmake was generating some warning messages about the build system that I fixed with some fairly extensive changes to the build system. I have also fixed an inconsistent use of the const attribute for setFont arguments that was turned up by one of our sun users (see https://sourceforge.net/tracker/index.php?func=detail&aid=2797964&group_id=187113&atid=919995 for details). As of revision 156 I have also done many of the other things (versions etc.) to prepare for a new release. Therefore, platform testing of revision 156 is now essential to make certain (in light of the above extensive build-system changes) that this release will work well on all platforms. Testing simply involves running "make" and "ctest" in the build tree and (after "make install" in the build tree) running "make" in the installed examples tree ($prefix/share/lasi1.1.1/examples) and making sure there are no errors, the example[0-2].ps results look okay, etc. When I do that here for Debian Lenny all is well. I plan further testing of the build for MinGW/MSYS under Wine, but I hope others here will do their own testing as well on as many platforms as possible. The PLplot developers on this list know we are also going through the late stages of a release cycle there with similar testing required. Fortunately, you can easily test both libLASi and PLplot at once. :-) One remaining issue for this forthcoming release is the alignment of diacritic marks. That issue was discussed by an e-mail to this list two years ago (one of the latest posts to this list before it became quiet). The subject line was "LASi: bug&fix diacritic marks alignment". I am now trying to regain contact with that guy since the genesis.txt file he attached was clobbered by the mail chain so his result cannot be replicated. However, his patch attachment "lasi-20080223.patch" came through fine to the list and appears to say if geometrical offsets are specified for the glyph, then libLASi should use them. Could some of you here with libpango/libcairo experience review that patch? I will apply that patch for the release (probably with applyOffset dropped so we always do the check) if you think this is the correct thing to do. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |