Since these constants are bitfield flags, we define some methods to make
working with them reasonably type safe.
Move the definitions to outdevstate.hxx, since we need the values there,
and that appears to be the "root most" header file.
Also dump TEXT_LAYOUT_BIDI_LTR constant, since it means the same thing
as TEXT_LAYOUT_DEFAULT (ie. 0), and leaving it in causes people to write
weird code thinking that it's a real flag.
Change-Id: Iddab86cd6c78181ceb8caa48e77e1f5a8e526343
Reviewed-on: https://gerrit.libreoffice.org/10676
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Removed its output paramater as GetCurrentViewShell should be
used instead and added a const version.
Change-Id: Iad8b57553b6e93e3472ce8c6905d08e8d49af770
Into the new class DocumentFieldsManager.
Removed SwDoc::_MakeFldList because it is not defined anywhere.
Also moved a few non interface methods that belong to the manager.
Change-Id: Icefd7ca7adcbb05a18d6fae0529fc54150b862fd
Into the new class DocumentRedlineManager.
Added an non const version of GetRedlineTbl to the interface.
Also Moved SetAutoFmtRedlineComment which is not part of interface.
Change-Id: I600d5821d5d5831557f5fc5375fb1203fe67a295
There is a special SwFieldMarkPortion sub-class that is supposed to be
created for these, which overrides Paint() to do nothing; unfortunately
at least for the CH_TXT_ATR_FIELDSTART at beginning of a paragraph
a plain SwTxtPortion is created, because the check of rInf.Len() is
checking the length of the _previous_ text portion; the call to
rInf.SetLen() only happens after creation, in last line of
SwTxtFormatter::NewTxtPortion().
This problem affects RTF and DOCX files since commit
c6b99eedda03461202f9bf012a422dfd81da72ec.
Change-Id: I447b21e841d22558d689f0f244d811c32e4923ec
This fixes the reported problem (that the pilcrow stopped showning for
centered paragraphs), and additionally makes the pilcrow large for large
paragraphs (like titles) again.
Change-Id: I78d9986c0da6abfb9936984bb8b72d5eba88c9d7
most of length in vcl are calculated in 'long'
but array of X position tend to be in sal_Int32.
As a prep work to be able to support 'double'
as the base type of Device Coordinate, harmonize
the use of 'long' for non-float coordinate.
Change-Id: I7cb33301ff6a5e2c62247b36a4e07e168a58a323
Find "missing headers," where a function is declared directly in the
.cxx (as extern) and not defined, and should arguably instead be declared
in an include file.
Change-Id: I6d83ee432b2ab0cd050aec2b27c3658d32ac02a2
Find places where we are returning a pointer to something, where we can
be returning a reference.
e.g.
class A {
struct X x;
public X* getX() { return &x; }
}
which can be:
public X& getX() { return x; }
Change-Id: I796fd23fd36a18aedf6e36bc28f8fab4f518c6c7
Because it is not needed there anymore in that class.
I added it as an include in all files that need it.
Change-Id: I3eb2e1da9d153017968b286e1a0250f145ca7cfe
In case of inline shapes, it's not possible to just copy the AnchorType
property of the shape to the textbox, as we want the textbox at the
expected position, not inline. OTOH, an inline shape has an implicit
position, so we can't position its textbox at import-time.
Solve the problem by setting the position of the textbox as we create
the layout of the inline shape.
Change-Id: I425ff5e0760858ebcbe457ed0ce9e4977ae8bc74
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>
Invalid read of size 1
at SwParaPortion::SetPrep(bool) (porlay.hxx:299)
by SwTxtFrm::Prepare(PrepareHint, void const*, bool) (txtfrm.cxx:1756)
by SwTxtFrm::Prepare(PrepareHint, void const*, bool) (txtfrm.cxx:1663)
by SwCntntFrm::MakeAll() (calcmove.cxx:1310)
by SwFrm::OptPrepareMake() (calcmove.cxx:356)
by SwFrm::OptCalc() const (frame.hxx:1037)
by SwLayAction::_FormatCntnt(SwCntntFrm const*, SwPageFrm const*) (layact.cxx:1829)
by SwLayAction::FormatCntnt(SwPageFrm const*) (layact.cxx:1660)
by SwLayAction::InternalAction() (layact.cxx:597)
by SwLayAction::Action() (layact.cxx:376)
by SwLayIdle::SwLayIdle(SwRootFrm*, SwViewImp*) (layact.cxx:2179)
Address 0x1f9507e0 is 832 bytes inside a block of size 840 free'd
by FixedMemPool::Free(void*) (mempool.cxx:48)
by SwParaPortion::operator delete(void*, unsigned long) (in /work/lo/master/instdir/program/libswlo.so)
by SwParaPortion::~SwParaPortion() (porlay.cxx:1972)
by SwTxtFrm::ClearPara() (txtcache.cxx:102)
by SwTxtFrm::Init() (txtfrm.cxx:329)
by SwTxtFrm::CalcLineSpace() (txtfrm.cxx:746)
by SwTxtFrm::Prepare(PrepareHint, void const*, bool) (txtfrm.cxx:1680)
by SwTxtFrm::Prepare(PrepareHint, void const*, bool) (txtfrm.cxx:1663)
by SwCntntFrm::MakeAll() (calcmove.cxx:1310)
by SwFrm::OptPrepareMake() (calcmove.cxx:356)
by SwFrm::OptCalc() const (frame.hxx:1037)
by SwLayAction::_FormatCntnt(SwCntntFrm const*, SwPageFrm const*) (layact.cxx:1829)
by SwLayAction::FormatCntnt(SwPageFrm const*) (layact.cxx:1660)
by SwLayAction::InternalAction() (layact.cxx:597)
by SwLayAction::Action() (layact.cxx:376)
by SwLayIdle::SwLayIdle(SwRootFrm*, SwViewImp*) (layact.cxx:2179)
Change-Id: I64a1cc6ea301b653af951ba0e00e28d4655d2d97
the page has been scaled by 75% and vertically centered so the page positions
need to be also adjusted.
Change-Id: I7ab6b4956933ba444441c857e78aee8e5c1cf97a
The old condition was: set the right edge of the repaint rectangle, in
case the result would be wider than the original (if we repaint more,
that can't hurt regarding the end result) or in case the left edge was
set.
But that's problematic, the reproducer situation described in the bug
triggers a case when the right edge is shrunk too much, so part of the
painted letter is missing.
Fix that by only setting the right edge of the repaint rectangle when we
know that it won't shrink.
Change-Id: I33b78a929021b284d5283fc2c35e0b3c999fa224
At least it seems that after setting the offset to the largest possible
value (instead of COMPLETE_STRING), things get back to normal.
Change-Id: I25fafd277eaf480f9ae232254ced3946589aa562
