summaryrefslogtreecommitdiff
path: root/editeng/qa
AgeCommit message (Collapse)AuthorFilesLines
2012-07-31Invalidate current position in LookupTree at remove action.Tomaž Vajngerl1-6/+6
Change-Id: I7a32e8d7c21c1e87e1acab9020f9ecbb7e441f2c
2012-07-30LookupTree for fast autocompletion lookups (by Nico Weyand).Tomaž Vajngerl1-0/+225
LookupTree is a tree structure for fast autocompletion lookups. Additionally the tree structure stores word probabilities, so each autocompletion request returns a result with highest probability. LatinLookupTree is an implementation which was designed to be even faster and more efficient latin text, however it works with any kind of unicode strings. The tree structure was coded by Nico Weyand, Unicode strings support and conversion to Libreoffice code structure was done by me. Change-Id: I6549ee45d0952407b8a070f30ed0598fcb420aa7
2012-07-04refactor handling of double border widths:Michael Stahl1-4/+31
Word uses a completely different definition of "width" of a double border than OOo and ODF: for Word the width is apparently the largest of the 3 component widths, while OOo and ODF define the width as the total with of all 3 components. The new border implementation in LO 3.4 was apparently inspired by Word's double border definition, which resulted in various import filter regressions, see the previous fixes: 36e43b52992735c622833e923faa63774b9e2f76 e2ffb71305c5f085eec6d396651c76d6daee3406 70a6a4d425558340bb49507975343a3e0a1bdde8 These fixes set the ScaleMetrics, which actually seems sub-optimal as there is a ScaleItemSet function somewhere that apparently re-scales all items in an itemset, which could undo the fixes. Also, one of the fixes actually managed to break RTF/DOCX import of double borders, as that ended up in the same code via the API. This commit now reverses the change, so that the width of a border is now always the total with of all components, which is (imho) much more intutitive, and also leads to a consistent UI where selecting say 3pt width has predictable results, no matter what the border style. The border widths are now converted in the Word format import/export filters (writerfilter and sw/source/filter/ww8), and various tests were adapted to the new handling. Change-Id: I50456c49b1a298569607e6c88f19f18441348ac3
2012-07-04replace enum SvxBorderStyle with css::table::BorderLineSyleMichael Stahl1-8/+10
Change-Id: I1dadb53f46b23f92d34061ef78dda872bdbcda67
2012-06-27targetted re-work of cppunit pieces.Michael Meeks2-6/+1
2012-06-25rename SvxBorderLine::SetStyle to something unambiguousMichael Stahl1-6/+6
Change-Id: Iec70985319a64cdc3630e15499ac304a7f1aabae
2012-05-14Renamed FILE to DOCINFO_TITLE, which is more appropriate for this field.Kohei Yoshida1-1/+1
Change-Id: I1267629da8b66fc21c4ae2e78634c2093274aa61
2012-05-11Unit test for UNO field item implementation.Kohei Yoshida1-0/+139
Make sure the type IDs are associated with correct service names. Change-Id: I5ff8ec7fb56f2790f9a3eca8e019c784cb27de43
2012-04-13setup/teardown default component context once before/after all testsCaolán McNamara1-1/+1
avoids the problems of dangling uno singletons invalidated after the first dispose and the chain of other singletons that don't expect to need to re-initialize, etc. reenable editeng cppunit test inherit i18npool cppunit test from unotest base drop LibreOfficeProtector, do "throwable" work in setUp/tearDown not in ctors/dtors
2012-04-12partially revert the editeng singleton stuff to get build to completeCaolán McNamara1-1/+1
2012-04-12Handle the correct deletion order of EditDLL in the base class.Kohei Yoshida1-2/+0
Turns out that this change affected all cppunit runs.
2012-04-11Remove the TODO comment that's no longer relevant.Kohei Yoshida1-1/+0
2012-04-11We need to delete EditDLL before de-initialize vcl to avoid crash.Kohei Yoshida1-2/+3
Without manually releasing the EditDLL singleton instance, it gets deleted *after* the cppunit does its cleanup, which de-initializes VCL. The problem is, when the EditDLL instance is destroyed, its member GlobalEditData instance deletes the OutputDevice instance that it owns, which in turn accesses font caches in VCL. But by the time we reach that point, VCL is already de-initialized, hence the problem.
2012-04-11Avoid duplicate symbols & use setUp() and tearDown() for the item pool.Kohei Yoshida1-4/+26
2012-04-11Just use the internal item pool already written for the edit engine.Kohei Yoshida1-69/+4
2012-04-11You *are* fixed.Kohei Yoshida1-1/+0
2012-04-11Set default items to the item pool, do this and that, and now the test passes.Kohei Yoshida1-2/+8
2012-04-11needs ure and base-class setUp does necessary stuffCaolán McNamara1-7/+0
2012-04-11Attempt to add general-purpose unit test for editeng.Kohei Yoshida1-0/+141
But instantiating EditEngine causes segfault. The line is commented out for now.
2012-01-27fdo#38542: SvxBorderLine::GuessLinesWidths:Michael Stahl1-1/+1
Importing style:border-line-width="0.002cm 0.088cm 0.141cm" (which older OOo/LO apparently could write) fails, because GuessLinesWidths can't find a matching style (result: standard "double" border, 3 equal width parts). Try to create a custom BorderWidthImpl of type DOUBLE instead, that preserves the individual widths.
2011-10-10ensure correct export size type in stream operationCaolán McNamara1-0/+19
2011-09-12sb140: #i113503# mixing system CppUnit and OOo STLport does not work, backed ↵Stephan Bergmann1-1/+3
out a6913c9677c2 For LibO, that just means replacing sal/cppunit.h with sal/precppunit.hxx.
2011-03-28Moved SvxBorder* into editeng namespace to avoid duplicate DOUBLE on windowsCédric Bosdonnat1-0/+2
2011-03-21editeng: Adapted borderline unit test to new build systemCédric Bosdonnat3-128/+1
2011-03-19editeng: more reliable test library buildCédric Bosdonnat1-2/+11
2011-03-19Fixed lines width guessing: gap are no smaller than 1ptCédric Bosdonnat1-1/+1
2011-03-19Switching the order of the SetLinesWidth argumentsCédric Bosdonnat1-5/+28
2011-03-19Fixed units mess in SvxBorderLine and BorderLineImplCédric Bosdonnat2-18/+9
2011-03-19Documented and Unit-tested the SvxBorderLine::SetLinesWidthCédric Bosdonnat3-0/+238
generated by cgit v1.2.3 (git 2.39.1) at 2025-03-02 12:55:34 +0000