summaryrefslogtreecommitdiff
path: root/solenv/inc/tg_scp.mk
diff options
context:
space:
mode:
Diffstat (limited to 'solenv/inc/tg_scp.mk')
-rw-r--r--solenv/inc/tg_scp.mk6
1 files changed, 3 insertions, 3 deletions
diff --git a/solenv/inc/tg_scp.mk b/solenv/inc/tg_scp.mk
index f049dc2fce78..f9f646e56820 100644
--- a/solenv/inc/tg_scp.mk
+++ b/solenv/inc/tg_scp.mk
@@ -2,9 +2,9 @@
#
# $RCSfile: tg_scp.mk,v $
#
-# $Revision: 1.8 $
+# $Revision: 1.9 $
#
-# last change: $Author: hjs $ $Date: 2001-08-15 10:02:09 $
+# last change: $Author: hjs $ $Date: 2002-06-21 13:12:04 $
#
# The Contents of this file are made available subject to the terms of
# either of the following licenses
@@ -111,7 +111,7 @@ $(SCP$(TNR)TARGETN): $(LOCALSCP$(TNR)FILES)
@echo ------------------------------
@echo Making: $@
@+-$(MKDIRHIER) $(BIN)$/$(SCP$(TNR)LINK_PRODUCT_TYPE) >& $(NULLDEV)
- scplink $(SCPLINKFLAGS) @$(mktmp $(foreach,i,$(SCP$(TNR)FILES) $(subst,$(@:d:d:d), $(@:d:d))$/$(i:+","))) -o $@
+ $(SCPLINK) $(SCPLINKFLAGS) @$(mktmp $(foreach,i,$(SCP$(TNR)FILES) $(subst,$(@:d:d:d), $(@:d:d))$/$(i:+","))) -o $@
$(SCP_CHECK_TOOL) $@
.ENDIF
generated by cgit (git 2.34.1) at 2024-07-12 23:18:08 +0000
> 2016-11-08reduce copying when decomposing drawinglayer primitivesNoel Grandin instead of returning a Primitive2DContainer from each method which we are then going to immediately append to another container, pass down a single container by reference which we can append to Change-Id: I0f28a499d2ec54f7111a7044c30099767aa079e1 Reviewed-on: https://gerrit.libreoffice.org/30258 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2016-04-19drawinglayer, sw: indentation fixesMiklos Vajna Change-Id: Ia84182629f33220a0d85bde00c16f9c26f45e3c5 2016-04-18tdf#99315 VclPixelProcessor2D: fix double border line widthMiklos Vajna Regression from commit 2c91cb08d65cd35fa8ef6eaca3677aa82fb58cbe (better drawing support for borders of different width, fdo#33634, 2012-04-04), the problem is that previously the width of inner/outer double border lines got rounded to integer values quite early, but after the commit they are kept at a double precision for much longer, which needs pixel correction in VclPixelProcessor2D. Example: if the border with is 1.47, and the line gets moved by 0.2 pixels, then the inner and outer edge of the line will be 0.2 and 1.67, which gets rounded to 0 -> 2 in the pixel processor. Previously the input was rounded to 1, so moving by 0.2 resulted in 0.2 -> 1.2, which got rounded to 0 -> 1. The result is that sometimes the line width is 1 pixel wider than expected. Fix the problem by allowing VclPixelProcessor2D to request pixel correction from BorderLinePrimitive2D. It wouldn't be possible to do pixel correction only in VclPixelProcessor2D, as it has no idea what to correct: it only gets polygons, so it has no idea if e.g. the top of a polygon is the outer edge of a top border line or an inner edge of a bottom border line. Change-Id: I1971f3a952fbcdc598ab46c659e12d976c13cbe6 Reviewed-on: https://gerrit.libreoffice.org/24221 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> 2016-04-15loplugin:refcountingStephan Bergmann Change-Id: I4f696bdb7b37da5949182d522b0d3c6c41fdc756 2016-04-15Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive widthMiklos Vajna Regression from commit 2c62596cf264ef10749d8bfdb2bb2ebef2d98fbc (fdo#75260: Correctly draw double lines for both Writer and Calc., 2014-03-03), the problem was that when decomposing a double border line promitive to solid line primitives (which happens for the legacy "border" type, while both the Calc UI and Excel importer creates "border-thin" ones), the decomposed inner line's height was larger than the requested width. As a result there was no gap between the polygon of the inner and the outer line of the double border, looking like a non-double border. The width of the outer border is still incorrect on the screen, though. Change-Id: Ia9713c315ce8f23e2579b257169798e7c82c0a64 Reviewed-on: https://gerrit.libreoffice.org/24115 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>