Signed-off-by: Stephan Bergmann <sbergman@redhat.com>,
changed from a macro- to a template-based solution. (Unfortunately MSVC 2012
does not support explicit conversion operators. Worked around that with
explicit #ifs rather than some HAVE_EXPLICIT_CONVERSION_OPERATORS and
SAL_EXPLICIT_CONVERSION_OPERATOR ainticipating we hopefully soon move to a
baseline that requires unconditional support for them.)
Change-Id: I4a89643b218d247e8e4a861faba458ec6dfe1396
* Added rational util functions used by Fraction class not
available in the boost::rational class.
* Replaced usage of Fraction by boost::rational<long>
* Removed code that relies on:
1. fraction.IsValid() -- rational only allow valid values, ie
denominator() != 0
2. rational.denominator() == 0 -- always false
3. rational.denominator() < 0 -- always false but implementation
detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation
* Simplified code that relies on:
1. rational.denominator() != 0 -- always true
* BUGS EXIST because Fraction allows the creation of invalid values but
boost::rational throws the exception boost::bad_rational
Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9
Reviewed-on: https://gerrit.libreoffice.org/11551
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
...and also corresponding param of CreateTabPage function type and corresponding
Craete functions. There were some call sites that passed undefined "null
pointer references" and SfxTabPage internally uses a pointer member pSet that is
checked for null anyway.
Change-Id: I4eb3636155eac46c9c9d26e6e6e842e85d7e95af
A simplified version of the semantic match that finds this problem is
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r1@
statement S;
position p,p1;
@@
S@p1;@p
@script:python r2@
p << r1.p;
p1 << r1.p1;
@@
if p[0].line != p1[0].line_end:
cocci.include_match(False)
@@
position r1.p;
@@
-;@p
// </smpl>
Change-Id: Ib9708d37fbb4c6060f88d5dae3814a2d37b2091e
Reviewed-on: https://gerrit.libreoffice.org/9493
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
Firstly, IsFormat is unused so there's no "escape" of
bFmt back into the outside world.
Then bFmt has two purposes.
Purpose 1 is 'not be a format dialog, be a format dialog, be a format dialog but hide standard button'
so, lets just add an explicit "Hide standard button" method and call
it in the (apparently) one place where it's necessary.
Purpose 2 is to flag that "BaseFmtHdl" was called from clicking
the "Standard" button at which point its set to 2.
SfxTabDialog::Init_Impl had...
"
// bFmt = temporary Flag passed on in the Constructor(),
// if bFmt == 2, then also sal_True,
// additional suppression of the standard button,
// after the Initializing set to sal_True again
if ( bFmtFlag != 2 )
m_pBaseFmtBtn->Show();
else
bFmtFlag = sal_True;
"
but the variable acted on is bFmtFlag a copy of bFmt, and is never read again
after that line, so setting it to sal_True is meaningless. The comment suggests
that the intent is to reset bFmt to true if it was 2 during initialization,
which fits with the later use of bFmt == 2 to indicate that the standard button was
clicked, i.e. reset bFmt back to its standard value.
So make bFmt a simple toggle of dialog as a format dialog or not, add a way
to remove the standard button and add a second variable to indicate the standard
button got pressed.
Change-Id: I98a441f5f314845abe243e05b6d92fd71d7b0b04
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
PDF Files can quickly become very big when a user inserts some images. Most users don't know how to reduce the size of their images.
This patch enables the resolution reduction for PDF Export to 300DPI by default.
Change-Id: I3ce5191de35561b59169e52e2e2efbc4a343f025
Reviewed-on: https://gerrit.libreoffice.org/8422
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Added vcl/settings.hxx to all cxx files which require it.
This helps to speed up compilation after changes to the settings.
Conflicts:
sc/source/ui/dbgui/pvlaydlg.cxx
Change-Id: I211a0735c47f72d6879f6f15339355abfe0e3cf4
Reviewed-on: https://gerrit.libreoffice.org/7933
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
.. to more explicit SvStream::Write* calls
This was done using another run of the clang rewriter, and then
a lot of hand tweaking to fix all the places where the rewriter
did not play nice with various macros.
Change-Id: I7bcab93851c8dfb59cde6bc76290c6484d88fb18
Reviewed-on: https://gerrit.libreoffice.org/7494
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
This change fixes two bugs:
1) In it's old location at PDFFilter::implExport, the pdf viewer is called
*before* the final file is actually written. It causes a problem under
Windows, because we use ShellExecute function which fails if the file
doesn't exist. Calling a function blocks execution, so we have no chance
to write the file before that function fails. (fdo#68099)
2) Being a part of the saving/filter code means that the pdf viewer will
open even when converting to a pdf in headless mode. It's definitely not
something that we want to happen.
Change-Id: I1a6f70ec76100ac9e008869aa57ad738ced3ab6c
Reviewed-on: https://gerrit.libreoffice.org/6565
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Ealier version of PDF standard allowed for not embedding the so called
standard PostScript fonts in the PDF files and all PDF readers had to
include them or a "suitable substitute". This behaviour had many issues
and is deprecated for 10 years now. The current version of PDF spec
says:
Beginning with PDF 1.5, the special treatment given to the standard 14
fonts is deprecated. Conforming writers should represent all fonts
using a complete font descriptor. For backwards capability, conforming
readers shall still provide the special treatment identified for the
standard 14 fonts.
This commits removes support for not embedding these fonts, and the, now
redundant, option to embed them.
This has the side effect of elimanating the cause of fdo#66108 and
fdo#41547.
Change-Id: I4f1fc4137a2de7baeef9e504f2e4f84fbec0a491
Reviewed-on: https://gerrit.libreoffice.org/4495
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
