------------------------------------------------------------------------
r220 | airwin | 2019-01-30 23:10:35 -0800 (Wed, 30 Jan 2019) | 10 lines
Changed paths:
   M /trunk/README.Release_Manager_Cookbook

Update to the lastest version of the instructions for the release manager

This file should reflect the actual commands and actual results of
those commands for this release.  And it is up to date in that regard
for what has gone on so far in this release.  However, in case there
are a few further tweaks necessary in the description of the commands
in the rest of the release process, then this file should be updated
again to reflect those changes just after the release.


------------------------------------------------------------------------
r219 | airwin | 2019-01-30 12:38:40 -0800 (Wed, 30 Jan 2019) | 8 lines
Changed paths:
   M /trunk/README.cumulated_release
   M /trunk/README.release

Finalize release notes for the forthcoming release of libLASi-1.1.3

As part of this change, I have prepended README.release into
README.cumulated_release so if there are any added tweaks after this
before the libLASi-1.1.3 release both README.release and
README.cumulated_release should be tweaked in the same way.


------------------------------------------------------------------------
r218 | airwin | 2019-01-29 22:26:05 -0800 (Tue, 29 Jan 2019) | 10 lines
Changed paths:
   D /trunk/CONCATENATED_README.release
   A /trunk/README.cumulated_release (from /trunk/CONCATENATED_README.release:217)

Rename CONCATENATED_README.release => README.cumulated_release

This new name for this cumulation of release notes follows how
this file is named in PLplot.

Note, before making this name change I double-checked that
this file contained all recent release notes up to and
including the last (1.1.2) release.


------------------------------------------------------------------------
r217 | airwin | 2019-01-29 19:30:55 -0800 (Tue, 29 Jan 2019) | 18 lines
Changed paths:
   M /trunk/README
   M /trunk/cmake/modules/lasi_version.cmake

Bump package version from 1.1.2 to 1.1.3 and library SOVERSION from 1 to 2 in anticipation of the 1.1.3 release

The bump in just the patch number of the package version reflects that
only maintenance and no new development has occurred for this release.
However, that maintenance did involve necessary but relatively minor
backwards-incompatible changes to the libLASi API (a change in the
PostscriptDocument::GlyphId::GlyphId protected method API 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).

As a result of these backwards incompatibilities, the library
SOVERSION had to be bumped from 1 to 2 to force users of this library
(e.g., the PLplot psttf device driver) to do the required
recompilations for this case.  However, there is no need for users to
actually change their source code to adjust to these backwards
incompatibilities.

------------------------------------------------------------------------
r216 | airwin | 2019-01-29 18:38:11 -0800 (Tue, 29 Jan 2019) | 36 lines
Changed paths:
   M /trunk/examples/CMakeLists.txt
   A /trunk/examples/ComplexTextLayoutExample.png
   D /trunk/examples/Example_1_Result.png
   D /trunk/examples/Example_2_Result.png
   M /trunk/examples/Makefile.examples.in
   A /trunk/examples/MissingGlyphExample.png
   A /trunk/examples/SimpleLASiExample.png

Reorganize how examples are built and run and replace old PNG snapshots with new ones

All references to a numerical "example[0-2]" core name style for
example applications and results have now been replaced by the more
descriptive core names MissingGlyphExample, SimpleLASiExample, and
ComplexTextLayoutExample.  This core name change also makes the names
of example applications and results consistent with the name of the
source code used for each of the examples.

These examples now do the appropriate bounding-box calculations so the
results for all three of these examples are now in valid EPS
(Encapsulated PostScript) format.  Accordingly the suffix of the
results of these applications has been changed from ".ps" to ".eps".
(This change in suffix is necessary before inkscape will honor the
bounding boxes.)

The new PNG snapshots generated by inkscape (now automatically
calculated in the build tree as a result of building the "all" target)
are much higher quality than the previous decade-old snapshots because
(i) pango is much more advanced than it was a decade ago, (ii) Linux
fonts are much better than they were a decade ago, and (iii) inkscape
does a better job of converting to PNG format than whatever (likely
commercial) application was used for such conversion a decade ago.
Accordingly I have removed the old PNG results from the examples
subdirectory of the source tree and replaced them with the current
build-tree results (on the Debian Testing platform) for
MissingGlyphExample.png, SimpleLASiExample.png, and
ComplexTextLayoutExample.png

Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by following all the shared library and static
library build-tree and installed examples tree test steps documented
in a local variation of README.Release_Manager_Cookbook that will soon
be committed.  All these tests passed without any issues.


------------------------------------------------------------------------
r215 | airwin | 2019-01-29 18:11:58 -0800 (Tue, 29 Jan 2019) | 4 lines
Changed paths:
   M /trunk/CMakeLists.txt
   M /trunk/src/CMakeLists.txt

Insert copyright notice in CMakeLists.txt and  src/CMakeLists.txt

In addition I fixed a CMake version number typo in the CMakeLists.txt comments.

------------------------------------------------------------------------
r214 | airwin | 2019-01-29 18:08:50 -0800 (Tue, 29 Jan 2019) | 2 lines
Changed paths:
   M /trunk/examples/README

Substantial update of the documentation of the examples

------------------------------------------------------------------------
r213 | airwin | 2019-01-25 12:57:27 -0800 (Fri, 25 Jan 2019) | 85 lines
Changed paths:
   M /trunk/include/LASi.h
   M /trunk/src/psDoc.cpp

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

This change to the glyph name (for the uncommon but not rare case when
FT_HAS_GLYPH_NAMES(face) is false for a given font) changes the glyph
name calculated by the nameof static function from

LASi_glyph_<unique number>

where unique number was incremented every time nameof was called

to

LASi_glyphU+<UCS4 hexadecimal code for the glyph>.

with a fallback to the unique number name approach if the UCS4 hexadecimal code for the glyph
could not be determined for some reason.

This change to the UCS4 version means there is now a one-to-one
relationship between unique glyph name and glyph.  This has several
advantages:

* The unique glyph name is always the same for the same glyph
  regardless of the order in which glyphs are encountered in strings.
  This improvement eliminated the PLplot differences due to different
  glyph names between octave results (calculated for all our standard
  Octave examples with just one octave session) and C results
  (calculated with a separate application for each of our standard C
  examples).

* When bounding-boxes are calculated using the get_dimensions method
  and text renderered with the show command, nameof is called twice
  with the same glyph.  For that case, the unique number approach
  calculated two different glyph names for the same glyph resulting in
  redundant glyph functions (with different unique number names but
  same contents) being stored in the PostScript header.  That libLASi
  misfeature has been eliminated with the new UCS4 glyph naming
  approach.

* The new version of the glyph names contains the UCS4 information for
  the glyph which allows users to understand (with the aid of
  applications such as gucharmap) exactly which glyph their
  application was asking to be rendered.  This additional glyph
  information is quite useful when debugging results.

The implementation of this change required copying (with a small
adaptation) the C-style static function utf8_to_ucs4 from
PLplot as allowed by the LGPL license for PLplot.  This change also required
the following backwards incompatibility to the libLASi API

-          GlyphId(FT_Face, const FT_UInt);
+          GlyphId(FT_Face, const FT_UInt, uint32_t unichar);

Since this is a protected method that is normally only used internally
it is anticipated that few if any libLASi users will have to actually
change their code due to this change.  (For example, this is the case
for PLplot which depends completely on libLASi for its psttf device
driver implementation.)  However, all libLASi users will have to
recompile their code due to this change so to force that I plan to
bump the SONAME for the libLASi library (as usual for any
backwards-incompatible change) before the forthcoming release
of the libLASi software.

Tested by: Alan W. Irwin <airwin@...> on Linux
(Debian Testing) by configuring libLASi, building it with "make", and
testing it with "ctest --verbose". The results for all three examples
continued to look good.  And the redundant glyph functions in the
PostScript headers are now eliminated with the UCS4 codes double-checked
with gucharmap for example 2 in a couple of cases.

Further PLplot test:

I installed this updated liblasi library and configured a PLplot build to use that
installed version for its psttf device driver and also specified -DPLPLOT_TEST_DEVICE=psttfc
to use that device for the test_diff_device target. I built that target
(which compares psttfc results for all examples written in all our supported languages).
The test_diff_device report was perfect, i.e., the octave differences that occurred before
because of different glyph function names in the header are now gone.  In addition,
the triple redundancy (presumably because that device calls bounding box twice) in
glyph functions is now also gone.

In sum, this change has nicely eliminated a number of minor (because
FT_HAS_GLYPH_NAMES(face) is false only for relatively few fonts)
libLASi issues.


------------------------------------------------------------------------
r212 | airwin | 2019-01-24 02:32:58 -0800 (Thu, 24 Jan 2019) | 121 lines
Changed paths:
   M /trunk/examples/MissingGlyphExample.cpp
   M /trunk/include/LASi.h
   M /trunk/src/psDoc.cpp

Work around libLASi issue that occurs when pango chooses pure bitmapped fonts

An example of such a pure bitmapped font is the popular Noto Color
Emoji. For glyphs such as "Unicode U+2648 ARIES: ♈", pango
(presumably due to the default configuration of fontconfig on my
Debian Testing system) chooses this font to render this glyph (and some
other fairly common glyphs as well).  Of course, this font is incompatible with libLASi since
that library can only use scalable outline fonts rather than bitmapped
ones.

The (DEBUG) result for this incompatible pango choice was

FT_Load_Glyph is returning error = 24 for a glyph index of 52 associated with the substring ♈♈

where 24 (see
<https://www.freetype.org/freetype2/docs/reference/ft2-error_code_values.html>)
corresponds to "Invalid_Size_Handle" which I assume means simply that
pure bitmapped fonts cannot be scaled (one of the font attributes that
libLASi obviously needs).  Prior to this commit, the libLASi response
for any FT_Load_Glyph error was to try again with a glyph index of 0
(normally used to obtain the default replacement glyph for the type
face).  But, of course, the exact same error as above is obtained for
this glyph index as well for Noto Color Emoji.  Therefore, the result
of this glyph index 0 error condition was libLASi aborted which is not
an acceptable result due simply to the overall popularity of Noto
Color Emoji.

Of course, this library abort can be avoided if fontconfig is
reconfigured to avoid bitmapped fonts or (almost equivalently) the
user uninstalls the Noto Color Emoji font package, but such
"solutions" are not acceptable in general because of the popularity of
this font for many other tasks where a bitmapped font is fine.

Ideally, the solution to this issue would be to ask pango to only
choose outline fonts, but I am not aware of any method of making such
a request of that library.  So unless or until such a method is
discovered (or developed) for the pango library, the only solution to
this issue is to find a libLASi workaround when the above glyph index
0 response to a FT_Load_Glyph error also errors out.

This commit implements such a workaround which is to substitute the
default replacement glyph for each glyph in the PangoItem
(corresponding to a run of characters that can all be rendered with a
font of fixed family, slant, weight, and width (but not size)).
whenever such an error is discovered for any glyph in a PangoItem.

The chosen emergency glyph is "\n" which experience shows reliably
forces the glyph index 0 code path which replaces that linefeed
with the default replacement glyph (normally an empty box).  So the
net result is the default replacement glyph is rendered now for all
error cases.

I have updated the explanatory text in MissingGlyphExample.cpp to be
consistent with this conclusion.

N.B. as part of this fix I transferred the PangoItem processing part
of the code in the for_each_glyph_do method (which is a misnomer since
it should really be called for_each_string_do) to a new
PostscriptDocument method called PangoItem_do.  This code
reorganization makes the code substantially easier to understand with
PangoItem_do doing most of the work, and for_each_glyph_do responding
to any errors reported by that method which it could not handle itself
with the glyph_index 0 code path.

Unfortunately this reorganization means the new routine PangoItem_do
must be a protected class method (rather than a simple C-style static
routine) because it uses protected data from the PostscriptDocument
class.  This change is a backward-incompatible change to libLASi.h and
the libLASi library which will require users of that library to
recompile their code against the changed libLASi.h.  However, this
backwards-incompatible change will not require them to actually change
their code.

Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by configuring libLASi, building it with "make", and
testing it with "ctest --verbose".  The results for the "Missing
Glyphs" showed empty boxes (the expected default replacement glyph)
for both the missing glyphs and all (two) Aries glyphs associated
with a PangoItem font face where pango chose the Noto Color Emoji
font.

Further tests:

* I ran all three examples under valgrind with no memory management
  issues other than memory leaks reported.

* I installed this updated liblasi library and configured a PLplot build to use that
  installed version for its psttf device driver and also specified -DPLPLOT_TEST_DEVICE=psttfc
  to use that device for the test_diff_device target.  I built that target
  (which compares psttfc results for all examples written in all our supported languages).
  The test_diff_device report was clean except for

octave
  Missing examples            :  24
  Differing graphical output  : 
  Missing stdout              : 
  Differing stdout            : 

  which further investigation showed was simply an artifact of the octave calculation
  being done with one octave session so that the unique lasi_index number associated
  with broken fonts that fail the !FT_HAS_GLYPH_NAMES(face) test is different for
  octave compared to the C examples.

* I viewed all 33 C standard example results built as part of the test_diff_device
  target build using the gv PostScript viewer.  In all cases (except for example 7 where
  the signs of the zodiac came out as empty boxes because of the Noto Color Emoji choice
  by pango) the rendering of the examples looked good.

In sum the only issue I could find for any of these tests is
duplicated (due to bounding-box calculations) GlyphId's in those rare
cases where a font failed the !FT_HAS_GLYPH_NAMES(face) test.  That
duplication lead to redundant glyph information (with different
LASi_glyph_* titles but duplicate contents) being stored in the
headers of the PostScript results.  The only way to address this issue
is to not call GlyphId when bounding boxes are being calculated, but I
don't know how to implement such a test.  Furthermore, I judge this to
be a minor issue because relatively few fonts are sufficient broken to
fail the !FT_HAS_GLYPH_NAMES(face) test so I am going to live with
this issue.


------------------------------------------------------------------------
r211 | airwin | 2019-01-23 16:24:48 -0800 (Wed, 23 Jan 2019) | 31 lines
Changed paths:
   M /trunk/examples/MissingGlyphExample.cpp

Modify the "Missing Glyph" example again

In this case I replaced

-      "Unicode U+1878 MONGOLIAN LETTER CHA WITH TWO DOTS: ᡸ",
+      "Embedded newlines a\\nb\\nc: a\nb\nc",

because I have verified experimentally that inserting a newline
character (and presumably any other non-printing character) in the
character string generates a missing glyph condition that results in
the replacement glyph (normally an empty box) being substituted by the
libLASi code.  So this appears to be a much more reliable way
(compared to random unicode glyphs that happen not to be available now
but which will likely become available later) in the long run to test
the response of libLASi to missing glyphs.

Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by configuring libLASi, building the all target,
running ctest, and verifying with gv that the resulting Encapsulated
PostScript file has substituted the missing glyph empty box for the
embedded newlines.

N.B. this test was done for a modified version of
examples/MissingGlyphExample.cpp where the Aries symbols were dropped.
Of course, with those symbols restored to the example as in this
commit, ctest errors out as before because of the attempt to use an
unsuitable pure bitmap font (Noto Color Emoji) to handle the Aries
glyph.  A solution to that remaining libLASi issue has been found but
it is not commit-ready yet (and it was not used for the present test).


------------------------------------------------------------------------
r210 | airwin | 2019-01-22 17:35:57 -0800 (Tue, 22 Jan 2019) | 87 lines
Changed paths:
   M /trunk/examples/MissingGlyphExample.cpp

Update "Missing Glyphs" example to provide more stringent tests of the libLASi library

One on-going testing issue with this example is Debian fonts are
constantly improving.  So in contrast to the Debian Jessie case,
Debian Testing provides all the glyphs for the previous version of
this example which therefore no longer tests libLASi's response to missing
glyphs.  So to address that issue (at least temporarily) I have added

"Unicode U+1878 MONGOLIAN LETTER CHA WITH TWO DOTS: ᡸ"

to the strings being rendered by this example.  This means this
example tests missing glyphs again for me since this glyph is missing
for the (extensive) set of Debian Testing font packages I currently
have installed.

One important libLASi defining characteristic is this library can only
use scalable outline fonts.  Until recently this has largely been only
a theoretical concern because fontconfig was typically set up to
prefer modern outline fonts over old-fashioned bitmapped fonts.
However, that all changed with the advent of the Noto Color Emoji
family of fonts which are high-quality pure *bitmapped* fonts suitable
for rendering the extraordinarily popular emojis.  Currently, for
Debian Testing at least, pango/fontconfig chooses this font over
suitable outline alternatives (likely because of that emoji
popularity), and there doesn't seem to be any way to overcome this
problem other than to remove the Noto Color Emoji font package, wait
for an outline version of that family of fonts to become available, or
(to express a really bad alternative) to configure fontconfig in one
way when using libLASi and another way when desiring emoji's for text
transmissions.

Also, pango/freetype does not appear to have any programming method to
force outline fonts to be chosen.  So going forward the plan is to
change libLASi to substitute blank glyphs for all glyphs in a
PangoItem where an error occurs (e.g., due to missing glyphs or a pure
bitmap font being chosen by pango for the PangoItem).  (Note a pango
item is associated with a sub-block of text that can be rendered with
a single font face, i.e., a group of fonts constrained to have the
same family, weight, slant, stretch and width but possibly varying
sizes).

To test this situation for the current libLASi, I have inserted in this
commit the test string

"Unicode U+2648 ARIES (twice): ♈♈"

where it turns out that pango currently selects the completely
unsuitable (from the libLASi perspective) pure bitmap font "Noto Color
Emoji" to represent those Aries symbols.  (This issue with the Aries
symbol was first discovered by PLplot comprehensive testing of the
psttf device driver which depends on libLASi.)

In addition, I have taken this opportunity to move from the "Arial"
font to the more generic "serif" font which presumably gives
fontconfig the same or even more freedom to choose the best font to
render a particular glyph.  And I have also changed all test strings
being rendered in this example to ones that describe themselves in
more detail, e.g.,

"Unicode U+0802: ࠂ"

was replaced by

"Unicode U+0802 SAMARITAN LETTER GAMAN: ࠂ"

Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by configuring LASi (using the Debian Testing system
version (3.13.2) of cmake), building the "all" target, and running
ctest --verbose.  The result for this commit of the "Missing Glyphs"
example was as follows:

[...]
test 1
    Start 1: example0

1: Test command: /home/software/lasi_svn/HEAD/build_dir/examples/example0 "example0.ps"
1: Test timeout computed to be: 9.99988e+06
1: Error returned from FT_Load_Glyph
1/3 Test #1: example0 .........................***Failed    0.08 sec
[...]

A test with the previous version of this example produces no such
errors which confirms the new version of this example is a more
stringent test of libLASi.  N.B. this ctest error will continue until
the libLASi library can be changed as discussed above.


------------------------------------------------------------------------
r209 | airwin | 2019-01-22 15:52:19 -0800 (Tue, 22 Jan 2019) | 27 lines
Changed paths:
   M /trunk/src/drawGlyph.cpp
   M /trunk/src/psDoc.cpp

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

That is change libLASi references to ft_glyph_bbox_unscaled and
ft_glyph_format_outline with FT_GLYPH_BBOX_UNSCALED and
FT_GLYPH_FORMAT_OUTLINE.

Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by configuring libLASi with the system version (3.13.2) of
cmake and building the libLASi library (with "make LASi") without
build errors.

Note the above deprecation of the lower-case form of the macro
constants was only noted by chance in documentation, and the actual
libLASi build continues to generate deprecation warnings due to other
long-standing issues.  Those issues (some of which have multiple
instances) are the following:

* "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 these deprecation warnings would be much appreciated!


------------------------------------------------------------------------
r208 | airwin | 2019-01-22 14:34:44 -0800 (Tue, 22 Jan 2019) | 77 lines
Changed paths:
   M /trunk/examples/ComplexTextLayoutExample.cpp
   M /trunk/examples/MissingGlyphExample.cpp

Add boundary boxes to the "Missing Glyph" and "Complex Text Layout" examples

This change was straightforward for the "Missing Glyph" case.

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
anamorphic scaling and rotation of text.  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.

In addition, for the "Complex Text Layout" case I reduced the font
size from 30 to 25 of the "UTHAITHANI IN THAI: อุทัยธานี" section of this
example to compensate for what appears to be a systematic increase
over the years (compared to previous screenshots of this example and
other lines of text in this example) in the font actually determined
by the Debian testing version of pango when the "Garuda" font is
specifically requested for this component.  A gucharmap experiment
with requesting this font with the Debian Testing package
fonts-tlwg-garuda-otf installed for the U+0E2D THAI CHARACTER O ANG
"อุ" indicates that "Garuda" is the font actually used in this case.
Which indicates this increase in size we are compensating for in this
commit is not an artifact of the wrong font being chosen.

Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing).  In the "Missing Glyph" case the test was a simple
one (using gv to check the boundary box of the complete eps result).
But in the "Complex Text Layout" case, I locally reduced the example
(using #if 0 ... #endif) to individual components and used the simple
gv test to test the above macros were working correctly for each of
those individual components and additional significant variations of
those components.

One such detailed test was for the red-rectangle component.  By
looking at the eps result, I confirmed the resulting high-res boundary
box was identical with the path of the red rectangle implying that
applications paying strict attention to that high-res BB would split
the width of the line.  And the low-res BB was slightly (less than one
point in all cases which is small compared to the width of the line)
outside the hig-res BB.  So a similar conclusion can be drawn for
those applications paying attention to the low-res BB.

However, note there is a small but significant boundary-box issue with
the gv PostScript viewing application.  The position indicator for the
app appears to conform to the low-res BB (i.e., it shows no position
outside that BB), but the white background supplied by that app is not
aligned properly with that BB.  For example, the lower y value for
that white background is systematically too low (by a significant
number of points corresponding roughly to the width of the line)
relative to the BB, and the upper x value is systematically too large
by a similar amount.

A further detailed test was for the case of anamorphic scaling of text
for a number of different sequential text segments.  In all cases
(subject to the above minor issues with gv), the bounding box of the
composite set of all such text segments was calculated properly.

A final detailed test was for the rotated text component where I used
sequential text rotated by various increments to prove each text
segment was continuous with the previous one and rotated properly.
Also, I confirmed for all these different rotation tests (subject to
the above minor issues with gv), that in all cases (including one that
had overall rotation angles in all quadrants) the bounding box of the
composite set of all rotated text segments was calculated properly.

Of course, after all those individual detailed component tests were
completed, I changed the "Complex Text Layout" example to the present case where each component
updates if necessary (i.e., if the component BB is larger in any dimension
than the overall boundary box calculated for previous components) the overall
bounding box.  And a simple gv test shows that entire result looks good
including an appropriate overall bounding box (subject to the
above minor issue with gv).


------------------------------------------------------------------------
r207 | airwin | 2019-01-22 11:39:08 -0800 (Tue, 22 Jan 2019) | 9 lines
Changed paths:
   M /trunk/src/psDoc.cpp

Fix minor boundary box issue

The low-resolution (integer) boundary box was being calculated by
taking the floor of all high-resolution (double) boundary box limits.
This commit changes that to the floor of the high-resolution lower
limits and the ceil of the high-resolution upper limits so that low
resolution bounding-box limits are always outside the high-resolution
limits, but with the difference always less than one point.

------------------------------------------------------------------------
r206 | airwin | 2019-01-10 18:20:41 -0800 (Thu, 10 Jan 2019) | 26 lines
Changed paths:
   M /trunk/Doxyfile.developer
   M /trunk/Doxyfile.user

Update doxygen configuration files from doxygen version 1.8.1.2 to 1.8.13

These conversions were done using

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

Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by running (from an initially empty build tree and
with the Debian Testing 3.13.2 version of CMake)

cmake -DCMAKE_INSTALL_PREFIX=/home/software/lasi_svn/install -DBUILD_SHARED_LIBS=ON ../lasi_2019 >& cmake.out
# To remove previously generated doxygen results in the source tree.
make clean >& clean.out
make all >& all.out

with no doxygen build issues other than one @param warning that the
parameter mapval does not occur in the argument list for
PostscriptDocument::accrue_dimensions.  Since mapval does appear in
this argument list, this warning can only be explained by some doxygen
C++ code-parsing failure.

In addition, I skimmed the generated results at doc/developer/html
and doc/user/html/ with firefox, and all seemed well.


------------------------------------------------------------------------
r205 | airwin | 2019-01-10 17:16:23 -0800 (Thu, 10 Jan 2019) | 24 lines
Changed paths:
   M /trunk/CMakeLists.txt

Bump (or shove hard in this case) the minimum version of CMake from 2.8.9 to 3.13.2

This change is 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.  That said, it is a tribute to
the robustness of the current libLASi build system and the backwards
compatibility of CMake that there were absolutely no build-system
warnings either before or after this change.

Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by running (from an initially empty build tree and
with the Debian Testing 3.13.2 version of CMake)

cmake -DCMAKE_INSTALL_PREFIX=/home/software/lasi_svn/install -DBUILD_SHARED_LIBS=ON ../lasi_2019 >& cmake.out
make
ctest

with no issues other than outdated Doxygen configuration files (which
will be the subject of the next commit).





------------------------------------------------------------------------
r204 | airwin | 2015-05-20 18:14:08 -0700 (Wed, 20 May 2015) | 45 lines
Changed paths:
   M /trunk/src/CMakeLists.txt

Build system: set target property POSITION_INDEPENDENT_CODE ON for the libLASi library

This change allows shared libraries from foreign software (e.g.,
PLplot) to link to the static version of libLASi. The cost of this
gain is there is a small amount of inefficiency (e.g., the more
complicated addressing code that apparently occurs on Linux for all
code compiled with the -fPIC flag) introduced for the static libLASi
library.

Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
using the following procedure (which is normally used for testing
changes to libLASi):

cd /home/software/lasi_svn/HEAD/build_dir
# Remove build tree and install tree
rm -rf /home/software/lasi_svn/HEAD/build_dir/* /home/software/lasi_svn/install

# Configure libLASi build, test, and install
# (Note change from normal procedure where we have specified building
# a static version of libLASi.)
cmake -DCMAKE_INSTALL_PREFIX=/home/software/lasi_svn/install \
-DBUILD_SHARED_LIBS=OFF ../lasi_allura >& cmake.out

# Check results
less cmake.out

# Build and install
make -j4 install >& install.out

# Check results
less install.out

# Test
ctest

I then followed up with a comprehensive test of PLplot where this
static libLasi library was fine for the shared library case for that
build (both with and without dynamic devices).  However, under these
conditions the traditional PLplot static build had some (missing
stdlib++) difficulties with the mixed Fortran, C++, and C case.  This
is expected and unfortunately there is no easy cure.  Therefore some
static/traditional testing limits are in train to avoid this case for
future testing.


------------------------------------------------------------------------
r203 | airwin | 2014-07-26 15:31:57 -0700 (Sat, 26 Jul 2014) | 2 lines
Changed paths:
   M /trunk/CONCATENATED_README.release

Prepend the release notes for 1.1.2.

------------------------------------------------------------------------
r202 | airwin | 2014-07-26 15:31:31 -0700 (Sat, 26 Jul 2014) | 2 lines
Changed paths:
   M /trunk/README.Release_Manager_Cookbook

Update instructions to exactly what occurred for the 1.1.2 release.

------------------------------------------------------------------------
r200 | airwin | 2014-07-26 13:54:34 -0700 (Sat, 26 Jul 2014) | 2 lines
Changed paths:
   M /trunk/ChangeLog.release

Update commit messages for 1.1.2 release cycle.

------------------------------------------------------------------------