Bug 9978 should have fixed them all, but some were missing.
We want all the license statements part of Koha to be identical, and
using the GPLv3 statement.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Attempting to create a patron card layout with mysql strict mode on gives the following error:
DBD::mysql::st execute failed: Incorrect integer value: '' for column 'layout_id' at row 1
Test plan:
- Turn on sql_strict_modes
- Create a new patron card
=> Must success with this patch applied
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Mainly a
perl -p -i -e 's/^.*3.07.00.049.*\n//' **/*.pm
Then some adjustements
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch removes 2 types of warnings when
creating Labels
a) Using '0' as filling char is not to the like of prStrWidth
On C4/Creators/Layout.pm
b) A RM followup from Galen on Bug 8375 to C4/Creators/PDF.pm
makes impossible to find properly a font :(
(http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=f7ef93e758850e991091e7268b8d1b1453082df4)
on C4/Labels/Label.pm
To test:
Pre patch
1) Go to Tools > Labels
2) Create a new layout, name ABC, type 'Barcode/Biblio'
3) Create a new batch, add 2 items
4) Export as PDF using the new layout
5) Look at logs, you will find something like
a) label-create-pdf.pl: Use of uninitialized value $strwidth in numeric lt (<) at /home/bgkriegel/kohaclone/C4/Creators/Layout.pm line 233., referer: http://staffdev.koha-community.org.ar/cgi-bin/koha/labels/label-print.pl
(Only one of this kind)
b) Two related lines similar to this examples
label-create-pdf.pl: Use of uninitialized value in -e at /home/bgkriegel/kohaclone/C4/Creators/PDF.pm line 226., referer: http://staffdev.koha-community.org.ar/cgi-bin/koha/labels/label-print.pl
label-create-pdf.pl: ERROR in koha-conf.xml -- missing <font type="Ft1">/path/to/font.ttf</font> at /home/bgkriegel/kohaclone/C4/Creators/PDF.pm line 229., referer: http://staffdev.koha-community.org.ar/cgi-bin/koha/labels/label-print.pl
(many many lines x number of items on batch)
6) Apply the patch
7) Export the same PDF, no more warnings
8) Bonus 1: change main font to Courier and Helvetica
and check results
9) Bonus 2: check using arabic records
Many hours to find :(
Easy to fix
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a checkbox on Label creator
to use or not an oblique variant of main font
for title
Also fix font selection for title in case an
oblique variant is used.
To test:
Before patch
1) Go to Tools > Label creator
2) Create a new layout, default values but select
any 'Oblique' variant for main font and
'Biblio/Barcode' for layout type
3) Go to Manage batches, create a batch, add items,
export PDF, download
4) Check logs, you must find a line with
'ERROR in koha-conf.xml -- missing <font type="COO">'
for example if main font Courier-Oblique
5) Open PDF, title could be right but not using selected font
After patch
6) Apply the patch
7) Run updatedatabase.pl
8) Repeat 1-2, note new checkbox 'Oblique title',
default checked
9) Repeat export, no new warnings on log
10) Create a new layout or edit an existent one,
uncheck 'Oblique title', save, export again
Check PDF has non slanted title
Followed test plan, works as expected. (See comment #11).
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Most of them were found and fixed using codespell.
Fix also some related grammar issues.
In C4/Serials.pm a variable was renamed to make future codespelling
checks easier.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
http://bugs.koha-community.org/show_bug.cgi?id=14383
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Fixes problem with creating new labels - before it populated with callnumber and not itemcallnumber
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
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>
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>
