Age | Commit message (Collapse) | Author |
|
Change-Id: Ie20a8931a16f6609ac5be23032a0b2e3a7ad1784
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95627
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
(at least not in general)
Change-Id: I71337b53dc9735e90a37ee532d0a8a08797b518c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106043
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
unused since 9fb7aaf570c03c8a26d763f1205fb8c890e8211a "Make linked graphic
register into LinkedManager again", and remove further function parameters and
class members that turn out to be unused now, too
Change-Id: I3dd2b138fd8787d12b89547526da751ea5954845
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106041
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
asserts since...
commit bf4bbc3c2174b21577b8878bc3197923ba44a029
Date: Thu Nov 12 15:38:13 2020 +0200
replace std::max(std::min()) with std::clamp
but looks wrong since...
commit ff916ccce1527b63aad17bbae0ad02a834cd31d6
Date: Tue Sep 30 13:51:36 2008 +0000
CWS-TOOLING: integrate CWS dr63
- mnScrollMax = limit_cast< sal_Int16 >( nApiValue, mnScrollMin, EXC_OBJ_SBS_MAXSCROLL );
+ mnScrollMax = limit_cast< sal_uInt16 >( nApiValue, mnScrollMin, EXC_OBJ_SCROLLBAR_MIN );
Change-Id: I002c764ed7129b1a66a7c827422b9d64034c6e53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106012
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
So this is a regression-inviting guess at a wrong impl.
And I am not a calc guy, so I shouldn't be making this
kind of a change.
The problem was that editingActive couldn't select
cells from other sheets for some cells near the
frozen border. The reason was that multiple splits
are considered active at the same time, and so the
editActive can be monkeyed with. Everything is all
so interconnected that I get rather confused.
This fix does not solve a same problem with a
true window split, only with a window freeze.
The freeze problem is that the left column was
looking at the column (outside its view) and asked
whether it fit inside the start X (0)
+ visible cells +1.
So pretending typical freeze of row 0 and col 0,
which means left starts at 0 and has 1 visible col.
Left activates if col is 0, or 1, or 2.
Since the only possible column in left is 0,
it should only activate in that case.
So visible cells should be --, not ++.
Right? Of course, something probably depends on
the editing view being turned on for partially
visible cells on the right or bottom side,
or perhaps even for the first invisible col/row,
and so this will probably cause a regression.
An alternative would be to -- for the left side
and ++ for the right side (to increase confusion,
but decrease regression potential).
Change-Id: I946512bc7b3994f1750527a1a8c55954234b0d69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105429
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Improve FillAnalyse, FillSeries to continue linear sequences
of mixed values in merged cells (mixed values are string + number,
like 'a1','a2' or '1a').
It discovers the linear sequence only if the string parts are
identical. It recognizes user lists only if all elements are in
the same user list.
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: I8810a0f1d637436222e3d0b9219da38ccb7c6346
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105784
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
for example selecting two cells with the same
text content "A1", and autofilling them must result
"A1", "A1"... instead of "A2", "A2", "A3", A3"...
Remove an obsolete fix in FillAnalyse(). As 0
increment is handled by both user list and mixed
sequence cases, there is no need to pre-check that
the elements are the same.
Now FillAnalyse will return with the proper FILL_LINEAR
(or user list) instead of FILL_SIMPLE that caused the
unnecessary +1 increment.
See commit d64bd977a430182826252695f041a6ddd62e45ef
(tdf#137653 tdf#137624 sc: fix autofill user list sequence)
and commit 5af699cf62b2313980add377a777c49dc1e7ae2a
(don't deduce increment from multiple equal list entries).
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: I0750816375486b5b95fb2e0fcfdb9b1d6c8ce7d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105791
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ia573921566ec6079b843cbcc0401d9d0f5c62089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105969
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
not just functions
Change-Id: Icca295dd159002b428b73f2c95d40725434f04d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105789
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...more likely to pick an appropriate version for the involved integer types,
esp. after the recent long -> tools::Long changes
Change-Id: Ia91259ca35aaf74b0e907de6831fc926f30057f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Motivated by https://bugs.documentfoundation.org/show_bug.cgi?id=122419#c21
Change-Id: I2086ed604c50b513019c7023ad4c01df9c5edb4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105925
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I76e34e8020d98292e8ffde387542b7029f85a42d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105754
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id679b4a2e7a290780142daae39d28a429fb3b11d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105765
Tested-by: Jenkins
Reviewed-by: Kevin Suo <suokunlong@126.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I890d19f5e2177294dc1175c90c98b964347f9e85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105751
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
for a in `git ls-files '*.ui'`; do sed -i 's/^\( *\)\(<object class="GtkGrid".*\)/\1<!-- n-columns=1 n-rows=1 -->\n\1\2/' $a; done
so we get the same behavior in glade as before 3.38 in that the grid preview
don't show any unoccupied grid squares
replace all existing n-columns=X n-rows=Y lines because they are
all wrong, except for
cui/uiconfig/ui/additionsfragment.ui
sw/uiconfig/swriter/ui/pageheaderpanel.ui
sw/uiconfig/swriter/ui/pagefooterpanel.ui
which are correct.
Change-Id: I401bbe8e098c26e7f57d6a872d3b70fc1ce85a00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105846
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
During the save process of a document, save code names of calc sheets
regardless of the VBA compatibility mode. Loading of documents with
changed code names already work without checking the VBA mode.
Change-Id: Ieb5297ac3b671fd39a200c34409ba2ffdad4e1f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103589
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This is an addition to commit 1f0b3c7a40edfa81bbc7a58d123a6a2dfd83e4ca
The following scenario had produced a wrong object size: The object is
anchored to cell. Some columns containing this cell were hidden and
then shown again.
ScDrawLayer::SetCellAnchoredFromPosition was called in this case and
had produced the wrong size. When the column of the object anchor is
shown, object becomes visible. This gives an 'object change' event,
sent to ScDrawView::Notify, which calls adjustAnchoredPosition. That
had a test pAnchor->getShapeRect() == pObj->GetSnapRect() that should
prevent calling SetCellAnchoredFromPosition. But exact equality fails
due to +-1 differencies because of Twips<->Hmm conversions.
Change-Id: I0bd3684b7a5eda62b578275c02a5ac839ce58e2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105802
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I55d0157436df09d5f28afb92819f996eff2e71db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105835
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I931ae2d4b2a26f5369c78b4f91ecd53a1b1fd4bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105464
Tested-by: Jenkins
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
|
|
following:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=95b27dd2e5b5bdcb39962f72882dcdf406bcb393
author Jim Raykowski <raykowj@gmail.com> 2020-10-11 16:15:47 -0800
committer Jim Raykowski <raykowj@gmail.com> 2020-11-13 17:53:20 +0100
commit 95b27dd2e5b5bdcb39962f72882dcdf406bcb393 (patch)
tree 84c49a7daadf1ce908a9f5608d40494af164917d
parent d40f2d02df26e216f367b5da3f9546b73f250469 (diff)
tdf#45705 rework zoom in and zoom out UI commands in Calc
Similar to commit 2cddaa6e199ed8bb6185b7825791199f9da4a670 done for
Writer view shell, this patch makes zoom in and zoom out commands
functional for Calc view shell in addition to the preview shell.
Change-Id: I1128d0990829015e21e352c2084a44849a37a7f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105806
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8c15b0ee8400c3b540154bc38c51cbf04b6c3850
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105794
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Similar to commit 2cddaa6e199ed8bb6185b7825791199f9da4a670 done for
Writer view shell, this patch makes zoom in and zoom out commands
functional for Calc view shell in addition to the preview shell.
Change-Id: Ibf1fd92e79c82cdea91d0d01491ac25577df54fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104196
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
Before the first time SetMapMode is changed, because that triggers a
redraw of the cursor using the new mapmode and so it appears in the
wrong place. We are going to turn off the cursor anyway, so do that
earlier.
Change-Id: Ib28a2af446436c6ebe450f0b5d1b3820ec7f479e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105757
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I297d43c594c5d8c3378e8b7f29ad798e89e4ebaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105776
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I404b0edb31fb4eb797baf814136b00fd605724eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105775
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...to "Find functions that take rtl::O[U]String parameters that can be
generalized to take std::[u16]string_view instead." (Which in turn can avoid
costly O[U]String constructions, see e.g. loplugin:stringview and subView.)
Some of those functions' call sites, passing plain char string literals, needed
to be adapted when converting them.
Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts commit 48b667a7e7d25f835f95df89162a7849d6972531.
Reason for revert: some discussion required
Change-Id: Ia0990d280837fb68b7ddc9f472ec78b1467b4311
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105540
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The 'normal' anchor (as on screen) is connected to the snap rectangle,
the NoRotatedAnchor is connected to the logic rectangle. They differ,
if the shape is transformed, e.g. rotated. Error was, that values of
the 'normal' anchor were applied to NoRotatedAnchor instead of
calculating the shift of NoRotatedAnchor independently. The error
becomes only visible on save, because there the NoRotatedAnchor is
used. Effected shape types are legacy shapes, text boxes and
transformable OLEs.
I have not tested, whether this fix would work for LO 7.0 too.
Change-Id: I8ad22ca54bdd49861a16a34736860a9871d8eba0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105611
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
which was added in
commit 331e2e5ed3bf4e0b2c1fab3b7bca836170317827
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Thu Sep 14 08:49:52 2017 +0200
long->sal_Int32 in Fraction
presumably to make the change impact less code.
Instead, update the call sites to reflect the actual bitwidth
of the data we will be receiving.
Change-Id: If2a678b1cf534f39cb8cb249757462be53658309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105607
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found by grepping and changed by hand.
Change-Id: I3c720859dba430fde3abc76c6c5cb58269efaf4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105512
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ice850a7929c5b88ca0c4da52504aa959aacd1024
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105548
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Bjoern Kirchhoff <Bjoern.Kirchhoff@escriba.de>
|
|
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
in favour of the more widely used, and better optimised, operator+
Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Error: A vertical flipped shape lost flip on loading. The error slipped
in, when I have implemented the suggestions from Jan-Marek. The object
is vertical flipped, to have no flip for calculating the full sized
logical rectangle. Therefore the second call to method
lcl_NeedsMirrorYCorrection gives wrong result 'false'. I need to
remember the result of the first call.
Change-Id: Ia411fe7108be9fdcbbf748ee9de9f443e55d6ed0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105570
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I044a11bd5690b063bf3bb346bf0e324c1353d478
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105561
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
because that's what we currently do in practice
Change-Id: Ib1154a4a7597dbabb20b1cb7b051995a72256e62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105563
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8825bed89c50dcb0a9858d04a1697cb12fdd81bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105556
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I9990be302a2d28e6e46f8bb33cda605ba15533f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105552
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
older ms specs confused JIS and ISO "B" sizes and there
are now documented newer sizes not in filter.
some of the sizes at
https://docs.microsoft.com/en-us/windows/win32/intl/paper-sizes
are surely still wrong, e.g. Letter extra paper and I trust the
values in calc table more.
orientation of ISO B6 Envelope dimensions is still ambiguous to me, so
left that alone for now
Change-Id: I6b6beb2620fe79f03ad5068eab0657a0b65f1aa4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105521
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I98dc177494fddc4a975479e99aba7b6318051b1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103618
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104202
Tested-by: Jenkins
|
|
in Groupedbar user interface, to be consistent with style names as well
as menu items in other UI modes
Change-Id: I0ac7f512af4fa7d9d771fe8dd553d42eb4cd5ea7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105465
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
The object geometry in ODF file format has values so as if no hidden
columns or rows exists. But for rendering the object geometry has to
treat hidden rows and columns as zero. This patch changes the object
geometry temporarily to the 'no hidden columns and rows' mode for
export and restores the original geometry afterwards.
The patch considers hidden columns left from the shape and hidden rows
above the shape. So the object is shifted. Considering hidden columns
or rows in the area, which is covered by the shape, is still missing.
That would possibly require scaling.
Change-Id: Icdb3f08404ca4d212d25a1967bfdc0bfc7186007
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105427
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Unrecognized A6 paper format was converted to the
default A4/Letter previously, see Paper Format
in Format->Page...
Co-authored-by: Balázs Regényi
Change-Id: If2ea0c4137177aa8be66cb11d4732b14cbc14455
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105392
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I7ba612d8880833057269290212bcd9d864bb7395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105399
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
with unique values so that, e.g.
if (pObj->GetObjIdentifier() == OBJ_LINE)
is only true if pObj is a SdrPathObj and not a E3dScene
Change-Id: I30c91e57eb27141390c644dec42e2a4bee96edf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105374
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
a) make m_nFormSfxId simply follow the slotid, like its sibling m_nDrawSfxId
b) move the previously selected form object into a variable of its own
as m_eFormObjKind instead of ~abusing m_nFormSfxId to do that
c) pass which form object a ConstFormControl creates as an explicit ctor arg
instead of providing that information by overwriting the slotid that
its ::Activate gets passed
making it follow the equivalent calc pattern and separating these very
different slot ids and object identifiers
In testing, with the form controls toolbar, clicking on a toolbaritem
toggles it on, and drawing in writer gives the expected control via
ConstFormControl ctor, and clicking the same toolbaritem toggles it off
hitting the expected SID_FM_LEAVE_CREATE case.
Change-Id: I514f6adc38f706c82f0268abf5c5e73cef5b902c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105405
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7e259043ad493d7e9c4ca34d64a4ca1ed1cf8db5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105391
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
When we are marked invalid data using Tools->Detective->
Mark Invalid Data, only top left cell of the merged cells
is circled instead of all the merged range.
Note: ScDrawLayer::RecalcPos change is for resizing the
circled merged cell.
Co-authored-by: Regina Henschel
Change-Id: Ia03c506c92ec6e1c81ef3039c20e8e7ba9e9181d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105241
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|