- 27 Kas, 2018 39 kayıt (commit)
-
-
Rizal Muttaqin yazdı
Change-Id: I1d569983551d27b59fccfab84c0fc7b6bd86dc77 Reviewed-on: https://gerrit.libreoffice.org/64098 Tested-by: Jenkins Reviewed-by:
Rizal Muttaqin <riz_17_oke@yahoo.co.id>
-
Tor Lillqvist yazdı
The way the iOS app is built (over in the online repo), any "resources" to be included need to be copied into the workdir/CustomTarget/ios folder. Change-Id: Ibac15b03dc447d6649e03404fe9a68ef3b4881b9
-
László Németh yazdı
as in ODT implementation of Google Docs, and as in DOCX supporting basic requirements of creating digital and professional print media. This patch fixes DOCX import (tdf#121668) and it gives the required PDF export, too. In the case of solid color, color gradient, hatching, pattern and tiled bitmap (except stretched bitmap), this patch removes the obsolete white border around the text area, if the user modifies the page background. Note: likely the white border was good for home printing in former times, but now it forms only a serious barrier for most users to create de facto design standard whole page background formatting instead of its unacceptable poor man's version. Note 2: the OpenDocument standard refers XSL/CSS here, and browsers adapt background settings to the body margin area the same way, as Google Docs and fixed LibreOffice do. More information: tdf#112195 "(Whole-Page-Filling) - Allow page background to cover the whole page (reloaded)" tdf#33041 "Allow page background to cover the whole page, not only within page borders/margins" tdf#121668 "FILEOPEN DOCX Page Color created with Word disappears on the margins" ooo#9370 "Off-margin page background" (https://bz.apache.org/ooo/show_bug.cgi?id=9370) Change-Id: I7c6c96ceaf7102b38e3e5c1ed767db0ee63520ab Reviewed-on: https://gerrit.libreoffice.org/63914Reviewed-by:
László Németh <nemeth@numbertext.org> Tested-by:
-
Noel Grandin yazdı
Change-Id: I05ae398b75bbafe9b144a90e6735cf7d5e532ce4 Reviewed-on: https://gerrit.libreoffice.org/64097 Tested-by: Jenkins Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk>
-
Noel Grandin yazdı
Change-Id: Ia505df60f5758d40dd55bc5b24886fd8aec327ce Reviewed-on: https://gerrit.libreoffice.org/64092 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: Ic363903bb6e32c029f5aac6810f69d590df1bf79 Reviewed-on: https://gerrit.libreoffice.org/64091 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I4e10f0a2f40f9e7b6cc40a810468f43b2ab97aa9 Reviewed-on: https://gerrit.libreoffice.org/64090 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I945047c0955bc66602d1a5033197a7405a69a8d3 Reviewed-on: https://gerrit.libreoffice.org/64089 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I1a83c897d93a29d38aebccdba33be7b70592922e Reviewed-on: https://gerrit.libreoffice.org/64096 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: Ie754752203dcb066c69dff6effb835d7e1db1753 Reviewed-on: https://gerrit.libreoffice.org/64088 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I88a53e285cc3e8b6cc1c67b1e56322a918554de6 Reviewed-on: https://gerrit.libreoffice.org/64087 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I46eb4145bd79253c1c20b7a03d82b6873402d9ac Reviewed-on: https://gerrit.libreoffice.org/64086 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I31f810383fb92b2d0dbe9fa9162b77f137154e91 Reviewed-on: https://gerrit.libreoffice.org/64085 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I4f10e323293485e7a1969fd4c80873aa05971e6c Reviewed-on: https://gerrit.libreoffice.org/64084 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I89a6244c01be811bfdfc443f687708ed6aec8a10 Reviewed-on: https://gerrit.libreoffice.org/64083 Tested-by: Jenkins Reviewed-by:
-
Michael Meeks yazdı
Also add image scale to in-memory cache lookup. Change-Id: I1e84b922d4a9ab2f1723c5cb8a72f295c6940504 Reviewed-on: https://gerrit.libreoffice.org/64043 Tested-by: Jenkins Reviewed-by:
Michael Meeks <michael.meeks@collabora.com>
-
Michael Meeks yazdı
This allows us to choose to render HiDPI images at the right time, when we have the DPI of the device to render to. The first step in a better, and more industry standard way of improving our UI for HiDPI via rendering level scaling that should retain a consistent look across the app with many fewer changes. Change-Id: I36681f3242cb650de4f0b2d0fcdffbe5618e30fc Reviewed-on: https://gerrit.libreoffice.org/64040 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: Ia1a45e7292a61efd21c4a7351af1a681b92e886e Reviewed-on: https://gerrit.libreoffice.org/64077 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Caolán McNamara yazdı
Change-Id: I41a053f63db6bced24dd6586e2c347d286339c29 Reviewed-on: https://gerrit.libreoffice.org/64071 Tested-by: Jenkins Reviewed-by:
-
Thorsten Behrens yazdı
Change-Id: I940e1ae01ec384069cf2704fdc81b7561e9f8d63 Reviewed-on: https://gerrit.libreoffice.org/64094Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by:
-
Bartosz Kosiorek yazdı
With introduing String rotation support I made mistake by not removing Maping from DX-Array. With this commit I'm fixing that issue. Now drawing with DrawDriverString record, and rotation is working perfectly. Change-Id: I7ae051b3791d9d2d8e2143ed33d21b7bfbc551c6 Reviewed-on: https://gerrit.libreoffice.org/64079 Tested-by: Jenkins Reviewed-by:
Patrick Jaap <patrick.jaap@tu-dresden.de> Reviewed-by:
Bartosz Kosiorek <gang65@poczta.onet.pl>
-
Armin Le Grand yazdı
This change solves the non-linear World-To-View trans- formation that calc uses due to it's screen rendering as good as currently possible (AFAIK). Calcv view is layouted on pixel base (due to better homogen distances and full pixel lines between cells), but this leads to having a non-linear transformation between discrete units (pixels, view) and model coordinates (World). In principle, each cell has it's own (so called) ViewTransformation -> the position on screen depends on the mappings of all cells top/left from it. This is obvioulsly non-linear and can sometimes be seen by producing 'offset' errors when many cells (small and thin) are shown in low zoom stages. No better solution for this comes to mind easily. The extremes are - on the one hand AntiAliasing the whole calc edit view and accept 'unsharp/AAed' lines - on the other hand what we have now. Maybe a future solution could find a mapping that gets close to linear mapping for the full view. On the long run this state is hard to keep correct. Even with this extended solution the mapping of SdrObjects spawning mutiple cells is assumed 'linear' in that area - which is in reality currently not the case (!) Note: This is only true for the screen visualization, print and/or PDF export do not do that pixel-based layouting. Note2: This mechanism is general in DrawingLayer (look for '.*GridOffset.*'. If it is deactivated by providing no offsets, the result is the unchanged, linear mapping. First step: Add interfaces to get a possible GridOffset at ViewObjectContact. There it belongs, we have a view- dependent offset per object and view. Add mechanisms to create on-demand and reach back to the view (aka calc's derivation of it). Second step: Implement the on-demand creation, adapt to use it in ViewObjectContact::getPrimitive2DSequence, add stuff to reset on zoom change, disable temporarily old mechanism -> paint already works. Need to adapt the places from old mechanism where the GridOffset was used, but no longer the geometry creations. Third step: Isolated and disabled old mechanism (by already removing SetGridOffset). Marked all places that possibly need change with '//Z' tag. Main work now will be to adapt in the SdrView implementations in svx to know about having a SdrObject-dependent ViewTransformation at all (currently not known, was hard-coded at some places from the old code, ViewTransformation set as MapMode at a target OutputDevice, not member at SdrView at all...). Fourth step: Adapt the Handles and OverlayObjects to use an evtl. existing GridOffset. The mechanism is that the SdrHdl(s) can be seen as 'Model-Objects', these get converted to OverlayObjects in the ::CreateB2dIAObject() implementations, for all SdrMarkView and SdrPageView, so this is the place where the ObjectContact is known (the SdrPageWindow *is* a ObjectContact) and the view- dependent GridOffset can be calculated per SdrObject. I modified OverlayObject to be able to work with a set Offset that embeds the created visualization using this additionally. Handles get now correctly set and have a working HitTest (due to that already using the primitives). Some inter- action stuff already working, some will need more adaption. We simply have no concept for this stuff... Refactored to not get dependencies to SdrObject in ObjectContact. Fifth Step: Make HitTest work by adding the View-And- Object dependent GridOffset in the View when HitTest is triggered. This is in SdrMarkView::CheckSingleSdrObjectHit where pObj->GetCurrentBoundRect() is used that gets the view-independent form. To make HitTest work, add a possible GridOffset. Since this will be necessary more often in SdrView hierarchy, added a tooling method (getPossibleGridOffsetForSdrObject) at that level after checking that at that level will be reachable at all potential spots. Inside that method the correct ObjectContact will be identified and the object-specific offset requested there. Sixth Step: Adaptions and started some cleanups. Still some adaptions needed: - After creation of new object, need to relocate from used GridOffset setting to WorldCoordinates - Interactions, e.g. start with dragging handles or full object/points Seventh Step: React on EndCreateObj. Here, the created SdrObject is in model coordinates and needs to be adapted to evtl. GridOffset. This is 'tricky' due to calculating the possible offset based on new coordinates 'close' to the target position, but may be in the wrong cell. Nonetheless this is the best we can do here. Last (hopefully) missing are now all interaction viszualizations. They already work and are applied correctly, but wrong visualized. Have taken the time to unify adding OverlayObjects for selection visualization to OverlayManager, see handleNewOverlayObject. This does all needed when adding OverlayObjects in one place where the GridOffset can also be handled. It makles things more safe - not possible to forget one of the three steps for others. Eighth Step: Do the same unification for creating the OverlayGeometry, also rename methods to make usage more clear. We now have SdrHdl::insertNewlyCreatedOverlayObjectForSdrHdl SdrDragMethod::insertNewlyCreatedOverlayObjectForSdrDragMethod which can do the needed GridOffset changes centralized. Needed to get a ObjectContact for this at SdrDragMethod, so adapted ::CreateOverlayGeometry implementations accordingly. Missing is now the implementation in insertNewlyCreatedOverlayObjectForSdrDragMethod to add the GridOffset - if used. This has no SdrObject at this time, so we will need a fallback to do the same using a Range (Rectangle). The stuff doing this for SdrObject already has a fallback and is based on using the Rectangle from the SdrObject anyways, so this will be possible. Ninth Step: Cleanup of old stuff (no more //Z), adapted some usages of OverlayObject creations to use getViewIndependentPrimitive2DContainer instead of the view dependent parts so that offset applied to drag-overlays is correct and not already added. Adapted insertNewlyCreatedOverlayObjectForSdrDragMethod to use calculateGridOffsetForB2DRange. Use now that instead of SdrObject-based approach in calc - is more generic. Getting closer, but still not complete - there is an error with dragging the grepped handle somehow - the offset for drag is somehow wrong. Tenth Step: Corrected that offset error. Of course at interaction start and progress (move) the coordinates are in GrifOffset coordinates and need to be corrected to Model coordinates. Done that at ::BegDragObj and ::MovDragObj, works well. Of course there are exceptions for the crop-handles, so needed to add setting the correct parameters at SdrHdl when these got created, then all works as expected. The strategy is to *not* change the model data itself in any way, instead do all changes/adaptions in the view-only code. This has minimal impact and is needed due to having a 1:n relationship between model and views anyways. There are two directions: All visualizations are adapted to take the GridOffset into account (SdrObjects, overlay, handles, InteractionObjects, ...). In the other direction input like MousePosition is in principle in calc EditView in 'GridOffset'-coordinates and needs to be mapped back before usage. Change-Id: I2ecdd409def96a7248a26a65a22e59eb962880a0 Reviewed-on: https://gerrit.libreoffice.org/64057 Tested-by: Jenkins Reviewed-by:
Armin Le Grand <Armin.Le.Grand@cib.de>
-
Michael Stahl yazdı
At least on tinderbox MacOSX-x86_64@49-TDF the sed appears to ignore the literal newline character, which is unfortunate, particularly since it worked on the Jenkins builder. Blind fix to replace this with a tr invocation that already appears to work in Zip.mk. Change-Id: I7a77e69774b050a018b12c73ddd9eff849c33a86
-
Gabor Kelemen yazdı
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ice2eb8c5994bf2ccb88972332ca4a1d3ed41752a Reviewed-on: https://gerrit.libreoffice.org/63826 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com>
-
Noel Grandin yazdı
Change-Id: I0a8867399699d1c5ce17c2e5dadf96510246f173 Reviewed-on: https://gerrit.libreoffice.org/64067 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I3a2145277212b7b45c25bea2e33aae3f6f4a7776 Reviewed-on: https://gerrit.libreoffice.org/64066 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
and document in the registry that the SubstFontsPS is unused Change-Id: I66a9e0b4353f17b34cffb02823726c9887b7bdd3 Reviewed-on: https://gerrit.libreoffice.org/64065 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I09a0eb661b66da78d8b3809124930bc761960712 Reviewed-on: https://gerrit.libreoffice.org/64064 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I5e1a92d94e5b7963c8162b74f1b67dbbf3eeccc9 Reviewed-on: https://gerrit.libreoffice.org/64063 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I0fffa7b02ac61ef009e566d04b903cc02e9b4b3d Reviewed-on: https://gerrit.libreoffice.org/64062 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I9e832da8f6b7a90d72c07ab712cbe00774496b76 Reviewed-on: https://gerrit.libreoffice.org/64060 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I604e3bf6362271e767a4862a2c9d789a2c89df88 Reviewed-on: https://gerrit.libreoffice.org/64070 Tested-by: Jenkins Reviewed-by:
-
Tor Lillqvist yazdı
Most probably that was related to "pulsating" buttons that haven't been used since 10.9. Whether the code even worked (made buttons pulsate) on 10.9 anyway is unclear. Much of the code in this file uses various HITheme (Carbon?) API that as far as I know is long since deprecated and undocumented. It's weird that it still compiles, and that it doesn't get caught by the private API use checking when submitting to the the Mac App Store, in the LibreOffice Vanilla case. This change reduces the busy looping in Dialog::Execute() even when nothing happens (no user input, no mouse movement) when displaying a dialog. Change-Id: I9c62db608f637aa5d8493176feb2873f6426fd00
-
Miklos Vajna yazdı
This restores compatibility for API users who called getByName() on the bitmap table and expected that the result can be set as a value for the GraphicURL property. The case is similar to the Writer images, which was handled in commit 587803ba (sw TextGraphicObject: handle XBitmap for GraphicURL, 2018-08-08) already. Change-Id: I3740a68989b306425d0d6c4d4e350ac163cb4170 Reviewed-on: https://gerrit.libreoffice.org/64069 Tested-by: Jenkins Reviewed-by:
-
Tor Lillqvist yazdı
It is much over a year since we bumped to 10.9, so it is time. Bumping to 10.10 will allow us to with good conscience get rid of some code that (presumably) tries to emulate some aspects of OS X user interface look that went away in 10.10. See tdf#114839. Change-Id: Ic41f73d8e59a40c4696069af85bb3ff33146086c Reviewed-on: https://gerrit.libreoffice.org/63880 Tested-by: Jenkins Reviewed-by:
Tor Lillqvist <tml@collabora.com>
-
Noel Grandin yazdı
Change-Id: I01321f82958bbf22838554010abf706a3e9b9391 Reviewed-on: https://gerrit.libreoffice.org/64061 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: Ia40e882af0df396895a19dd34caa60461cdf6c12 Reviewed-on: https://gerrit.libreoffice.org/64059 Tested-by: Jenkins Reviewed-by:
-
Rahul Gurung yazdı
Change-Id: Idd62a6458d7aa0d1d8a479f5ebf78637e0360548 Reviewed-on: https://gerrit.libreoffice.org/63950 Tested-by: Jenkins Reviewed-by:
Markus Mohrhard <markus.mohrhard@googlemail.com>
-
Markus Mohrhard yazdı
Change-Id: I1048d86bf11b4fdd4a5c90f6e98276893b8ffbf4 Reviewed-on: https://gerrit.libreoffice.org/64078 Tested-by: Jenkins Reviewed-by:
-
- 26 Kas, 2018 1 kayıt (commit)
-
-
Miklos Vajna yazdı
This way it can't happen that we open a menu or context menu, the user switches away (loosing focus) and a leftover floating window is still there. Handle this at the same place where we stop blinking the cursor on focus loss. Change-Id: I4321e8e3fa1d3f8976c0a1fa29c6a182972023bf Reviewed-on: https://gerrit.libreoffice.org/64053Reviewed-by:
-
