- 28 Eyl, 2018 1 kayıt (commit)
-
-
Aron Budea yazdı
This reverts commit 3d92276f.
-
- 21 Eyl, 2018 5 kayıt (commit)
-
-
Samuel Mehrbrodt yazdı
Change-Id: Iaf9c8e2ed72115e1f82d2541ae2a1d4803795a46 Reviewed-on: https://gerrit.libreoffice.org/60752 Tested-by: Jenkins Reviewed-by:
Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 088af440) Reviewed-on: https://gerrit.libreoffice.org/60768Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 005be0cd)
-
Caolán McNamara yazdı
Change-Id: Ifbe81b851b17858a915105c102af6f4d8f2c81fa Reviewed-on: https://gerrit.libreoffice.org/60800Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Christian Lohmaier yazdı
Change-Id: I1a8c8bc20ee7e97b47f0602dcfaa3cb1b771de8f (cherry picked from commit bb26bd61) (cherry picked from commit 606c2208)
-
Xisco Fauli yazdı
Change-Id: Ie29c2213d8efccd7750396325ce05b4909c09d02 Reviewed-on: https://gerrit.libreoffice.org/60592Reviewed-by:
Michael Meeks <michael.meeks@collabora.com> Tested-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com> Tested-by:
-
Miklos Vajna yazdı
The interesting part of the layout of page 2 is: - frame #40 is a section frame with a text frame which is in a list ("A") - frame #48 is a section frame after that, with the same top=19213 Given that frame #40 has height > 0, they overlap when the page is rendered. What happens is: - frame #40 grows - there are other section frames between #40 and #48 in-between, but they don't have an SwSection - these frames are skipped - then the position of #48 is invalidated So the next time we calculate the position of #48, we look the last skipped (previous) section frame (which still has top=19213, since its position was not invalidated above), and since its height is 0, we conclude that our current top=19213 is valid after all. This is like this since commit 84a3db80 (initial import, 2000-09-18), so leave the code there that invalidates not only the next frame, but all the way down to the first non-SwSection-less-SwSectionFrame. But instead of just invalidating the last frame, invalidate the in-between SwSection-less-SwSectionFrames as well. In practice this did not cause a problem in case the document has no layout cache. If it does, then the frames are created on pages hinted by the cache, then later moved to their final place. In practice this bug was visible only in this later case. (I.e. such a layout cache can be only created if the machine that saved the document last time does not have the fonts needed by the document installed; and then the document is opened on an other machine which has those fonts.) (cherry picked from commit b5937112) Conflicts: sw/qa/extras/layout/layout.cxx Reviewed-on: https://gerrit.libreoffice.org/60658 Tested-by: Jenkins Reviewed-by:
-
- 17 Eyl, 2018 4 kayıt (commit)
-
-
László Németh yazdı
of cells of blank rows. This workaround is probably a fix for problems of most users, but for a full solution it needs to extend the workaround for all rows with not default settings, also avoiding of the possible performance problems. Note: the number 1000 of the extra rows came from a similar workaround used in XLSX export of Google Spreadsheets, but instead of listing extra empty 1000 rows in OOXML, this fix writes only the cells with not default settings from the extra 1000 blank rows. Reviewed-on: https://gerrit.libreoffice.org/58575 Tested-by: Jenkins Reviewed-by:
László Németh <nemeth@numbertext.org> (cherry picked from commit 99b9ea63) Reviewed-on: https://gerrit.libreoffice.org/58812Reviewed-by:
Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit d7cbaac6) Change-Id: Icac9441b7eb1520dcd20fc04337e070d070591c7
-
Michael Meeks yazdı
Change-Id: Idee779cea587e11f6d0f7902182c9394e73d46eb Reviewed-on: https://gerrit.libreoffice.org/60488 Tested-by: Jenkins Reviewed-by:
Andras Timar <andras.timar@collabora.com> Tested-by:
-
Michael Meeks yazdı
Change-Id: Ie0fb21776514a9a67e9fdff2ae856392cd711adb Reviewed-on: https://gerrit.libreoffice.org/60542Reviewed-by:
-
Michael Meeks yazdı
Change-Id: I22d2d545a6201cbb89d430c65f66e0fea8794d83 Reviewed-on: https://gerrit.libreoffice.org/60543Reviewed-by:
-
- 14 Eyl, 2018 6 kayıt (commit)
-
-
Andras Timar yazdı
Change-Id: If2673b0bdd1489e8bd0bc60b8372756da8cf1533
-
Muhammet Kara yazdı
This is just a band-aid to make personas feature work again. Change-Id: I80b54fe9a8ddc93d93744fcf2c7f739d81f6face Reviewed-on: https://gerrit.libreoffice.org/60432 Tested-by: Jenkins Reviewed-by:
Heiko Tietze <tietze.heiko@gmail.com> Tested-by:
Muhammet Kara <muhammet.kara@pardus.org.tr> (cherry picked from commit e98ac43e) Reviewed-on: https://gerrit.libreoffice.org/60468Reviewed-by:
-
Tamas Bunth yazdı
Change-Id: Ia0d0290517fdebd9a7700d52fa0e86de0e958b2d Reviewed-on: https://gerrit.libreoffice.org/60406 Tested-by: Jenkins Reviewed-by:
Tamás Bunth <btomi96@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/60462Reviewed-by:
-
Tamas Bunth yazdı
Change-Id: I81307c6e45220081c39ddd7d1672457202bbc517 Reviewed-on: https://gerrit.libreoffice.org/60404 Tested-by: Jenkins Reviewed-by:
-
Tamas Bunth yazdı
it should throw an exception. Change-Id: I55fd8ed5d92a28096b9bde6b0161e16d7543203b Reviewed-on: https://gerrit.libreoffice.org/60460Reviewed-by:
-
Jan Holesovsky yazdı
Steps to reproduce: * turn on changetracking * write few characters * insert table * move the cursor behind the table and type * crash Change-Id: Icd7b64d2fe594c2b87c9d3d7fa48a957755cbc3b Reviewed-on: https://gerrit.libreoffice.org/60390Reviewed-by:
-
- 13 Eyl, 2018 2 kayıt (commit)
-
-
Justin Luth yazdı
This commit reverts the first (LO 4.3ish) regression commit 60635557 and most of the two commits that tried to fix that: commit 9ae1e094 and commit ee45d881 in LO6.0/6.2. The ooxmlexport6 unit test shows that there is nothing special about 180degrees. So, all transformations need to be avoided in docx format - not just 180 degree ones. I removed IsInGroupShape() since it is no longer being used - as per standard procedures. Reviewed-on: https://gerrit.libreoffice.org/58434 Tested-by: Jenkins Reviewed-by:
Justin Luth <justin_luth@sil.org> Reviewed-by:
Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit ab296726) Change-Id: Id2bba5bc542875a10ac21fbb67f29b2d59705493
-
Justin Luth yazdı
Introduced in LO 4.0 in a mass copy of compat settings in commit 355d25ea Reviewed-on: https://gerrit.libreoffice.org/57991 Tested-by: Jenkins Reviewed-by:
-
- 12 Eyl, 2018 22 kayıt (commit)
-
-
Ashod Nakashian yazdı
Change-Id: Idde3cd22ecc1f1bd34f7519acedc85584ed2deaf Reviewed-on: https://gerrit.libreoffice.org/58160Reviewed-by:
Jan Holesovsky <kendy@collabora.com> Tested-by:
-
Ashod Nakashian yazdı
When loading document, LOK needs to setup the client view, register callbacks, get document size and type, etc. All of these need to take SolarMutex, which is taken by the idle jobs immediately after loading, blocking LOK from finishing initialization and rendering the first tiles for the user. This gives the user the impression that the document is loading for far longer than it actually is, due to lack of interactivity (or indeed any activity on the screen besides the spinning wheel). By delaying the idle jobs, we allow time for LOK to finish initialization and render the first tiles before the idle jobs kick in and hog SolarMutex. Reviewed-on: https://gerrit.libreoffice.org/56572Reviewed-by:
-
Ashod Nakashian yazdı
Reviewed-on: https://gerrit.libreoffice.org/57160Reviewed-by:
-
Aron Budea yazdı
spell-checker is initialized during font init since e7f65920 Change-Id: Ia5b5223aa8cc00d0e80451142ae18a7046ad00d4 Reviewed-on: https://gerrit.libreoffice.org/57064Reviewed-by:
Ashod Nakashian <ashnakash@gmail.com> Tested-by:
-
Ashod Nakashian yazdı
Reviewed-on: https://gerrit.libreoffice.org/56573Reviewed-by:
-
Justin Luth yazdı
better fix than cecf71c1 since: 17.4.25 insideV (Table Cell Inside Vertical Edges Border) This element specifies the border which shall be displayed on all interior vertical edges of the current group of table cells. [Note: Although individual table cells have no concept of an internal edge, which would render this property useless in most cases, it is used to determine the cell borders to apply to a specific group of cells as part of table conditional formatting in a table style, for example, the inside vertical edges on the set of cells in the header row. end note] So, I interpret this as insideV/H having meaning only within table styles, and not when directly applied to a cell. The only documents I've seen with insideV/H directly applied to a cell seem to have been created by LO - which dumps them everywhere, redundantly. Tablestyle cell groupings are handled elsewhere via grabbag dumps, so insideV/H borders can be eliminated from TableCellProperties. Change-Id: I128417f0a0b485c85ede463daacb8feabc457302 Reviewed-on: https://gerrit.libreoffice.org/60187 Tested-by: Jenkins Reviewed-by:
-
Justin Luth yazdı
Previously, if an earlier column wished for the entire table width, then none of the other columns could adjust their size, even if they only wanted one more character. This slight change gives every column a chance to "wish" for an equal portion, and still gives the earlier columns a chance to maximize. So, this should implement very similarly to before, thus workflow should not be impacted. Change-Id: I11e8b94ce333735aa92b5388af6319f8eb0ccc51 Reviewed-on: https://gerrit.libreoffice.org/60027 Tested-by: Jenkins Reviewed-by:
-
Justin Luth yazdı
Since the internal SW defaults (0) don't match the import defaults, always write the top/bottom, left/right margins into the document definition. It is very rare indeed to have a zero margin anyway, since the page margin being zero is highly discouraged because of printing. The bug report is for DOCX, but it also affects DOC. I don't have an example where LRSpace is skipped, but it only makes sense to treat these two the same just in case. Change-Id: Ie9a08ad0dd4f73bc976756fe244fc33e2dc804f3 Reviewed-on: https://gerrit.libreoffice.org/59967 Tested-by: Jenkins Reviewed-by:
-
Justin Luth yazdı
Well, not on the bottom or right outside cells. Obviously the presence of a bottom or a right in those cases doesn't indicate an inside line. Reviewed-on: https://gerrit.libreoffice.org/59600 Tested-by: Jenkins Reviewed-by:
-
Justin Luth yazdı
The absence of "on=" is treated in Word (tested 2003) as off. Change-Id: Ibc6b0e5ca0f25a9c3ca1b9505fa24c4d821bfd0 Reviewed-on: https://gerrit.libreoffice.org/59457 Tested-by: Jenkins Reviewed-by:
-
Justin Luth yazdı
I didn't see this mentioned in the sprm documentation, but that is how MS Word seems to implement it. Change-Id: I5b86ecf99a884e768877cdb0e71f43cdb9f2ad76 Reviewed-on: https://gerrit.libreoffice.org/59221Reviewed-by:
-
Justin Luth yazdı
Previously, a hash-encoded value would simply fail to zero and thus the color would be dark black. The unit test covers two conditions. Paragraph 1 has a valid encoding, and pararaph 2 has an invalid coding (which is ignored and fails to COL_AUTO). Change-Id: I68940f5c4b0975a87feb6cab8fb3572b7546a077 Reviewed-on: https://gerrit.libreoffice.org/59295 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
to solve the long-standing problem of Calc/Writer integration, ie. now Calc table data are inserted cell by cell in Writer text tables instead of putting an unwanted second table over the original, as an OLE object. First insert the OLE table as a nested native table using paste special as RTF, and cut and paste that to get a native table insertion, removing also the temporary nested table. This fix has got correct undo, but unfortunately, also a small flash during insertion by the temporary nested table. I've tried to fix that by LockView and LockModify, but it seems, they don't help. Note: the planned solution mentioned in the original OOo issue (reported in 2004) suggested to use a hidden temporary document, but that has got poblems with clipboard usage. Change-Id: I49253239f1878bce5fc4c93494f997ed37101a1c Reviewed-on: https://gerrit.libreoffice.org/58346 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
to get a user-friendly solution to copy Calc cell content to a text document and to its native tables. NOTE: MSO does the same for copying 1-cell tables, while LibreOffice was able to do this only with paste special as RTF. Change-Id: I6156333055aa9bed4cf56ff12f913e89d3f5700c Reviewed-on: https://gerrit.libreoffice.org/57783 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
commit 0307a627 fixed the top margin import of the paragraphs of document sections, and import of first paragraph of the text frames with beforeAutospacing, but nullified all other paragraph top margins in frames. Note: there is no visible margin difference in the unit test (extended by this commit) before and after the fix, because the first paragraph uses also afterAutospacing, resulting still 14pt paragraph space. But the tested beforeAutospacing value of the next paragraph checks the fix correctly. Change-Id: I0ab3b8bbff33c5488f4b4af1ea4dabf7105103f2 Reviewed-on: https://gerrit.libreoffice.org/57231Reviewed-by:
-
László Németh yazdı
of a text frame (first bug of tdf#104354), a table cell or a document by setting zero top margin here. This bug could result non visible paragraph content in narrow frames, as in the test document of the commit. See also commit f737c938 for a similar fix for first paragraph of a shape. Fix top margins of the first paragraphs of the affected tdf#82006 and tdf#107480, adding also new paragraphs to their RTF tests cases to keep the original tests, too. Reviewed-on: https://gerrit.libreoffice.org/56737Reviewed-by:
-
László Németh yazdı
ie. OOXML export/import of "_MarkAsFinal" MSO document property. Reviewed-on: https://gerrit.libreoffice.org/56475 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
Import custom document property _MarkAsFinal as LoadReadonly setting, export LoadReadonly as _MarkAsFinal in DOCX, XLSX and PPTX documents. Before this fix, LibreOffice opened read-only OOXML documents as editable, also saved and exported _MarkAsFinal=true silently, resulting unintented read-only warning info bar in MSO. This commit improves interoperability a lot, because this is a basic document protection of MSO, recommended on its UI. Note: LoadReadonly (on File->Properties...->Security, property "Open file read-only") doesn't show "Edit read-only" info bar from commit 630186ff, but it's still possible to switch on editing by Edit->Edit Mode. MSO shows info bar for _MarkAsFinal. (There is an advantage to hide the info bar in LibreOffice in a mixed environment, to avoid overwriting of press-ready MSO files by LibreOffice.) Note 2: Other differences of LoadReadonly in LO and _MarkAsFinal in MSO: (1) Switching on editing doesn't remove the LoadReadonly property automatically in LO. (2) Saving with LoadReadonly doesn't switch off editing of the actual (still opened) document in LO. Reviewed-on: https://gerrit.libreoffice.org/56180 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
Change-Id: I63fd380be974c1d15beef0d2cfec42350119ae2f Reviewed-on: https://gerrit.libreoffice.org/56050 Tested-by: Jenkins Reviewed-by:
-
Adam Kovacs yazdı
Change-Id: I496e1cbac527383837a4e8fcdee42967ecf555e4 Reviewed-on: https://gerrit.libreoffice.org/59968 Tested-by: Jenkins Reviewed-by:
-
Adam Kovacs yazdı
Extending commit d7551e32 to all default MSO 2016 preset dashes: Saving an ooxml file with LibreOffice now preserves the prstDash tags with the values sysDot, sysDash, dash, dashDot, lgDash, lgDashDot, lgDashDotDot, instead of converting them to custDash tags. Note: the import of the preset dash outlines are still not relative to the line width, in spite of their original behaviour in MSO. Change-Id: I65eaf06952a968019495664067010c874fce1352 Reviewed-on: https://gerrit.libreoffice.org/59203 Tested-by: Jenkins Reviewed-by:
-
Balazs Varga yazdı
With adding the "TextMaximumFrameWidth" property to the chart title's textbox property, it breaks chart titles longer then the chart width, as in OOXML reference implementation. LibreOffice previously distorted the text and squeezed the chart. This patch will fix it. Change-Id: Ic086d25b49e9c5cf9c6f2c79f141592749adc7d8 Reviewed-on: https://gerrit.libreoffice.org/59991 Tested-by: Jenkins Tested-by:
-
