- a form with a header row and a hundred empty bordered rows below it
printed only the header row. Calc drops a run of 84 or more equally
formatted rows below the last cell with content, and everything under
it, so the print range ended at the last row with data. The borders
were on screen all along, so only printing, the print preview and the
PDF export showed it.
- the run is measured from the last row with data, so typing changed
the result. On a form whose borders end at row 100, text in row 16 left
84 rows below it and the borders stayed away, text in row 17 left 83
and the whole form printed.
- ScDocument::IsPrintEmpty prints a page that carries a border and no
content, and suppresses one carrying only a colour. A bordered run is
therefore kept now, unless it is wider than SC_VISATTR_BORDER_STOP in
its own length or in its distance below the data, which is the whole
column case i30830 is about. The length stays the same as the sheet is
filled in, the distance stops a chain of shorter bordered ranges
reaching the sheet end. Neither measure applies to a run under
SC_VISATTR_STOP rows, because a run that short was never dropped.
- the print range also sets where Ctrl+End lands, how far the desktop
scrolls and what range is written out on save, so all three grow with
it. In the browser the scroll extent comes from the cell area, so it
stays where it was.
- a run has to meet one more condition than before to be dropped, so no
document prints less than it did, and the ones hitting this bug print
more.
- the tests say a bordered form is printed, a colour under the content
does not pull the print area down, a border too wide or too far down
does not either, a frame round a whole column leaves the printout
ending at the last row with content, and a form is printed wherever the
content ends, including when a font change splits it in two.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: I44d041cdbbcde7bfa69b53035f5bebc8d59f9bdd
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/14112
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit 00e5de0a8bd89e5f5c9f7b19fef85331354c4458)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211943
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A fraction whose terms are red came back with red terms and a black
bar, and a colored square root came back with a black root sign.
The formula draws these parts itself, so their color is not in the
text. It sits in the m:ctrlPr of the fraction or the root, which
neither filter read.
Read m:ctrlPr on import and keep the color while the parts inside are
read, so the command comes out once around the whole fraction rather
than repeated on the bar and on both terms. An inner color beats an
outer one, which is how the parser treats nested commands. A border box
that Writer does not draw is dropped, and the color it named stays on
the content that is left.
Write m:ctrlPr back on export wherever a node has a color of its own, but
only for a DOCX. A slide or a sheet does not declare the w namespace that
the color needs. The fraction, the brackets, the root, the accent, the
over and underline, the overbrace and underbrace, the border box and the
n-ary operator each have a property element that can hold one.
Added the testMathFractionBarColor unit test.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: Ic13c9e59756806932f61a6fb51e4919a49cdfcd6
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10047
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 568ac1d9bdfc8bd43995dbd3626e73084d4f90d6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211416
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Steps to reproduce:
1) Write a formula with a color command, such as color red { 1 }.
2) Save the document as DOCX and open it again.
The formula comes back at the default color, and the color command has
gone from its text.
A run is one stretch of text with a single set of formatting. In a
formula each run carries two property elements. The import already read
the math element m:rPr. The font color sits in the text element w:rPr.
The import skipped that one as an unexpected tag, and the export never
wrote it.
Read w:color on import and put a color command around the text of that
run. A color that StarMath has a name for is written with that name, so
a formula written as color red reads the same way after a round trip.
Other colors become hexadecimal digits, which the parser reads only in
upper case. A value of auto leaves the default color in place, and so
does black, which keeps ordinary formulas clean and lets the color
follow a dark document theme.
The braces of a color command hold an expression, and a run holds
whatever text the document put in it. A run of operators is written as a
literal, which is an expression and keeps the color. A run that does not
parse for any other reason keeps no color command, so the formula reads
the way it did before any color was carried over. The import never
writes command text that fails to parse.
On export, write w:color for a run whose node has a color of its own, but
only for a DOCX. A slide or a sheet never declares the w namespace, so the
color stays out of a presentation or a spreadsheet. The tree has been
arranged by then, so a surrounding color command has already reached the
leaf nodes.
The color of the lines and signs a formula draws, such as a fraction
bar, travels elsewhere and is not covered here.
Added the testMathColor and testMathObjectColorOmittedInSlide unit tests.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: I4207aab6a363e5f841de58e3f743d9e010609c10
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10046
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit dfcc0c42df5c774f4087f425cad0af81ecea6b5e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211415
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
- the printout lost rows when the user set Orientation to Landscape in
the File - Print dialog. Only the first page used the landscape paper.
The pages after it kept the portrait page breaks, so they took more rows
than fitted on the paper. The preview was correct, so only the paper and
the PDF showed the problem.
- ScModelObj::render() built a second ScPrintFunc after every page, so
that the document would hold the page style's page size again. That
object shared its page break vectors with m_pPrintState and recalculated
them for the portrait paper, so the next page read the wrong breaks.
render() now counts the pages once, after the last page.
- "tdf#166107: remove unnecessary resetPrintArea()" added the second
ScPrintFunc, https://gerrit.libreoffice.org/c/core/+/183948
(eccf4cd57a)
- sc::PrintPageRanges kept its results in a shared_ptr and its input by
value. One copy could recalculate the shared result while another copy
still read its own input as a match. PrintPageRanges shares the input
along with the results now.
- added testTdf171366 to check that the print dialog and the page style
split the sheet at the same rows.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: Ifa5998278ff899e713b439e33ed04d76f109fbc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210649
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins
- add support for x15 namespace.
- add a unittest.
- add support for <x15:connection> and <x15:rangePr> elements.
- support model and sourceName attributes.
<extLst>
<ext xmlns:x15="..." >
<x15:connection id="..." model="...">
<x15:rangePr sourceName="..."/>
</x15:connection>
</ext>
</extLst>
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: I3b3e380ddd07f251b23333fe9d3959961dd5c19c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190924
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
follow-up for https://gerrit.libreoffice.org/c/core/+/188451 (f84f8f2ea4)
- added a unittest for xmlMaps.xml and <xmlColumnPr>
- removed unused aContent variable.
- this was causing the tests to fail to load the bugdoc during createScDoc("...")
- change Target="/xl/xmlMaps.xml" to Target="xmlMaps.xml" in xl/_rels/workbook.xml.rels
- change xmlns attribute to xmlns:x in xl/tables/table[n].xml
- add XmlColumnPrModel and TableColumnModel
- these Models can be used for implementing sub-elements.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: I5e6ad575b7071f3cf4decb5d90d418b9c54ba107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189044
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
- we should take line spacing into account for field shadings.
- otherwise, bottom of some letters(e.g. "Ç", "ş", "g", "p") will be cut because of the "field shadings" background layer.
- also check if line spacing type is "proportional" or "fixed".
- add a unittest
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: I805551469f712ec6147b025d771d996ef7fd0c95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187986
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
- regression from commit 2413f21362
- if a paragraph is partly deleted, add it to the "hidden" list.
- if we delete -at least- a single character from a paragraph (during Record Track Changes is enabled), Writer thinks the whole paragraph and the numbering is deleted. Therefore, the numbering of the paragraph does not get added to the hidden list.
- this patch adds the partly-deleted paragraph numbering to the hidden list during fileopen.
- added a unit test
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: Ia8852eb7d61b57f15a037b2ffd3e6eec363f90af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186597
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
to fit header & footer if DocumentSettingId::TAB_OVER_SPACING compatibility flag is set.
- if a doc created in MSO Word and opened in LO Writer, header&footer for the first page were not visible - for some documents.
- this change make them visible now.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: If4548949514eb319a6b1e3af5799d266f53ec753
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185261
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
otherwise: (in word/settings.xml)
- if a docx document has w:enforcement="0", LO will not
import it. Hence, LO will not export it, too.
- this will cause a lack of enforcement attr. - which
will make the docx "protected" after export from LO - in MSO Word.
Therefore, we have to import enforcement attr. even if it's
value is "0".
Change-Id: I30cf3cd8725151ea5bd9d4e484757e36602707e5
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184042
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
in xl/pivotTables/pivotTable*.xml we have e.g. <location ref="A3:B6" firstHeaderRow="1" firstDataRow="1" firstDataCol="1" rowPageCount="1" colPageCount="1"/>
- the 'ref' attribute indicates the cell range of a pivot table.
- 'firstDataRow' specifies the first row of the PivotTable data,
relative to the top left cell in the ref value.
- 'firstDataCol' specifies the first column of the PivotTable data,
relative to the top left cell in the ref value.
if we get the number of rows and cols in the pivot table (using
<location ref="..."), and substract 'firstDataRow' & 'firstDataCol'
from it, we get the correct count attr. value of <row/colItems> during
export from ODS -> XLSX.
- added testTdf123225PivotTableEmptyRowColItems Cppunit test to make
sure that export works with empty row/col items.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: Ia85a89e429d95492f0f753af3fbf46771d1a2a0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182529
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
in xl/pivotTables/pivotTable*.xml.
- we should always export (.ods to .xlsx) <rowItems> and <colItems>, even if
the pivot table does not contain col/row items. Otherwise:
1) Excel will fail to open the xlsx document, you will get an error message.
2) Excel will open the file without any errors but:
2.1) context menu -by right clicking on the pivot table- will have less
or more items than it should have after "refresh".
2.2) if e.g. trying to sort the items you will get "Cannot determine
which PivotTable field to sort by" warning.
- we should add t="grand" to the last <i> element. Otherwise, Excel will not
have all functions in the context menu of the pivot table. Especially for the
"Grand Total" column/row cells. we shouldn't need "refresh" to use all
functions/items in the context menu.
- note: it is not completely clear that the last <i> element always gets
t="grand". however, testing on the some docs indicate that t="grand"
should be in the last <i> element.
- added testTdf123225PivotTableNoColItems unit test to check if
<i t="grand"> exported. also, added some useful information in the
comment section for future tests/issues.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: I22b42ddb4a27c4b7b88ad8a71376c2c82d5a735a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182242
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
of xl/pivotTables/pivotTable*.xml.
- additionally, export <i> and <x> with their default attribute values.
- <x/> single element has only "v" attribute and its value is
increased by 1 up to the count attribute value of rowItems/colItems.
- it is expected that this will fix function loss in XLSX pivot table's
context menu and there will be no need to refresh the pivot table.
(ODS -> XLSX)
- this is also fix "Cannot determine which PivotTable field to sort by"
warning on Excel if you try to e.g. sort the items - alongside the loss
of functions.
- add testTdf123225PivotTableRowColItems Cpp unit test
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: Id44806e666a55500ba3faeb0571e50e407c15791
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181795
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
- Initializing some dialogs at the startup of Options
makes it opening very slow on some low-power systems.
- This patch removes this initialization. This means,
all dialogs will be initialized at the time of search.
Therefore, we should wait a bit longer when typing
on the search bar to get the results...
- remove the default parameter "nNumberOfNode" from
initializeFirstNDialog()
- rename initializeFirstNDialog() to initializeAllDialogs()
Change-Id: I4fd9c5673f7edecfe6a6621b6018d5d405f112a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167023
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Moritz Duge <moritz.duge@allotropia.de>
- move and copy use the same ScViewFunc::MoveTable
function
- added 3 new parameters to "SfxVoidItem Move FID_TAB_MOVE"
- SfxBoolItem FromContextMenu FN_PARAM_4,
- SfxUInt16Item ContextMenuIndex FN_PARAM_5,
- SfxBoolItem MoveOrCopySheetDialog FN_PARAM_6
- moveLeft and moveRight of inactive tabs are implemented
- move and copy of inactive tabs from the Move/Copy Sheet
dialog are implemented
- made Move/Copy Sheet dialog async
Change-Id: I97461780a6c46f601bce9490315cd5cbea9505d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158078
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Gökay ŞATIR <gokaysatir@collabora.com>
(cherry picked from commit 4d5f8b43b04734805f48b921b98a74fd9ab67d0f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162385
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Bayram Çiçek