Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This patch provides a very partial fix for this bug in that it reduces
the number of pdf generation failures due to a "wide character" error.
It does not ensure that all unicode characters will print correctly as
this is dependent upon many other issues mentioned in this bug and
various posts to the developer list.
What this code does is test to see if the pdf stream is utf8 encoded
and if it is, explicitly declares it to be so. Unicode chars will still
print incorrectly, but the pdf will be created and should open properly
in whatever pdf reader.
You may test this by adding any character with a diacritical to the
title of a bib and then attempting to generate a label pdf with the
title of that bib. Before the patch is applied the resulting pdf
should contain an error mentioning a wide character issue. After the
patch is applied, the pdf should be valid.
No documentation changes are necessary as a result of this patch.
This patch should be backported to 3.2.x.
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
working through the master branch to eliminate all
podchecker warnings/errors
Actual improvement to the quality of the POD will
come later (hopefully with assistance of others)
Signed-off-by: Andrew Elwell <Andrew.Elwell@gmail.com>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
The apparent fix is to have the text wrap alogrithm to calculate based
on a label width reduced by approx. 3/16" when there is no left text margin.
This is probably not the proper fix as it appears that this algorithm is being
affected by adjustments in the label width for label creep and perhaps offset
as well. But this does fix the symptom and is all the time available for this
problem at present.
Documentation Changes:
It might be good to add a note to the effect that if the user does not supply
a left text margin in the layout, a 3/16" (13.5 point) left text margin will
apply by default.
This reverts commit 1f56a04cad.
[RM note: I confirm Chris Nighswonger's testing that shows that
the patch causes regressions, including breaking creating new
label layouts.]
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
A lot of routines were defaulting to return -1 in error conditions
but calling code was expecting a ref or object
use return with explicit undef (or emptyness in array context)
for these cases. Extended this to cases where return was not tested
( -1 might in some cases be legit data).
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
(cherry picked from commit 5cf2b78b6f)
[RM note: ... thereby undoing the revert]
A lot of routines were defaulting to return -1 in error conditions
but calling code was expecting a ref or object
use return with explicit undef (or emptyness in array context)
for these cases. Extended this to cases where return was not tested
( -1 might in some cases be legit data).
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Pagination code was commented out during development causing the
spill over page one to be wrapped back onto page one. This patch
fixes that problem.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
