aboutsummaryrefslogtreecommitdiff
path: root/source/pt/basctl
diff options
context:
space:
mode:
authorChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2014-04-20 03:37:05 +0200
committerChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2014-04-20 04:47:28 +0200
commite3821ba029d6e69b786157d13984ca5af908bb31 (patch)
tree4ba56321b75e683beafcf57c7b61bae3bf33e620 /source/pt/basctl
parentf3f04265562dcd40990cccdd83170c8afffef4ab (diff)
update translations for 4.3.0 alpha1
and force-fix errors using pocheck Change-Id: Id45e0dc7161738ebd69ba07108b9fdd149643703
Diffstat (limited to 'source/pt/basctl')
-rw-r--r--source/pt/basctl/source/dlged.po9
1 files changed, 5 insertions, 4 deletions
diff --git a/source/pt/basctl/source/dlged.po b/source/pt/basctl/source/dlged.po
index 587b49d3ff5..37770df7df7 100644
--- a/source/pt/basctl/source/dlged.po
+++ b/source/pt/basctl/source/dlged.po
@@ -4,16 +4,17 @@ msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: https://bugs.libreoffice.org/enter_bug.cgi?product=LibreOffice&bug_status=UNCONFIRMED&component=UI\n"
"POT-Creation-Date: 2013-11-20 13:01+0100\n"
-"PO-Revision-Date: 2012-02-16 14:02+0200\n"
-"Last-Translator: Sérgio <smarquespt@gmail.com>\n"
+"PO-Revision-Date: 2014-04-10 00:15+0000\n"
+"Last-Translator: Carlos <crolidge@hotmail.com>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
-"X-Generator: LibreOffice\n"
+"X-Generator: Pootle 2.5.1\n"
"X-Accelerator-Marker: ~\n"
+"X-POOTLE-MTIME: 1397088936.000000\n"
#: dlgresid.src
msgctxt ""
@@ -82,7 +83,7 @@ msgctxt ""
"FT_INFO\n"
"fixedtext.text"
msgid "The default language is used if no localization for a user interface locale is present. Furthermore all strings from the default language are copied to resources of newly added languages."
-msgstr "É utilizado o idioma padrão se não existir qualquer configuração regional da interface do utilizador. Para além disso, todas as palavras do idioma padrão serão copiadas para os recursos de idiomas recentemente adicionados."
+msgstr "O idioma padrão será utilizado se não existir qualquer configuração regional para a interface do utilizador. Além disso, todas as palavras do idioma padrão serão copiadas para os recursos de idiomas recentemente adicionados."
#: managelang.src
msgctxt ""
generated by cgit (git 2.34.1) at 2025-02-06 11:17:12 +0000
-5-5'>libreoffice-3-5-5 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/include/basegfx/utils/bgradient.hxx
AgeCommit message (Collapse)Author
2023-09-21tdf#146619 Recheck include/basegfx with IWYUGabor Kelemen
Change-Id: I08dad6ceeaa9e5470491c09f06d819c4c27ec5f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156983 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
2023-08-21move BGradient to awt::Gradient2 UNO conversion into docmodelTomaž Vajngerl
This is needed because the module dependencies are an issues if the conversion is done in basegfx. The bigger issue will come when the ComplexColor conversion will be done as basegfx can't depend on docmodel because of circular dependencies. The BGradient is also more suitable for docmodel anyway as the previously it was part of the model and is not a basic (gfx) type - however this doesn't move the whole BGradient into docmodel yet. Change-Id: Id91ce52232f89f00e09b451c13da36e2854ae14b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155674 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-09MCGR: tdf#155479 repair gradient SVG export for MCGRArmin Le Grand (allotropia)
Unfortunately SVG export is based on metafiles and thus there is (in principle) no way to get the BGradient/ColorStop/MCGR data transfered as needed. For that, using UNO API to read the model or using B2DPrimitives would help - as is better for the export respectively. Since there is not the time to re-design SVG export I added this 'compromize' as a fix. It gets the needed data transported over the metafile (that part is the compromize). It then exports the MCGR data to SVG (at least - as was already there - if it's a linear/axial gradient). This happens now with all Gradient Stops when there is a MCGR gradient. That part is/will hopefully be re-usable if SVG export gets redesigned. I also added a handling for StepCount feature, so when used (in LO, others do not have that) 'hard' color stops get generated to make the gradient look identical for SVG export. Had to make adding of that extra-information in metafiles dependent on exporting really to SVG. There are 51 cases which use 'MetaActionType::COMMENT' which would potentially have to be adapted. Also added code to solve the problem for TransparencePrimitive2D at VclMetafileProcessor2D::processTransparencePrimitive2D. This will now - also only for SVG export - directly create the needed MetaFloatTransparentAction and add additional MCGR information. This will be used on SVG export to write a 'Mask' as was done before. This is now capable of creating fill MCGR-Masks in the sense that any number of TransparencyStops will be supported. Change-Id: Ic6d022714eae96b8fbc09e60652851ac5799b757 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152623 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-06-05tdf#155549 MCGR: Recreate 'axial' from symmetric 'linear'Regina Henschel
When exporting a shape with an axial gradient fill to OOXML, it is converted to a linear gradient with multiple color stops. Versions before MCGR had recreated it as axial gradient on import from OOXML. But now LO is able to handle multiple color stops and so the linear gradient from OOXML is imported as linear gradient in LO. When such file is then written as ODF, the multiple color stops are in elements in extended namespace and versions before MCGR do not understand them. They show only the first and last color (which are equal) and the gradient is lost. With this patch LO converts the linear gradient back to an axial gradient on export to ODF. The exported axial gradient is rendered in a version with MCGR same as the linear gradient when opening the OOXML file. The difference is, that versions without MCGR now render an axial gradient with two colors. Change-Id: I2b416b4cdca75d8327107a4f259d63c2e6e97ac3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152574 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-05-31MCGR: Use tryToRecreateBorder for better BW comp with LOArmin Le Grand (allotropia)
For better compatibility with LO versions before MCGR, try to re-create a 'border' value based on the existing GradientSteps. With MCGR we do not need 'border' anymore in quite some cases since no Start/EndColor at 0.0 resp. 1.0 is explicitely needed. Since we (unfortunately need to) internally continue to support border anyways it does no harm to fallback to use the border value - if there is an equivalent representation as this helper checks for. For exports that do not support 'border' this will be adapted as needed (see tryToApplyBorder()) Change-Id: If98c64039ff97143d4b5c92ac2a950e70f5bb70a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152395 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-26MCGR: Border restoration supportArmin Le Grand (allotropia)
Due to tdf#155362 I added code to be able in case we would need it to convert a BGradient using added tooling from having offsets in the GradientSteps and no border to adapted GradientSteps and border. This is preferrable due to our GradientStyle_RECT (and GradientStyle_ELLIPTICAL too) use that 'non- linear' paint aka move-two-pixels-inside, someone else called it 'frame-paint'. This does not bode well with the border being applied 'linear' at the same time (argh). Thus - while in principle all is correct when re-importing a GradientStyle_RECT with a border after export to pptx, it looks slightly better ('correcter') wen doing so. That is because when being able to and restoring a border at least that border part *is* applied linearly. I took the chance to further apply tooling, move it to classes involved and instead of awt::Gradient2 use more basegfx::BGradient since it can and does host tooling. This is also a preparation to be able to adapt (restore) border in case of turn- around in ODF where the importing instance is before MCGR existance and has to handle Start/EndColor. Needed to take more care with using BGradient instead of awt::Gradient2 for initialization, also better dividing/organization of tooling, already preparation to use for other purposes. Change-Id: I2d3a4240a5ac6fff9211b46642ee80366dc09e3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152194 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-19MCGR: Adaptions to WriteGradientFill and BGradientArmin Le Grand (allotropia)
Added code to make WriteGradientFill directly use the available BGradient implementation. The goal is to never directly work on awt::Gradient2, but use BGradient & it's tooling methods. Added constructors and tooling to BGradient and BColorStops to make that easier (single line conversions between uno::Any, basesgfx classes and awt:: incarnations). Directly handle uno::Any and awt:: classes, changed stuff to make use of this. Change-Id: I083a323b9efee8ca4f3becb2966aac0a294b9a60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151842 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-16Fix typoAndrea Gelmini
Change-Id: Ibbf9a267bbfba02c119fa1995c6b2ae90f391031 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151813 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-16Fix typoAndrea Gelmini
Change-Id: Ibb3cbd37e04beed410c61f93f35be51a59bdc10b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151808 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-16Fix typoAndrea Gelmini
Change-Id: I126f38c126c3f541d451cdafa074d2b8c0248d05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151815 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-15MCGR: consolidations/cleanups for changes so farArmin Le Grand (allotropia)
Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>