ABOUT libLASi
=============

The libLASi website is located at http://www.unifont.org/lasi/ with the project
page located at http://sourceforge.net/projects/lasi.

libLASi is a library that provides a C++ stream output interface (with
operator<< ) to writing Postscript and Encapsulated Postscript documents
containing any of the world's scripts supported by Unicode 4.0 and the Pango
complex text layout engine.  You can use any TrueType or OpenType fonts that
you want. The library accomodates both left-to-right (e.g. most European
languages) as well as right-to-left (e.g. Hebrew, Arabic) scripts, as well
as Complex Text Layout (CTL) scripts such as Devanagari, Bengali, Thai, and
other Indic and Indic-derived scripts. You can include any number of
different scripts or languages in the same document without need for any
special configuration or layout calculation on the programmer's part.
libLASi accepts Unicode strings encoded in the UTF-8 transformation format
which is the de facto standard on Linux and other *nix systems.

Although Postscript printing capability exists in open-source toolkits such
as Gnome and QT, libLASi was designed for projects that are independent of
any one Graphic User Interface (GUI) toolkit or do not even make use of a
GUI interface but still require the ability to produce Postscript output
containing Unicode text.

For installation instructions, see http://www.unifont.org/lasi/

For example programs that uses libLASi, please see the examples
directory located in the install tree at
$prefix/share/lasi$version/examples where $prefix is the installation
prefix and $version is the version of lasi (1.1.3 at the time of
writing). An example is provided which tests that libLASi is robust
against some common font issues such as a missing glyph or pango
deciding to use a pure bitmapped font such as the popular Noto Color
Emoji that does not provide the outline font data that libLASi needs).
Simple and slightly more extensive examples are provided as well that
have more interesting output.  For more details concerning the examples,
please consult examples/README.

See the file COPYING for terms of copying and re-distribution.

Copyright (C) 2003, 2004, 2006 Larry Siden
Copyright (C) 2008 Ed Trager
Copyright (C) 2008 Ritu Khanna
Copyright (C) 2008-2019 Alan W. Irwin
Copyright (C) 2008 Andrew Ross
Copyright (C) 2008 Werner Smekal

    This library is free software; you can redistribute it and/or
    modify it under the terms of the GNU Library General Public
    License as published by the Free Software Foundation; either
    version 2 of the License, or (at your option) any later version.

    This library is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    Library General Public License for more details.

    You should have received a copy of the GNU Library General Public
    License along with this library; if not, write to the
    Free Software Foundation, Inc., 59 Temple Place - Suite 330,
    Boston, MA  02111-1307  USA.

Original Author:

	Larry Siden
	4047 Rolling Meadow Lane
	Pittsfield Twp., MI  48197-6619, USA

	http://umich.edu/~lsiden
	mailto:lsiden@gmail.com

Contributors:

	Edward H. Trager
	ehtrager@umich.edu
	http://eyegene.ophthy.med.umich.edu

	Ritu Khanna
	rituk@umich.edu

        Alan W. Irwin
        irwin@beluga.phys.uvic.ca

        Andrew Ross
        andrewross@users.sourceforge.net

        Werner Smekal
	smekal@iap.tuwien.ac.at

This is a cookbook showing the steps required to create a libLASi release at
SourceForge.

INDEX
(1)  Create and test a preliminary tarball from trunk
(2)  Finish release-related trunk changes so they will be in the release
(3)  Create and test the release tarball from trunk
(4)  Update ChangeLog and README.Release_Manager_Cookbook
(5)  Tag the release
(6)  Create and test the release tarball from the tagged version
(7)  Generate a file release at Sourceforge
(8)  Commit the tagged version
(9)  Publicity for the release announcement
(10) Post release tweaking of this file (README.Release_Manager_Cookbook)

(A1) GNU Privacy Guard (gpg).
(A2) Setting the correct date and time on your computer.
End of INDEX

(1)  Create and test a preliminary tarball from trunk

     Do everything in (3) below just to make sure that the trunk
     version is in good shape before you do the following final stages
     of the release process.

(2)  Finish release-related trunk changes so they will be in the release

*    set environment variable for version to make directions below
     more generic.

export LASI_VERSION=1.1.3
# Should refer to first release in this release cycle, i.e., one after
# last release for the last release.
export FIRST_RELEASE_REVISION=r200

*    Prepare a preliminary version of the ChangeLog file to see what
     has been accomplished since the last release.

# This makes the BASE used below correct.
svn update

svn log --revision ${FIRST_RELEASE_REVISION}:BASE --verbose  >| ChangeLog.release_preliminary

     Note the "_preliminary" suffix to distinguish this from the final
     result below which will contain (if all goes well in the steps
     below) a record of all but the last commit (of the ChangeLog
     itself) for this release.

     Note the order of the --revision components puts this preliminary
     version in chronological order.  But it is traditional for the
     final version to have the result in reverse chronological order
     (see below).

*    Update and commit README and cmake/module/lasi_version.cmake to
     reflect the current version. Also, follow the instructions in
     that latter file for updating the SOVERSION, the minor number and
     the patch number.

*    Update and commit the release notes (stored in the README.release
     file) containing a short overview of the most important changes
     noted in the ChangeLog.release_preliminary file since the last
     release.

*    Once completely satisfied with README.release insert it at the
     start of README.cumulated release to keep a historical record in
     reverse chronological order of the notes for all releases in that
     file.  From now on, any further tweaks to README.release should
     be mirrored in README.cumulated release which is why this
     insertion step should be delayed until the release manager is
     completely satisfied with README.release.

*    Check that all local changes (other than this file,
     README.Release_Manager_Cookbook, and ChangeLog) are in the
     repository so they will be reflected in the ChangeLog, tagged
     version of the release, and release tarball.

svn status

(3)  Create and test the release tarball from trunk

*    Do the usual cmake and make in the build tree to build the user
     and developer configurations of the Doxygen documentation in the
     source tree.  For example,

cd /home/software/lasi_svn/HEAD/build_dir
# In case this not set.
LASI_VERSION= 1.1.3
time (rm -rf /home/software/lasi_svn/HEAD/build_dir/* ~/lasi_svn/install; env PATH="/usr/bin:$PATH" cmake -DCMAKE_INSTALL_PREFIX=/home/software/lasi_svn/install -DBUILD_SHARED_LIBS=ON ../lasi_2019 >& cmake.out)
make -j16 all >& all.out

     Then build a preliminary version of the release tarball

make package_source

*    Check that generated tarball by checking its table of contents as follows:

tar ztvf libLASi-$LASI_VERSION.tar.gz |sed "s?  *? ?g" |cut --delimiter=" " --fields="6-" |less

*    Unpack that tarball:

tar zxf libLASi-$LASI_VERSION.tar.gz

*    Test that tarball with shared build, install, and shared examples build

mkdir tarball_build_dir
cd tarball_build_dir
build_tree_dir=$(pwd)
/usr/bin/cmake -DCMAKE_INSTALL_PREFIX=../tarball_install -DBUILD_SHARED_LIBS=ON ../libLASi-$LASI_VERSION >& cmake.out
make -j16 >& make.out
# Inspect EPS results.  Note a white background has to be imposed because
# these results have no background.  So by default the background would be a checkerboard
# imposed by pqiv if this --background-pattern option was not used.

# Inspect same results converted (with opaque white background added) to PNG format
# by inkscape.

for CORE_NAME in MissingGlyphExample SimpleLASiExample ComplexTextLayoutExample ; do
    pqiv -i --background-pattern=white examples/$CORE_NAME.eps
    pqiv -i examples/$CORE_NAME.png
done

# ldd and valgrind tests of the examples including comparisons of the
# results generated with the previous results.  Note, that 2>&1
# redirects stderr to *current" stdout (which defaults to pipe),
# test.eps afterwards means PostScript output goes directly to that
# file rather than stdout (so nothing more is emitted to stdout), and
# >| test.eps afterwards means PostScript output goes to stdout (but
# not stderr) and stdout then overwrites whatever was in test.eps
# before.

for CORE_NAME in MissingGlyphExample SimpleLASiExample ComplexTextLayoutExample ; do
    ldd -r examples/$CORE_NAME 2>&1 | less
    valgrind examples/$CORE_NAME 2>&1 test.eps | less
    cmp test.eps examples/$CORE_NAME.eps
    valgrind examples/$CORE_NAME 2>&1 >| test.eps | less
    cmp test.eps examples/$CORE_NAME.eps
done

# Run ctest
/usr/bin/ctest -j16 --output-log >| ctest.out
# Compare ctest results with above make results.
for CORE_NAME in MissingGlyphExample SimpleLASiExample ComplexTextLayoutExample ; do
    cmp examples/ctest_examples_output_dir/$CORE_NAME.eps examples/$CORE_NAME.eps
done

make -j16 install >& make_install.out
cd ../tarball_install/share/lasi$LASI_VERSION/examples
make -j16 >& make.out

for CORE_NAME in MissingGlyphExample SimpleLASiExample ComplexTextLayoutExample ; do
    ldd -r $CORE_NAME 2>&1 | less
    cmp $CORE_NAME.eps $build_tree_dir/examples/$CORE_NAME.eps
    valgrind ./$CORE_NAME 2>&1 test.eps | less
    cmp test.eps $CORE_NAME.eps
    valgrind ./$CORE_NAME 2>&1 >| test.eps | less
    cmp test.eps $CORE_NAME.eps
done

*    Test that tarball with static build, install, and static examples build

# Repeat all the prior test steps starting with removing prior test results with

cd $build_tree_dir/..
rm -rf tarball_*

# Then follow with all the above steps starting with

mkdir tarball_build_dir
[...]

# but with cmake option -DBUILD_SHARED_LIBS=ON replaced by -DBUILD_SHARED_LIBS=OFF

     If these tests reveal that trunk changes are necessary, do those, commit
them, and retest them.

(4)  Update ChangeLog and README.Release_Manager_Cookbook

*    Update this file (README.Release_Manager_Cookbook) as much as
     possible concerning what has been done to complete this release
     and commit that result.  However, if some subsequent deviations
     occur from the instructions in this cookbook then this file
     should also be tweaked after the release (see (10)).
svn commit README.Release_Manager_Cookbook

*    Prepare a (hopefully) final version of the ChangeLog file and commit it.
svn update
svn log --revision BASE:${LAST_RELEASE_REVISION} --verbose >| ChangeLog.preliminary
mv ChangeLog.preliminary ChangeLog.release
svn commit ChangeLog.release

(5)  Tag the release

     Based on suggestions in the svn manual, the libLASi svn archive
     is configured as follows:

branches/
tags/
trunk/

     For the release, you will be creating (and eventually committing)
     what is essentially a branch of libLASi that is a snapshot record
     of that subproject at the time of the release. This branch will
     be located in the /tags directory and should follow the naming
     convention tags/$LASI_VERSION although prior releases used a
     different naming convention based on CVS (!) requirements.

#ONE TIME ONLY
# The easiest way to get started is to check out the _entire_ lasi svn
# repository as follows:

svn checkout https://svn.code.sf.net/p/lasi/code lasi_allura_complete

#ONE TIME ONLY completed

     If you already have this directory, you will need to make sure
     that all your commits (probably in a different local directory)
     have been done (see above) and that lasi_complete is up to date
     with those commits.

cd lasi_allura_complete
svn update

# Create and commit release tag of lasi
svn copy trunk tags/$LASI_VERSION

(6)  Create and test the release tarball from the tagged version

     Do exactly the same as (3), but for tagged source code in
     tags/$LASI_VERSION

     In the (unlikely event that problems are found in the tarball
     generated from the tagged version during the release process,
     corrections should be made to trunk/, the ChangeLog.release file
     recreated and committed (see instructions above).  Then merge the
     trunk version into the tags as follows:

cd tags/$LASI_VERSION
svn merge -r A:B /path/to/trunk

     Where A and B specify the range of revisions in trunk to be
     applied to tags/$LASI_VERSION in the merge process. These can be
     determined by commit messages.

(7)  Generate a file release at Sourceforge

     A list of your GPG keys can be obtained using the command "gpg --list-keys <first name>"
     where <first name> is the first name you used when creating your gpg key.  The result of
     that command for the current release manager (AWI) is

pub   rsa2048 2011-08-19 [SC] [expires: 2021-12-12]
      A7CED6D2D4903103FCDDFC1E418B8FC4BB159E92
uid           [ultimate] Alan W. Irwin (Time Ephemerides key) <airwin@users.sourceforge.net>
uid           [ultimate] Alan W. Irwin (libLASi key) <airwin@users.sourceforge.net>
uid           [ultimate] Alan W. Irwin (FreeEOS key) <airwin@users.sourceforge.net>
uid           [ultimate] Alan W. Irwin (PLplot key) <airwin@users.sourceforge.net>

     The A7CED6D2D4903103FCDDFC1E418B8FC4BB159E92 field above can be used for key signings,
     but more conveniently its last 8 characters can be used for that purpose, e.g.,
     BB159E92

     Also, a new curveball thrown by the Debian Testing version of gpg
     is you must identify the tty you are using with, e.g.,

export GPG_TTY=$(tty)

     (see remarks at
     <https://www.elliotblackburn.com/importing-pgp-keys-from-keybase-into-gpg/>)

     Otherwise, in my experience, gpg will refuse to sign the tag and
     you will get the error:

error: gpg failed to sign the data
error: unable to sign the tag

     But with the above trick, the following command just worked.

gpg --default-key BB159E92 --detach-sign --armor libLASi-$LASI_VERSION.tar.gz

     where BB159E92 is the last 8 characters of the full key
     identification above and is sufficient to identify the public key
     for Alan W. Irwin as taken from the above key list.  N.B. it
     appears there is no gpg model for signing with a particular user
     id.  So the signature verification below will have all UID's.

     Then verify that result:

gpg --verify libLASi-$LASI_VERSION.tar.gz.asc

     where the output of that commmand should be similar to

gpg: assuming signed data in 'libLASi-1.1.3.tar.gz'
gpg: Signature made Wed 30 Jan 2019 10:58:19 PM PST
gpg:                using RSA key A7CED6D2D4903103FCDDFC1E418B8FC4BB159E92
gpg: Good signature from "Alan W. Irwin (Time Ephemerides key) <airwin@users.sourceforge.net>" [ultimate]
gpg:                 aka "Alan W. Irwin (libLASi key) <airwin@users.sourceforge.net>" [ultimate]
gpg:                 aka "Alan W. Irwin (FreeEOS key) <airwin@users.sourceforge.net>" [ultimate]
gpg:                 aka "Alan W. Irwin (PLplot key) <airwin@users.sourceforge.net>" [ultimate]

     Copy the results to a more permanent location:

cp libLASi-$LASI_VERSION.tar.gz* /home/software/lasi_svn/HEAD/export

     Prepare a temporary file called README.release that concatenates
     README.release and ChangeLog.release.

cd lasi_allura_complete/tags/$LASI_VERSION

echo "

DETAILED CHANGELOG FOR THIS RELEASE

" | \
cat README.release - ChangeLog.release >| /tmp/README.release

     Upload the release to SourceForge using sftp

cd /home/software/lasi_svn/HEAD/export

sftp airwin,lasi@frs.sourceforge.net <<EOF
cd /home/frs/project/l/la/lasi/lasi
mkdir "$LASI_VERSION Source"
cd "$LASI_VERSION Source"
put libLASi-$LASI_VERSION.tar.gz.asc
put libLASi-$LASI_VERSION.tar.gz
lcd /tmp
put README.release
quit
EOF

     Demonstrate with irwin account that can download these uploaded
     results and verify them:

SITE=https://sourceforge.net/projects/lasi/files/lasi/"$LASI_VERSION Source"
wget "$SITE/libLASi-$LASI_VERSION.tar.gz.asc"
wget "$SITE/libLASi-$LASI_VERSION.tar.gz"

gpg --verify libLASi-$LASI_VERSION.tar.gz.asc

# Belt and suspenders....

diff libLASi-$LASI_VERSION.tar.gz.asc /home/software/lasi_svn/HEAD/export
diff libLASi-$LASI_VERSION.tar.gz /home/software/lasi_svn/HEAD/export

     Login to sf.net

     Go to the file-release area at
     sf.net/projects/lasi/files/lasi/<LASI_VERSION> Source

     (where <LASI_VERSION> stands for whatever you have set
     LASI_VERSION to above)

     Click on the "i" or "info" button to mark the tar.gz file as the
     default file to download for all platforms.

(8)  Commit the tagged version
cd lasi_allura_complete
svn commit tags/$LASI_VERSION

(9)  Publicity for the release announcement

     Create a news item for the Release:
     Click on the news menu item and then click on

     Click "Submit" for the news feature.

     Experience shows you should edit a temporary file with no line
     feeds except at paragraph breaks, and all URL's should be
     mentioned as-is with no html formatting.  Then cat that file, and
     cut and paste the result to the form generated above.  SF then
     turns that result into something readable as HTML with the URL's
     turned into clickable links.

     Other publicity:

     Barbara: linuxtoday.com, lwn.net, lxer.com

(10) Post release tweaking of this file (README.Release_Manager_Cookbook)

     This only needs to be done if the actual procedure followed for
     the release differed in any detail from the previously updated
     instructions in this file.

DONE!  :-)

--- Appendix ---

(A1) GNU Privacy Guard (gpg)
A brief summary of developer relevant gpg commands, see also:
http://dewinter.com/gnupg_howto/english/GPGMiniHowto.html,
man gpg, and http://www.gnupg.org/faq/GnuPG-FAQ.html.

* Configure key-server (if you haven't done that already) by editing
  $HOME/.gnupg/gpg.conf.  Also specify the auto-key-retrieve option
  for convenience.

* List keys on your keyring that have been retrieved or generated so far:

gpg --list-keys irwin

* Search for any previously published keys that you might want to
  revoke.  (Note the search phrase is case insensitive but the search
  is done on the Boolean AND of the terms so the following search would
  miss any key generated in the past by Alan Irwin because of the
  middle initial "W." that is specified for the search).  OTOH, I
  always use my middle initial for publications to reduce name clashes.

gpg --search-keys Alan W. Irwin

* Create a new key:

gpg --gen-key

  With gnupg 1.4.10, I chose the following options when creating a new key:

Please select what kind of key you want:
  (1) RSA and RSA (default)

What keysize do you want?
2048 (default)
5-year expiration date.

....

Real name: Alan W. Irwin
Email address: irwin@users.sourceforge.net
Comment: Time Ephemerides key
You selected this USER-ID:
    "Alan W. Irwin (Time Ephemerides key) <irwin@users.sourceforge.net>"


N.B. nameofkey below is the name of the key, usually specified by the
second number after the slash for the first pub line given by
"gpg --list-keys".  For example, the above key gives the following
result:

software@raven> gpg --list-keys irwin
pub   2048R/BB159E92 2011-08-19 [expires: 2016-08-17]
uid                  Alan W. Irwin (Time Ephemerides key) <irwin@users.sourceforge.net>
sub   2048R/C5ECCF77 2011-08-19 [expires: 2016-08-17]

So the name could be BB159E92.  Other possibilities exist as well such
as "irwin", but that might not be unique.

* N.B. Made a mistake in the above.  My SF e-mail address is airwin@....
not irwin@... GRRR.  So fix it.

Under --edit-key command

adduid  (fill in correct e-mail address this time)
uid number (to select uid to work on for further commands
revuid  (revoke bad e-mail one)
primary (to make the new one the primary one, I am not sure that is necessary)
trust  (to make the new one ultimately trusted, again, not sure that is necessary.  N.B. didn't seem to change trust value, but that was just bad output)

save  (to get out again)

When edited the next time showed ultimate trust value for correct id, but
I don't know whether that was the above primary/trust subcommands or
whether those were necessary at all.  It turned out those were not
necessary at all as I later used the above sequence to generate
a libLASi key and a FreeEOS uid key.

* Generate a revocation certificate.  Note this requires the pass phrase
  specified at the time of key generation so keep that pass phrase in
  a safe place or else generate the revocation certificate right after
  generating the key, and keep that certificate in a safe place.  I chose
  the former course (keep the pass phrase safe).  N.B. the options should
  appear below in the order given!

gpg --armor -o nameofkey-revocation.asc --gen-revoke nameofkey

* Publicly revoke old key (from FAQ):

gpg --import old-revocation.asc
gpg --send-keys nameofkey

* Upload your (public) key to GPG key server so that others can obtain it to
verify your signature on the release tarball.
gpg --send-keys nameofkey

gpg --refresh-keys  (to update from the server all keys including your own).

This verified that the bad irwin address was revoked even though
gpg --search-keys Alan W. Irwin

still shows revoked uid as the #1 uid.

(A2) Setting the correct date and time on your computer.

(While it is useful to have the correct time on your computer, this is no
longer strictly necessary).
Verify that your computer has the right date and time using the command date.
The easiest way to make sure the time and date are correct is to do the
following:
1. Install the debian ntpdate package.
2. Execute the command "/usr/sbin/ntpdate pool.ntp.org", which you will
   have to do as root.
This will immediately change your system clock. It is not recommended if you
have other apps running on your system that expect time to increase in a
smooth and linear fashion.

If you would like your computer to always have the correct time and date, you
can install the debian ntp package, which must be properly configured to work.
Some notes about how to do this can be found in the PLplot mailing list
archive. Look for the thread titled "PLplot 5.7.2 is now available" dated
Jan 22/23 2007.

libLASi Release 1.1.3
~~~~~~~~~~~~~~~~~~~~~
This is a maintenance release of libLASi that reflect the ongoing
efforts of the libLASi developers to respond to bug reports for this
stable and convenient library for creating PostScript documents that
can contain characters from any of the script and symbol blocks
supported in Unicode and by the Pango layout engine.

If you encounter a problem with libLASi, then please send a bug report to
the libLASi developers via the lasi-devel mailing list described at
http://lists.sourceforge.net/lists/listinfo/lasi-devel.

Please see the license under which this software is distributed (LGPL), and
the disclaimer of all warranties, given in the COPYING.LIB file.

INDEX

1. OFFICIAL NOTICES FOR USERS

1.1 CMake version compatibility
1.2 Backwards-incompatible libLASi API changes
1.3 Need help getting rid of deprecation build warnings

2. Changes relative to our previous release (version 1.1.2) in decreasing order of importance

2.1  Improve libLASi's response when pango/fontconfig chooses pure bitmapped fonts
2.2  Make glyph names have a one-to-one relationship with glyphs
2.3  Set target property POSITION_INDEPENDENT_CODE ON for the libLASi library
2.4  Make "MissingGlyphExample" a more stringent test of font or glyph issues for libLASi
2.5  Replace deprecated lower-case variants of Freetype macro constants with preferred upper-case form
2.6  Add bounding boxes to the "MissingGlyphExample" and "ComplexTextLayoutExample" examples
2.7  Rename example applications and results using consistent and descriptive core names
2.8  Fix low-resolution boundary box issue
2.9  Update doxygen configuration files from doxygen version 1.8.1.2 to 1.8.13
2.10 Change the minimum version of CMake from 2.8.9 to 3.13.2

3. Testing of this release.

END of INDEX

1. OFFICIAL NOTICES FOR USERS

1.1 CMake version compatibility

    Our build system is implemented using CMake.  The minimum version
    of CMake we allow is 3.13.2 on all platforms.  That version is the
    one we have used to test this release of libLASi (see Section 3
    below).  However, if you try later CMake versions as they are
    released during the life of this libLASi release, our build system
    will likely continue to work well because CMake has an excellent
    reputation for preserving backwards compatibility.

1.2 Backwards-incompatible libLASi API changes

    The bug fixes in this release required backwards-incompatible
    changes to the libLASi API (a change in the argument list of the
    PostscriptDocument::GlyphId::GlyphId protected method that is
    designed for internal use only and the addition of the
    PostscriptDocument::PangoItem_do protected method that is also
    designed for internal use only).  Therefore, the SOVERSION for
    libLASi has been bumped from 1 to 2 to force source code that
    depends on this library (e.g., the PLplot psttf device driver) to
    be recompiled.  However, such source code will not require changes
    to adjust to this backwards-incompatible change in the libLASi
    API.

1.3 Need help getting rid of deprecation build warnings

This release has deprecation warning build issues which are

* "warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]"

* "warning: ‘PangoContext* pango_ft2_get_context(double, double)’ is deprecated: Use 'pango_font_map_create_context' instead [-Wdeprecated-declarations]"

* "warning: ‘FT_FaceRec_* pango_ft2_font_get_face(PangoFont*)’ is deprecated: Use 'pango_fc_font_lock_face' instead [-Wdeprecated-declarations]"

All of these are beyond my current C++ and pango skill level to fix so
help with cleaning up any of these deprecation build warnings messages
would be much appreciated!

2. Changes relative to our previous release (version 1.1.2) in decreasing order of importance

2.1  Improve libLASi's response when pango/fontconfig chooses pure bitmapped fonts

     This change was the primary motivation for this release.

     Previous to this change when pango chose the popular Noto Color
     Emoji font to help render the Aries glyph, libLASi threw an error
     and aborted since such pure bitmap fonts are not suitable for
     libLASi's outline font needs.  Such a response completely stops
     PLplot tests when PLplot standard example 7 attempts to render an
     Aries glyph with either the psttf or psttfc devices.  So this
     previous response was completely unacceptable, and the fix for it
     is important.

     This change fixes that previous response by replacing all glyphs
     for a PangoItem where pango chooses a non-outline font with the
     default glyph used to represent missing glyphs.  Of course, a
     much better procedure would be to request pango to limit its
     choices to outline fonts, but as far as I know there is no method
     for doing that (outside of having one fontconfig configuration
     for libLASi use and another for all other situations), and, in
     any case, the present workaround is "good enough for now" because
     pure bitmap fonts are rare (for example, it is possible that Noto
     Color Emoji in the future may become available in the outline
     form generally preferred for modern fonts), and Pango/fontconfig
     chooses such pure bitmap fonts for relatively few glyphs.

2.2  Make glyph names have a one-to-one relationship with glyphs

     This change is an important motivation for this release.

     This change is confined to the case when fonts don't follow
     standards so that they cannot be interrogated for the glyph name,
     i.e., FT_HAS_GLYPH_NAMES(face) is false.  Before this change,
     libLASi computed its own unique glyph name using the template

LASi_glyph_<unique number>

     where <unique number> was incremented whenever the code decided a
     new glyph had been encountered.  This scheme had the following
     disadvantages:

*    The logic for deciding when new glyphs were encountered was
     faulty with the result that the same glyph would have multiple
     glyph names and therefore redundant glyph information stored in
     the PostScript header whenever, for example, both

doc.osBody() << show(string)

     and

doc.get_dimensions(string,&lineSpacing,&xAdvance,&yMinimum,&yMaximum);

     (a common combination when bounding boxes are being determined)
     were called for the same string.

*    The glyph name depended on the order with which strings were
     processed with the result that PLplot octave results (where all
     standard octave examples were run from one instance of octave)
     had different glyph names than PLplot C results (where all
     standard C examples were run using separate executables for each
     example).

*    The glyph names were completely meaningless to humans reading
     through the PostScript code in the results.

     All these issues were addressed by borrowing a static function
     from PLplot (whose LGPL'd code allows us to do that) to calculate
     the UCS4 (32-bit unsigned) encoding of unicode for each glyph
     encountered in the UTF-8 encoded input string.  With the result
     that the glyph names now have the template

LASi_glyph_U+<UCS4 hexadecimal code for the glyph>

     where by definition the UCS4 hexadecimal code completely
     identifies the glyph in a unique way which is easy to look up,
     e.g., with the gucharmap application.

     The net result of this change is the PLplot test_diff_device
     target for the case when -DPLPLOT_TEST_DEVICE=psttfc now gives a
     clean report for the first time ever.  So this change is an
     important one.

2.3  Set target property POSITION_INDEPENDENT_CODE ON for the libLASi library

     This change is an important motivation for this release.

     This bug fix allows the static version of libLASi to be used with
     shared builds of external software that depend on libLASi such as
     the PLplot psttf device driver.

2.4  Make "MissingGlyphExample" a more stringent test of font or glyph issues for libLASi

     The most important change here was to add

"Unicode U+2648 ARIES (twice): ♈♈"
"Embedded newlines a\\nb\\nc: a\nb\nc"

     to the strings that are rendered to PostScript by this example.

     For the first of these, the Debian Buster version of pango
     (likely due to the default fontconfig configuration) decides to
     use the popular Noto Color Emoji font to render the Aries glyphs,
     but the problem for that font is it is a pure bitmap font with no
     outline information that is required by libLASi.  So this line
     tests the response of libLASi to this situation.

     For the second of these the linefeed "\n" glyph is a non-printing
     glyph.  It appears for all such glyphs there is a "missing glyph"
     issue so regardless of future font improvements this line seems
     to be a reliable way to trigger missing-glyph issues to test the
     response of libLASi to this situation.

2.5  Replace deprecated lower-case variants of Freetype macro constants with preferred upper-case form

2.6  Add bounding boxes to the "MissingGlyphExample" and "ComplexTextLayoutExample" examples

     The resulting MissingGlyphExample.eps and
     ComplexTextLayoutExample.eps files join SimpleLASiExample.eps as
     being properly formatted EPS (Encapsulated PostScript) files.

     Note also that for the "Complex Text Layout" case, I implemented
     some generally useful C++ code macros (called
     LASI_SHOW_AND_UPDATE_BB, LASI_SCALED_SHOW_AND_UPDATE_BB, and
     LASI_ROTATED_SHOW_AND_UPDATE_BB), which made it straightforward
     to handle even complex cases such as determining the bounding box
     of text that has undergone anamorphic scaling or rotation.  For
     example, the LASI_ROTATED_SHOW_AND_UPDATE_BB macro includes C++
     code to apply the rotation matrix to determine the x,y
     coordinates of the corners of the rotated text box and use those
     corner coordinates to help determine the overall bounding box.

2.7  Rename example applications and results using consistent and descriptive core names

     Those core names are " MissingGlyphExample", "SimpleLASiExample",
     and "ComplexTextLayoutExample".  As a result the example source
     code name is <core name>.cpp, the example application name is
     <core name> (or <core name>.exe on Windows platforms), the EPS
     (Encapsulated PostScript) results are named <core name>.eps, and
     the PNG results (generated from the EPS results using inkscape)
     are named <core name>.png.

2.8  Fix low-resolution boundary box issue

     As a result of this change the low-res (int) BB (bounding box)
     limits are calculated from the high-res (double) BB limits with
     the appropriate combinations of floor and ceil so the low-res
     limits always lie on or outside (by up to but not including 1
     point) the high-res limits.  Previously this calculation was done
     incorrectly with floor for all limits.

2.9  Update doxygen configuration files from doxygen version 1.8.1.2 to 1.8.13

     These changes were done in the usual way by running the following
     commands:

doxygen -u Doxyfile.developer
doxygen -u Doxyfile.user

2.10 Change the minimum version of CMake from 2.8.9 to 3.13.2

     This change was motivated by the bug fixes in later CMake
     versions and also the much better checking of the build system
     that occurs for the policies automatically used for 3.13.2.

3. Testing of this release.

This release has been successfully built and run-tested (following the
prescription in README.Release_Manager_Cookbook) for both the shared
and static library case on Linux (Debian Buster) using CMake-3.13.2
(the minimum allowed version of CMake for libLASi), libpango-1.42.4,
libcairo-1.16.0, libfreetype-2.9.1, and libfontconfig-2.13.1.

This release has not been tested (yet) on Mac OS X or Windows
platforms, but we anticipate no difficulties on those platforms since
previous versions of libLASi have worked well on those platforms.  In
other words, the cross-platform nature of libLASi appears to have been
well supported by CMake in the past, and we feel that happy state will
continue with this release as well.

libLASi Release 1.1.2
~~~~~~~~~~~~~~~~~~~~~
This is a maintenance release of libLASi that reflect the ongoing
efforts of the libLASi developers to respond to bug reports for this
stable and convenient library for creating PostScript documents that
can contain characters from any of the script and symbol blocks
supported in Unicode and by the Pango layout engine.

If you encounter a problem with libLASi, then please send a bug report to
the libLASi developers via the lasi-devel mailing list described at
http://lists.sourceforge.net/lists/listinfo/lasi-devel.

Please see the license under which this software is distributed (LGPL), and
the disclaimer of all warranties, given in the COPYING.LIB file.

INDEX

1. Changes relative to our previous release (version 1.1.1).

2. Testing of this release.

1.1 Update of examples/MissingGlyphExample.cpp
1.2 #include FreeType headers in recommended (by FreeType) way.
1.3 Make all install locations configurable.
1.4 Fix FreetypeGlyphMgr::FreetypeGlyphMgr(FT_Glyph glyph) initialization bug.
1.5 Fix long-standing file repeatability issue.

1.1 Update of examples/MissingGlyphExample.cpp

The whole point of this example was to make sure that libLASi
responded well to missing glyphs, but the example had gotten seriously
outdated because for modern Linux systems with the normal system
fonts, the chosen unicode characters were no longer missing!  That
issue has now been addressed by using a larger variety of obscure
unicode glyphs in the examples based on some glyphs that gucharmap
says are missing for the particular Debian stable platform where this
release is being created.  At the same time, I took the opportunity to
improve the look of the PostScript results of this example by
indicating its purpose and keeping results for the various test
glyphs separate from each other.  The results are good (no build or
run-time errors, the PostScript results are now self-explanatory, and
the missing glyphs are indicated by empty boxes).

1.2 #include FreeType headers in recommended (by FreeType) way.

This fixes <https://sourceforge.net/p/lasi/bugs/2/>, does not disrupt
the previous success with building libLASi against FreeType version
2.4.9, and for the first time allows libLASi to build against FreeType
version 2.5.1 and later.  So this is a high-impact fix for use of
libLASi with the latest FreeType versions and is also the fundamental
motivation for this maintenance release.

1.3 Make all install locations configurable.

This fixes <https://sourceforge.net/p/lasi/bugs/3/> and makes it more
convenient to package libLASi.

1.4 Fix FreetypeGlyphMgr::FreetypeGlyphMgr(FT_Glyph glyph) initialization bug.

This fixes <https://sourceforge.net/p/lasi/bugs/4/>.  The particular
method being fixed here is not used in any of our examples, and was
only caught by compiler warning messages rather than a bug report
about actual use of this method so this is likely a low-impact
fix.

1.5 Fix long-standing file repeatability issue.

This bug <https://sourceforge.net/p/lasi/bugs/5/> was discovered while
testing a pre-release version of 1.1.2, but apparently also appeared
in all prior releases of libLASi.  The issue was glyphs without a name
available in the font data were assigned a unique name by libLASi
using rand, but those unique names were not repeatable from one run of
an application linked to libLASi to the next (presumably because
libraries that libLASi depends on were fiddling with the rand seed in
some threaded way that was not repeatable).  An initial fix that used
rand_r and a unique seed for libLASi solved the issue, but ultimately
it was decided to solve the issue by using the libLASi assigned names
LASi_glyph_1, LASi_glyph_2, etc., which should be unique until the
integer overflow limit is encountered, and which should not name clash
with glyph names that are included with font data.

2. Testing of this release.

This release has been successfully build and run tested on Linux using
(1) libpango-1.30.0, libcairo-1.12.2, and libfreetype-2.4.9 and (2)
libpango-1.35.0, libcairo-1.12.14, and libfreetype-2.5.3.

Thanks to the kind testing help of Arjen Markus, this release has also
been successfully build and run tested on Windows using the build
procedure for that platform given at <http://www.unifont.org/lasi/>
using the gtk+ all-in-one Windows bundle downloaded from
<http://www.gtk.org/download/win32.php> which includes
libpango-1.30.1, libcairo-1.10.2, and libfreetype-2.4.11.

Although there has been no specific testing of this release on Mac OS
X, we do not anticipate any difficulties for that platform since
previous releases of libLASi (patched for the above freetype header
issue) have worked fine on that platform according to reports at
https://sourceforge.net/p/lasi/bugs/2/.

libLASi Release 1.1.1
~~~~~~~~~~~~~~~~~~~~~
This is a stable release of libLASi. It represents the ongoing efforts
of the libLASi developers to improve the libLASi library for creating
PostScript documents that can contain characters from any of the
script and symbol blocks supported in Unicode and by the Pango layout engine.

If you encounter a problem with libLASi, then please send a bug report to
the libLASI developers via the lasi-devel mailing list described at
http://lists.sourceforge.net/lists/listinfo/lasi-devel.

Please see the license under which this software is distributed (LGPL), and
the disclaimer of all warrantees, given in the COPYING.LIB file.

INDEX

1. Changes relative to our previous release (version 1.1.0).

1.1 Make declaration and definition of setFont arguments consistent.
1.2 Fix alignment of diacritical marks.
1.3 Build system improvements.
1.4 Reduction of symbol visibility for gcc.

1.1 Make declaration and definition of setFont arguments consistent.

Thanks to John Ellson's bug report (link failure with Sun's CC - ID:
2797964) we found out that the arguments of setFont had inconsistent
const attributes between the declaration in LASi.h and the definition
in psDoc.cpp.  We have now fixed that inconsistency by using John's
patch to drop the const attribute from the appropriate definition
arguments.

1.2 Fix alignment of diacritical marks.

Thanks to Yotam Medini for supplying a patch which we have applied to
correct the positioning of diacritical marks.  This change means there
must be an extra bool applyOffset = false argument to the
PostscriptDocument::for_each_glyph_do method (see Lasi.h).  This
method is called internally by other libLASi routines with applyOffset
both true and false depending on circumstances/needs to obtain
correct offsets for diacritical marks.

This method is also available for external use so this added argument
is a backwards-incompatible API change requiring rebuilding of
apps/libraries that use this method, and the soversion of the library
has been bumped from 0 to 1 consistent with this API change.  However,
this external API change issue is not relevant for the libLASi
examples that are part of this release and also to the psttf device driver
for PLplot that depends on libLASi because those applications and device
driver plug-ins do not call the for_each_glyph_do method.

1.3 Build system improvements.

Our CMake-based build system has been updated to determine pkg-config
results in a way that is much more useful for CMake.  (We simply
adopted PLplot's method of handling this).  The result is that modern
CMake (tested on CMake-2.6.4 and CMake-2.8.1) warnings about
inconsistent library handling by Policy CMP0003 are no longer present.
The minimum version of CMake has been updated from 2.4.5 (!) to 2.6.4.

1.4 Reduction of symbol visibility for gcc.

The infrastructure in LASi.h for exporting symbols for the Windows
version of this library has been generalized for the gcc-4.x case for
Unix platforms following the well-tested implementation used for
the PLplot libraries.

The net effect of this change is that Windows visibility of symbols
should be unchanged and similarly for Unix _except_ for the case of
gcc on Unix where the user specifies the gcc -fvisibility=hidden
option.  For that case, the exported symbols are reduced to those
exported in the Windows case.  The difference in results between using
default visibility and -fvisibility=hidden for gcc-4.x on Unix is the
number of visible symbols in libLASi.so is reduced from 164 to the 128
actually needed by users of the library which should give a modest but
still significant reduction in load times.

libLASi Release 1.1.0
~~~~~~~~~~~~~~~~~~~~~
This is a stable release of libLASi. It represents the ongoing efforts
of the libLASi developers to improve the libLASi library for creating
PostScript documents that can contain characters from any of the
script and symbol blocks supported in Unicode and by the Pango layout engine.

If you encounter a problem with libLASi, then please send a bug report to
the libLASI developers via the lasi-devel mailing list described at
http://lists.sourceforge.net/lists/listinfo/lasi-devel.

Please see the license under which this software is distributed (LGPL), and
the disclaimer of all warrantees, given in the COPYING.LIB file.

INDEX

1. Changes relative to our previous release (version 1.0.5p1 for FreeType
versions less than 2.2 and version 1.0.6 for FreeType 2.2+).

1.1 Replace autotools-based build system with a CMake-based build system.
1.2 libLASi can now be built both on Unix and Windows.
1.3 The examples have been reorganized and extended.
1.4 libLASi is now more robust against font/glyph issues.


1.1 Replace autotools-based build system with a CMake-based build system.

The build system is now based on CMake. It has been tested on Linux,
Mac OS-X and Windows platforms.  For directions on how to use CMake to
build libLASi, please consult http://www.unifont.org/lasi/.  In particular,
the new build system has the capability of detecting the FreeType version
so the previous split release (1.0.5p1 and 1.0.6) is no longer necessary.

1.2 libLASi can now be built both on Unix and Windows

Our new CMake-based build system allows building libLASi on both Unix
(Linux, Mac OS X, and proprietary Unices) and Windows (Cygwin, MinGW/MSYS,
and Microsoft proprietary build environments) platforms.  Instructions
for various platforms have been collected at http://www.unifont.org/lasi/.

1.3 The examples have been reorganized and extended and can now be built
in both the build tree and install tree.

After running "cmake" (which configures libLASi) and "make" (which builds
the libLASi library and examples which use that library in the build tree,
see instructions at http://www.unifont.org/lasi/), you can run ctest in the
build tree to run the examples. If ctest shows no errors, the PostScript
results of that test of the libLASi library are collected in the
examples/example[0-2].ps files in the build tree. See examples/README
in the source tree for descriptions of these test examples.

The examples can also independently be built and run in the install tree
created by "make install" as well using

cd $version/share/lasi$lasi_version/examples
make

where $version is the installation prefix specified as a command-line option
for the cmake command, and $lasi_version is currently 1.1.0.  The make
command uses pkg-config to specify the correct C++ flags and link flags, and
users with independent applications that link to libLASi are advised to use
the same method as well.

1.4 libLASi is now more robust against font/glyph issues.

Missing glyphs are now rendered as a blank rather than being the cause of
showstopping errors seen in previous libLASi releases.

Some font installations were occasionally returning non-outline glyphs that
were causing segfault errors for older libLASi versions.  The libLASi code
has now been changed to render a blank for such cases and only attempt to
render results for the outline glyphs it was designed for.

libLASi Release 1.1.3
~~~~~~~~~~~~~~~~~~~~~
This is a maintenance release of libLASi that reflect the ongoing
efforts of the libLASi developers to respond to bug reports for this
stable and convenient library for creating PostScript documents that
can contain characters from any of the script and symbol blocks
supported in Unicode and by the Pango layout engine.

If you encounter a problem with libLASi, then please send a bug report to
the libLASi developers via the lasi-devel mailing list described at
http://lists.sourceforge.net/lists/listinfo/lasi-devel.

Please see the license under which this software is distributed (LGPL), and
the disclaimer of all warranties, given in the COPYING.LIB file.

INDEX

1. OFFICIAL NOTICES FOR USERS

1.1 CMake version compatibility
1.2 Backwards-incompatible libLASi API changes
1.3 Need help getting rid of deprecation build warnings

2. Changes relative to our previous release (version 1.1.2) in decreasing order of importance

2.1  Improve libLASi's response when pango/fontconfig chooses pure bitmapped fonts
2.2  Make glyph names have a one-to-one relationship with glyphs
2.3  Set target property POSITION_INDEPENDENT_CODE ON for the libLASi library
2.4  Make "MissingGlyphExample" a more stringent test of font or glyph issues for libLASi
2.5  Replace deprecated lower-case variants of Freetype macro constants with preferred upper-case form
2.6  Add bounding boxes to the "MissingGlyphExample" and "ComplexTextLayoutExample" examples
2.7  Rename example applications and results using consistent and descriptive core names
2.8  Fix low-resolution boundary box issue
2.9  Update doxygen configuration files from doxygen version 1.8.1.2 to 1.8.13
2.10 Change the minimum version of CMake from 2.8.9 to 3.13.2

3. Testing of this release.

END of INDEX

1. OFFICIAL NOTICES FOR USERS

1.1 CMake version compatibility

    Our build system is implemented using CMake.  The minimum version
    of CMake we allow is 3.13.2 on all platforms.  That version is the
    one we have used to test this release of libLASi (see Section 3
    below).  However, if you try later CMake versions as they are
    released during the life of this libLASi release, our build system
    will likely continue to work well because CMake has an excellent
    reputation for preserving backwards compatibility.

1.2 Backwards-incompatible libLASi API changes

    The bug fixes in this release required backwards-incompatible
    changes to the libLASi API (a change in the argument list of the
    PostscriptDocument::GlyphId::GlyphId protected method that is
    designed for internal use only and the addition of the
    PostscriptDocument::PangoItem_do protected method that is also
    designed for internal use only).  Therefore, the SOVERSION for
    libLASi has been bumped from 1 to 2 to force source code that
    depends on this library (e.g., the PLplot psttf device driver) to
    be recompiled.  However, such source code will not require changes
    to adjust to this backwards-incompatible change in the libLASi
    API.

1.3 Need help getting rid of deprecation build warnings

This release has deprecation warning build issues which are

* "warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]"

* "warning: ‘PangoContext* pango_ft2_get_context(double, double)’ is deprecated: Use 'pango_font_map_create_context' instead [-Wdeprecated-declarations]"

* "warning: ‘FT_FaceRec_* pango_ft2_font_get_face(PangoFont*)’ is deprecated: Use 'pango_fc_font_lock_face' instead [-Wdeprecated-declarations]"

All of these are beyond my current C++ and pango skill level to fix so
help with cleaning up any of these deprecation build warnings messages
would be much appreciated!

2. Changes relative to our previous release (version 1.1.2) in decreasing order of importance

2.1  Improve libLASi's response when pango/fontconfig chooses pure bitmapped fonts

     This change was the primary motivation for this release.

     Previous to this change when pango chose the popular Noto Color
     Emoji font to help render the Aries glyph, libLASi threw an error
     and aborted since such pure bitmap fonts are not suitable for
     libLASi's outline font needs.  Such a response completely stops
     PLplot tests when PLplot standard example 7 attempts to render an
     Aries glyph with either the psttf or psttfc devices.  So this
     previous response was completely unacceptable, and the fix for it
     is important.

     This change fixes that previous response by replacing all glyphs
     for a PangoItem where pango chooses a non-outline font with the
     default glyph used to represent missing glyphs.  Of course, a
     much better procedure would be to request pango to limit its
     choices to outline fonts, but as far as I know there is no method
     for doing that (outside of having one fontconfig configuration
     for libLASi use and another for all other situations), and, in
     any case, the present workaround is "good enough for now" because
     pure bitmap fonts are rare (for example, it is possible that Noto
     Color Emoji in the future may become available in the outline
     form generally preferred for modern fonts), and Pango/fontconfig
     chooses such pure bitmap fonts for relatively few glyphs.

2.2  Make glyph names have a one-to-one relationship with glyphs

     This change is an important motivation for this release.

     This change is confined to the case when fonts don't follow
     standards so that they cannot be interrogated for the glyph name,
     i.e., FT_HAS_GLYPH_NAMES(face) is false.  Before this change,
     libLASi computed its own unique glyph name using the template

LASi_glyph_<unique number>

     where <unique number> was incremented whenever the code decided a
     new glyph had been encountered.  This scheme had the following
     disadvantages:

*    The logic for deciding when new glyphs were encountered was
     faulty with the result that the same glyph would have multiple
     glyph names and therefore redundant glyph information stored in
     the PostScript header whenever, for example, both

doc.osBody() << show(string)

     and

doc.get_dimensions(string,&lineSpacing,&xAdvance,&yMinimum,&yMaximum);

     (a common combination when bounding boxes are being determined)
     were called for the same string.

*    The glyph name depended on the order with which strings were
     processed with the result that PLplot octave results (where all
     standard octave examples were run from one instance of octave)
     had different glyph names than PLplot C results (where all
     standard C examples were run using separate executables for each
     example).

*    The glyph names were completely meaningless to humans reading
     through the PostScript code in the results.

     All these issues were addressed by borrowing a static function
     from PLplot (whose LGPL'd code allows us to do that) to calculate
     the UCS4 (32-bit unsigned) encoding of unicode for each glyph
     encountered in the UTF-8 encoded input string.  With the result
     that the glyph names now have the template

LASi_glyph_U+<UCS4 hexadecimal code for the glyph>

     where by definition the UCS4 hexadecimal code completely
     identifies the glyph in a unique way which is easy to look up,
     e.g., with the gucharmap application.

     The net result of this change is the PLplot test_diff_device
     target for the case when -DPLPLOT_TEST_DEVICE=psttfc now gives a
     clean report for the first time ever.  So this change is an
     important one.

2.3  Set target property POSITION_INDEPENDENT_CODE ON for the libLASi library

     This change is an important motivation for this release.

     This bug fix allows the static version of libLASi to be used with
     shared builds of external software that depend on libLASi such as
     the PLplot psttf device driver.

2.4  Make "MissingGlyphExample" a more stringent test of font or glyph issues for libLASi

     The most important change here was to add

"Unicode U+2648 ARIES (twice): ♈♈"
"Embedded newlines a\\nb\\nc: a\nb\nc"

     to the strings that are rendered to PostScript by this example.

     For the first of these, the Debian Buster version of pango
     (likely due to the default fontconfig configuration) decides to
     use the popular Noto Color Emoji font to render the Aries glyphs,
     but the problem for that font is it is a pure bitmap font with no
     outline information that is required by libLASi.  So this line
     tests the response of libLASi to this situation.

     For the second of these the linefeed "\n" glyph is a non-printing
     glyph.  It appears for all such glyphs there is a "missing glyph"
     issue so regardless of future font improvements this line seems
     to be a reliable way to trigger missing-glyph issues to test the
     response of libLASi to this situation.

2.5  Replace deprecated lower-case variants of Freetype macro constants with preferred upper-case form

2.6  Add bounding boxes to the "MissingGlyphExample" and "ComplexTextLayoutExample" examples

     The resulting MissingGlyphExample.eps and
     ComplexTextLayoutExample.eps files join SimpleLASiExample.eps as
     being properly formatted EPS (Encapsulated PostScript) files.

     Note also that for the "Complex Text Layout" case, I implemented
     some generally useful C++ code macros (called
     LASI_SHOW_AND_UPDATE_BB, LASI_SCALED_SHOW_AND_UPDATE_BB, and
     LASI_ROTATED_SHOW_AND_UPDATE_BB), which made it straightforward
     to handle even complex cases such as determining the bounding box
     of text that has undergone anamorphic scaling or rotation.  For
     example, the LASI_ROTATED_SHOW_AND_UPDATE_BB macro includes C++
     code to apply the rotation matrix to determine the x,y
     coordinates of the corners of the rotated text box and use those
     corner coordinates to help determine the overall bounding box.

2.7  Rename example applications and results using consistent and descriptive core names

     Those core names are " MissingGlyphExample", "SimpleLASiExample",
     and "ComplexTextLayoutExample".  As a result the example source
     code name is <core name>.cpp, the example application name is
     <core name> (or <core name>.exe on Windows platforms), the EPS
     (Encapsulated PostScript) results are named <core name>.eps, and
     the PNG results (generated from the EPS results using inkscape)
     are named <core name>.png.

2.8  Fix low-resolution boundary box issue

     As a result of this change the low-res (int) BB (bounding box)
     limits are calculated from the high-res (double) BB limits with
     the appropriate combinations of floor and ceil so the low-res
     limits always lie on or outside (by up to but not including 1
     point) the high-res limits.  Previously this calculation was done
     incorrectly with floor for all limits.

2.9  Update doxygen configuration files from doxygen version 1.8.1.2 to 1.8.13

     These changes were done in the usual way by running the following
     commands:

doxygen -u Doxyfile.developer
doxygen -u Doxyfile.user

2.10 Change the minimum version of CMake from 2.8.9 to 3.13.2

     This change was motivated by the bug fixes in later CMake
     versions and also the much better checking of the build system
     that occurs for the policies automatically used for 3.13.2.

3. Testing of this release.

This release has been successfully built and run-tested (following the
prescription in README.Release_Manager_Cookbook) for both the shared
and static library case on Linux (Debian Buster) using CMake-3.13.2
(the minimum allowed version of CMake for libLASi), libpango-1.42.4,
libcairo-1.16.0, libfreetype-2.9.1, and libfontconfig-2.13.1.

This release has not been tested (yet) on Mac OS X or Windows
platforms, but we anticipate no difficulties on those platforms since
previous versions of libLASi have worked well on those platforms.  In
other words, the cross-platform nature of libLASi appears to have been
well supported by CMake in the past, and we feel that happy state will
continue with this release as well.