Re: tdf96324
Hi, I've attached a small example to the bug: two text blocks M_N (subscript), one rotated one plain. In SVGTextWriter::implWriteTextPortion we see the coordinates where the text portions are positioned: rotated: M (443,5096), N (559, 4808) ->y coordinate of N should increase instead of decrease compared to y coordinate of M plain: M (250, 443), N (542, 559)-> the delta in x is 292 compared to 161 in the rotated case, which is too small. Armin, do you have a code pointer for me, where these numbers are calculated? Regards, Christina Am 29.10.2017 um 13:40 schrieb Christina Roßmanith: > Hi, > > I'm having a look at bug tdf96324. The problem is that when exporting an > ODG to SVG the subscript 'N' from a rotated axis label isn't visible in > the exported SVG. It is exported but with coordinates which are way off. > > As far as I understand the ODG document is converted to a metafile and > this is exported to SVG. The coordinates in the metafile are wrong so I > would like to see how the metafile is created. > > Any hints where I might start to search? > > Christina > > > > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/libreoffice > signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
tdf96324
Hi, I'm having a look at bug tdf96324. The problem is that when exporting an ODG to SVG the subscript 'N' from a rotated axis label isn't visible in the exported SVG. It is exported but with coordinates which are way off. As far as I understand the ODG document is converted to a metafile and this is exported to SVG. The coordinates in the metafile are wrong so I would like to see how the metafile is created. Any hints where I might start to search? Christina signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
build fails in postprocess/qa/services.cxx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, for quite a while I have the following problem: branch: master ./g pull -r make fails in postprocess/qa/services.cxx with error message: services.cxx:231:Assertion Test name: (anonymous namespace)::Test::test forced failure - - creating com.sun.star.wizards.agenda.CallWizard caused com.sun.star.uno.RuntimeException unsatisfied query for interface of type com.sun.star.loader.XImplementationLoader! Before that I get lots of messeage like no obvious way to instantiate implementation com.sun.star.i18n.Transliteration.ignoreSpace_ja_JP no obvious way to instantiate implementation com.sun.star.i18n.Transliteration.ignoreTiJi_ja_JP no obvious way to instantiate implementation com.sun.star.i18n.Transliteration.ignoreTraditionalKana_ja_JP no obvious way to instantiate implementation com.sun.star.i18n.Transliteration.ignoreTraditionalKanji_ja_JP no obvious way to instantiate implementation com.sun.star.i18n.Transliteration.ignoreZiZu_ja_JP no obvious way to instantiate implementation com.sun.star.i18n.Transliteration.largeToSmall_ja_JP no obvious way to instantiate implementation com.sun.star.i18n.Transliteration.smallToLarge_ja_JP no obvious way to instantiate implementation com.sun.star.office.comp.Acceptor no obvious way to instantiate implementation com.sun.star.office.comp.PipeSplashScreen no obvious way to instantiate implementation com.sun.star.office.comp.SplashScreen no obvious way to instantiate implementation com.sun.star.report.comp.ReportToolboxController no obvious way to instantiate implementation com.sun.star.report.comp.StatusbarController no obvious way to instantiate implementation com.sun.star.script.framework.security.SecurityDialog no obvious way to instantiate implementation com.sun.star.script.provider.ScriptURIHelper no obvious way to instantiate implementation com.sun.star.sdb.ApplicationToolboxController no obvious way to instantiate implementation com.sun.star.svtools.OfficeFilePicker no obvious way to instantiate implementation com.sun.star.svtools.OfficeFolderPicker Any hint what is going wrong here? Usually I disabled the test, fixed some bug, pushed my fix and after ./g pull -r I had to disable the test again. But clearly that is far from being optimal... Christina -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVBJ69AAoJEN/hiApPuw9SrNsIAK7CCi7QyW0ZtHHoM+PUWE+3 eIXTJRuRRJkBRp5gkQMNsWaNU9IpQDJJd6g/s9j5yFyGrY0bSIi/dps0XaUUudZV r/9jUTQZ30YK4KNHd0cNq1gm2Z5HtDlkFPQw7lJRRFR7f20fjMv4hH7HVUGZ7o8S NL+dw9+4EMPkiOI4suUSPitEXHfP1zHgsdFFucaOAO7T6265gDmdU2tEEn8MA09D UrashmSn22ahU4/peSTyKKxEcTUzeN46wlE8tZV7Ny4Gn7dlCQpeiwJANSj4BUth 1Nh6teBB6YpOueBseFkUnOliswaOtWPtiWrbO5WMKYCNCCn8R2xpAP4HzyxMwm4= =4JsZ -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bug 64075: code pointer needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, opening homenet.svg (attached to the bug) shows the circles without a filling but filled circles would be correct. The reason (I guess) is that each circle is represented as 4 bezier curves which make it a manually closed polygon but not a closed polygon. So my question is: Where can I find the code responsible for filling polygons (and where probably polygons are being tested as being closed but not manually closed)? Christina -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUx/wgAAoJEN/hiApPuw9SH0AH/RMZRqLH068qwwR7zAy2+gp4 2Pa6lv1JA9G1J9PlbEqTpXCMTD5BzumLIEOxOgDa2hgCUha2zoulMTsiOTSFHnXk p6s/CQwn9zzuIgWrluix/5l8tjJArqK49pT0F16vweRqWleAUx4IgMhZOdBCnn4Z N5bJk+uYC7mEirA8OY8CQ9Mb8FGLFALTPhrft4f3pt0ZW682FOiZ7pcb4oZdVS+5 hfAsFq9TeMqUGt6WQ7dIYgzEoI/WQv+GmoSVo+haPT1SsAwf/DqEMjkEDRypNa4e XMALoUlkOBrgJZ4A3l9WOvqOC0IXs71683JHcKOBmaE/sV69GGGAS+CenoYz0Xw= =do1t -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: About Svgreader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.04.2014 22:22, schrieb julien2412: Hello, Reading bugtrackers about SVG, I noticed there were 2 locations with svgreader: - filter/source/svg/svgreader.cxx This is used for File-Open and then choosing the svg file. - svgio/source/svgreader (there's also svgio/source/svguno) This is used for Insert-Picture-From File. And that is the reason why some bugs appear only with opening or inserting a svg graphic. Christina There's no README for svgio/ and the README of filter isn't detailed. Someone to explain (perhaps update/add README)? Above all, what part is used to read svg? Julien -- View this message in context: http://nabble.documentfoundation.org/About-Svgreader-tp4107050.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTYY02AAoJEN/hiApPuw9S3XcH/3J27/t4/kzQt5Advv6wHTwZ nsH3tA/Qz6LBK+nMRv7MyfwH4UPuzNPE4DBs+03MMU7pqDSiA6WO42IVVyvGgeys vwkwhKPaC0lo0HIF7ELgGb0z8e9T9K+XOrI7E9j2EkX5/f2WtTxWjzu6Tu5GuM5f /l2E4eH/qFFf0w5eavLfUry16OcgYx7oPcjXfScSUoshoQwVOwg3cuAju6yc9O7k AbG1hee6CHprm7QAZ/oA6lI4EvZNnYzwYalSwIpwLqRBwKCzv0DwRzosj+WuoQQL 8/LA3TKmD/iwIFkr8W46qipZQhjTZsbQW2b0vobZ3XNgRdUMeWuZ6r7ZTTMz8qc= =Thmb -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PUSHED] [PATCH] fdo#39468 German comments for svx/source/tbxctrls/itemwin.cxx
Hi Laurent, thank you for your patch! It has been merged to LibreOffice. Christina On 14/09/13 15:54, Laurent BP wrote: Hello, Here is a patch to translate German comments on the file I'm working on. 0001-fdo-39468-Translate-German-comments-in-itemwin.cxx.patch http://nabble.documentfoundation.org/file/n4074171/0001-fdo-39468-Translate-German-comments-in-itemwin.cxx.patch Laurent BP - LibreOffice 4.1.1.2 -- View this message in context: http://nabble.documentfoundation.org/PATCH-fdo-39468-German-comments-for-svx-source-tbxctrls-itemwin-cxx-tp4074171.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
SVG: scaling if no width/height is given
Hi, the problem described here - https://bugs.freedesktop.org/show_bug.cgi?id=64125 is caused by a missing width and height attribute of the SVG given as an example. So, what would we expect given a ViewBox attribute when importing a graphic? What I'd expect is that the aspect ratio is kept and a reasonable scaling is applied in order to fill a page, table cell or whatever. And that the little green squares (handles?) behave like a bounding box for the graphic content. Is that correct? What I've achieved so far is the correct scaling. What I'm looking for is where the total size of the graphic is still determined wrong (see attached screenshot) - little green squares are more like DIN A4 than the ViewBox size. Christina attachment: Bug_SVG.png___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
fdo#64897
Hi, commit abb6f47bd3941ec63a41a9b9fa4c7de620b5177d causes the crash when saving as ppt (see bug description). I'm having a look at it but I'm not sure if I can figure out what is going wrong. Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
bisect related question
Hi, some questions arise during git bisect: 1. Will each build get an unique build id? Is this id related to the most recent commit? 2. Does make tail_build.clean; make tail_build require make dev-install afterwards? 3. Do get a faster build: How can I get rid of slowcheck? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
bibisect related question
Hi, I've completed my first bibisect successfully. Now I have a range of commits to have a closer look at. I thought to create a branch reflecting the last good point and cherry-pick commits to see when the bug occurs again. But that branch does not build, it fails somewhere in libxmlsec so I decided to take the first bad point. This one builds but during make dev-install it fails with : * : ERROR: ERROR: Missing files at /home/cr/Software/LibO2/core/solenv/bin/modules/installer/scriptitems.pm line 1311 : * Now I'm lost. What are the autogen.sh options used to create the bibisect builds? I've assumed that all states stored in bibisect are buildable ... Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Help needed for fdo#63311
Hi, if you add text (e.g. abc) to a shape like a smiley, save the document, delete the text and save again the text is still present in the saved file. Closing the drawing isn't necessary. If you don't save the drawing after adding the text but delete the text and save the drawing afterwards the text isn't present in the written file. In shapeexport.cxx at line 242 if(xText.is() !xText-getString().isEmpty()) xText-getString() evaluates to abc if the drawing was saved even if the text was deleted. So I guess something happens to the text during saving (because saving is necessary to trigger the wrong behaviour) and this something isn't updated properly if the text is deleted. And this is where I am stuck but maybe my findings ring some bells for someone else? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
return value of GetTextBreak()
Hi, GetTextBreak() returns STRING_LENGTH if text breaking isn't necessary (if I get it right). indexOf() returns -1 if searching failed. Would that be a choice for GetTextBreak() as well? What would be a useful return value? sal_Int16, sal_Int32? In GenericSalLayout int is chosen as return type. In OutputDevice xub_StrLen is chosen... Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] add copy() and toInt32() to OUStringBuffer
Please ignore this one. https://gerrit.libreoffice.org/#/c/2229/ is the one I'd like to get reviewed. Christina Am 01.03.2013 21:55, schrieb Christina Roßmanith (via Code Review): Hello LibreOffice gerrit bot, Norbert Thiebaud, I'd like you to reexamine a change. Please visit https://gerrit.libreoffice.org/2125 to look at the new patch set (#5). Change subject: add copy() and toInt32() to OUStringBuffer .. add copy() and toInt32() to OUStringBuffer Change-Id: Ibac7f624f1a1dcce653dff4bec573be457d70075 --- M sal/inc/rtl/ustrbuf.hxx 1 file changed, 56 insertions(+), 0 deletions(-) git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/25/2125/5 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] replace (Xub)String with OUString in vcl
Hi,
when changing (Xub)String to OUString I came across a strange for-loop.
You find it at the end of the quotation. I've kept some context...
(continue below the quotation)
diff --git a/vcl/source/control/field.cxx b/vcl/source/control/field.cxx
index 387acea..e632b4a 100644
--- a/vcl/source/control/field.cxx
+++ b/vcl/source/control/field.cxx
@@ -89,29 +89,29 @@
// ---
-static sal_Bool ImplNumericGetValue( const XubString rStr, double rValue,
+static sal_Bool ImplNumericGetValue( const OUString rStr, double rValue,
sal_uInt16 nDecDigits, const
LocaleDataWrapper rLocaleDataWrappper,
sal_Bool bCurrency = sal_False )
{
-XubString aStr = rStr;
-XubString aStr1;
+OUString aStr = rStr;
+OUString aStr1;
rtl::OUStringBuffer aStr2;
sal_BoolbNegative = sal_False;
-xub_StrLen nDecPos;
+sal_Int32 nDecPos;
// react on empty string
-if ( !rStr.Len() )
+if ( rStr.isEmpty() )
return sal_False;
// remove leading and trailing spaces
-aStr = string::strip(aStr, ' ');
+aStr = aStr.trim();
// find position of decimal point
-nDecPos = aStr.Search( rLocaleDataWrappper.getNumDecimalSep() );
-if ( nDecPos != STRING_NOTFOUND )
+nDecPos = aStr.indexOf( rLocaleDataWrappper.getNumDecimalSep() );
+if ( nDecPos = 0)
{
-aStr1 = aStr.Copy( 0, nDecPos );
-aStr2.append(aStr.Copy(nDecPos+1));
+aStr1 = aStr.copy( 0, nDecPos );
+aStr2.append(aStr.getStr()+nDecPos+1);
}
else
aStr1 = aStr;
@@ -119,32 +119,32 @@
// negative?
if ( bCurrency )
{
-if ( (aStr.GetChar( 0 ) == '(') (aStr.GetChar( aStr.Len()-1 ) ==
')') )
+if ( aStr.startsWith(() aStr.endsWith()) )
bNegative = sal_True;
if ( !bNegative )
{
-for (xub_StrLen i=0; i aStr.Len(); i++ )
+for (sal_Int32 i=0; i aStr.getLength(); i++ )
{
-if ( (aStr.GetChar( i ) = '0') (aStr.GetChar( i ) = '9') )
+if ( (aStr[i] = '0') (aStr[i] = '9') )
break;
-else if ( aStr.GetChar( i ) == '-' )
+else if ( aStr[i] == '-' )
{
bNegative = sal_True;
break;
}
}
}
-if ( !bNegative bCurrency aStr.Len() )
+if ( !bNegative bCurrency !aStr.isEmpty() )
{
sal_uInt16 nFormat = rLocaleDataWrappper.getCurrNegativeFormat();
-if ( (nFormat == 3) || (nFormat == 6) ||
- (nFormat == 7) || (nFormat == 10) )
+if ( (nFormat == 3) || (nFormat == 6) || // $1- || 1-$
+ (nFormat == 7) || (nFormat == 10) ) // 1$- || 1 $-
{
-for (xub_StrLen i = (xub_StrLen)(aStr.Len()-1); i 0; i++ )
+for (sal_Int32 i = aStr.getLength()-1; i 0; i++ )
{
-if ( (aStr.GetChar( i ) = '0') (aStr.GetChar( i ) =
'9') )
+if ( (aStr[i] = '0') (aStr[i] = '9') )
break;
-else if ( aStr.GetChar( i ) == '-' )
+else if ( aStr[i] == '-' )
{
bNegative = sal_True;
break;
In
for (sal_Int32 i = aStr.getLength()-1; i 0; i++ )
i starts with at least -1 is tested to be non negative and incremented.
Is this code ever used??? Or am I failing to see the magic behind the
scenes?
Christina
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] replace (Xub)String with OUString in vcl
Hi Eike,
Am 06.02.2013 13:38, schrieb Eike Rathke:
Hi Christina,
On Wednesday, 2013-02-06 12:36:33 +0100, Christina Roßmanith wrote:
-for (xub_StrLen i = (xub_StrLen)(aStr.Len()-1); i 0; i++ )
+for (sal_Int32 i = aStr.getLength()-1; i 0; i++ )
{
-if ( (aStr.GetChar( i ) = '0') (aStr.GetChar( i ) =
'9') )
+if ( (aStr[i] = '0') (aStr[i] = '9') )
break;
-else if ( aStr.GetChar( i ) == '-' )
+else if ( aStr[i] == '-' )
{
bNegative = sal_True;
break;
In
for (sal_Int32 i = aStr.getLength()-1; i 0; i++ )
i starts with at least -1 is tested to be non negative and
incremented. Is this code ever used??? Or am I failing to see the
magic behind the scenes?
No, that code doesn't make sense and to me looks it should be
for (sal_Int32 i = aStr.getLength()-1; i 0; --i)
Awkward guessing of negative currency formats anyway..
Do you think it is ever used? It would be an endless loop, wouldn't
it?!? The question is modify to --i or remove some code.
Well there are lots of formats for negativ currencies:
-if ( (nFormat == 3) || (nFormat == 6) ||
- (nFormat == 7) || (nFormat == 10) )
+if ( (nFormat == 3) || (nFormat == 6) || // $1- || 1-$
+ (nFormat == 7) || (nFormat == 10) ) // 1$- || 1 $-
I've added them as a comment because the numerical codes for the various
formats are quite non intuitive.
Christina
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Duplicate code? Call for #define xxx_PAGETYPE_xxx
Hi, I had a look at cui/source/tabpages/tpline.cxx and found two identical blocks in sal_Bool SvxLineTabPage::FillItemSet( SfxItemSet rAttrs ) around lines 767 and 871. Could someone confirm (and maybe explain) that this is intentional. And code like if( nDlgType != 0 || nPageType != 3 ) is difficult to read. There are constants defined in source/tabpages/numpages.cxx, e.g. #define NUM_PAGETYPE_BULLET 0 but I don't know if those match the ones used in tpline.cxx. Anybody who is knowing what is going on here willing to spend some #defines or clearify if those from numpages.cxx are valid? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
gifread.cxx: Netscape 2.0
Hi, during RTL_CONSTASCII... cleaning I came across this lines in vcl/source/filter/igif/gifread.cxx: if( (aAppId == NETSCAPE) (aAppCode == 2.0) (cSize == 3) )... Will this condition ever be true? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Gradient data structure
Hi, there is some progress in svg:linearGradient import. But that gradient type is more flexible than the existing draw:gradient. That rises the question: Should I extend the existing data structure or add a SvgGradient data structure? Christina Rossmanith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gradients
Am 17.09.2012 09:04, schrieb Fridrich Strba: Hello, Christina, On 14/09/12 22:12, Christina Roßmanith wrote: 1. Created by LibreOffice (create rectangle in Draw, fill with a blue to green gradient, save as fodg) draw:gradient draw:name=Gradient_20_7 draw:display-name=Gradient 7 draw:style=linear draw:start-color=#ff draw:end-color=#00ff00 draw:start-intensity=100% draw:end-intensity=100% draw:angle=0 draw:border=0%/ 2. Modified by me to use svg:linearGradient instead of draw:gradient (rendered as a grey to white gradient, clearly has to be improved :-) ) svg:linearGradient draw:name=Gradient_20_7 draw:display-name=Gradient 7 svg:stop svg:offset=0 svg:stop-color=#ff svg:stop-opacity=100% / svg:stop svg:offset=1 svg:stop-color=#00ff00 svg:stop-opacity=100% / /svg:linearGradient Now, the problem we have is that we don't parse the svg:xxxGradient element and its nested elements. And since we still have in the shape fill:gradient, it will fill it with a default gradient which is basically white to black. I know that we don't parse them (but I didn't know about the default gradient). My intention is to create an example which is expected to work and make it work next. In a second step the svg import filter should use svg:xxxGradient. Christina The idea would be to make the xmloff understand that notation and at least import it in the same way we import the gradients in svg files. Cheers Fridrich ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Gradients
Hi, I'll have a look at gradients again. Could someone please have a look at the following two gradient specifications and tell me if they are supposed to look the same: 1. Created by LibreOffice (create rectangle in Draw, fill with a blue to green gradient, save as fodg) draw:gradient draw:name=Gradient_20_7 draw:display-name=Gradient 7 draw:style=linear draw:start-color=#ff draw:end-color=#00ff00 draw:start-intensity=100% draw:end-intensity=100% draw:angle=0 draw:border=0%/ 2. Modified by me to use svg:linearGradient instead of draw:gradient (rendered as a grey to white gradient, clearly has to be improved :-) ) svg:linearGradient draw:name=Gradient_20_7 draw:display-name=Gradient 7 svg:stop svg:offset=0 svg:stop-color=#ff svg:stop-opacity=100% / svg:stop svg:offset=1 svg:stop-color=#00ff00 svg:stop-opacity=100% / /svg:linearGradient Thank you, Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] page borders (bug 52327)
Hi Regina, to make sure we are talking about the same page borders: there are slightly thicker lines in normal view indicating what is printed on a page. But they appear only after print preview for a sheet was executed. If the bug reporter confirmes that print preview works for him I'll close the bug with NOTABUG - any objections? Christina ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] page borders (bug 52327)
Hi, I had a look at fdo52327 and have some questions: 1. Should page preview trigger the calculation of page borders? 2. If so, should it be a trigger for the current sheet only or for all sheets? Christina Rossmanith ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Draw and gradient opacity
Hi, obviously I'm working with gradients at the moment :-) and I'm in need of a code pointer again. I've created a rectangle in Draw (manually - no svg import this time), filled it with a linear gradient with a constant 50% opacity and saved the file as fodg. Then I saw that opacity is stored at two places in the file: 1. in the gradient definition (draw:start-intensity=50% draw:end-intensity=50%) 2. in the rectangle style (draw:opacity=50%) If I remove it in the rectangle style and re-open the fodg file the rectangle isn't filled transparently anymore, i.e. the opacity in the gradient definition is ignored. So my question is: Which code is responsible for reading fodg files (to check if start-intensity and end-intensity are processed at all) and which code does the painting? Hope that I've used the correct terms... Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
gradient angles
Hi, just to be sure before I continue my work: SVG gradient with angle=0° changes color from left to right (I'm taking this from http://www.w3.org/TR/SVG/pservers.html#LinearGradientElement) ODF gradient with angle=0° changes color from top to bottom (I can't find any meaning of the angle attribute here http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416460_253892949) Is this correct? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: gradient angles
Am 29.07.2012 18:25, schrieb Regina Henschel: Hi Christina, I'm not sure about what you want to know. Christina Roßmanith schrieb: Hi, just to be sure before I continue my work: SVG gradient with angle=0° changes color from left to right (I'm taking this from http://www.w3.org/TR/SVG/pservers.html#LinearGradientElement) The svg:gradient does not has an angle, but a start point and an end point. The start point has the color of the 0%-stop color and the end point has the color of the 100%-stop color. You are right, there is no angle but transforms are applied to the gradient vector (and normal). So the question is what is the direction of the gradient vector in absence of any transform and the w3c test suite gives the answer: from left to right (along the positive x axis?) ODF gradient with angle=0° changes color from top to bottom (I can't find any meaning of the angle attribute here http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416460_253892949) I think, that the specification is not clear about the untransformed direction of the gradient vector. Gradient vector is for me the direction from start color to end color in the way, that a line with points of same color is perpendicular to the gradient vector. LibreOffice handles it in the way, that the untransformed gradient vector is in direction of the positive y-axis, that is on screen from top to bottom. That means I have to rotate the gradient orientation 90° ccw when importing svg gradients. The draw:angle is the angle the gradient vector is rotated. Where it has the same rule as other rotations, that it is on screen against clock, which will be clockwise in calculation because of the top-down direction of the y-axis. LibreOffice handles the angle unit as 0.1°, whereas in ODF1.2 the angle unit defaults to 1°. That might explain why in a fodg file which I've modified by hand a gradient angle of 90 is interpreted as 9. Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
fodg + gradient + angle
Hi, a gradient angle given without a unith should be interpreted as degrees, but in my example a value of draw:angle=90 shows up in LibO as 9 degrees. If I change it to draw:angle=90deg the value is read correctly. Thus the question is: Where do I have to look to fix it? Thank you for any code pointers, Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH][REVIEW] use dash parameters from svg file
Hi,
finally a patch is ready for handling of dashes. I've removed all
polygon emulation stuff. Svg has a more flexible way to define dashes.
1. ODF only permits one constant distance between dashes. Currently the
average of all distances is taken.
2. The svg dash array is parsed up to the point where is can't be
represented by ODF parameters. That should be better than rejecting the
whole array and drawing a solid line.
3. Dash offset can't be represented at all.
Comments and nitpicking welcome...
As far as I can see now the emulated style id in the internal-style-ref
attribute isn't used anywhere (id following after '$'). Keep it or
remove it?
Christina
From 8c71ee764f06327a265e1e8d230bea9a8a7fe058 Mon Sep 17 00:00:00 2001
From: Chr. Rossmanith chrrossman...@gmx.de
Date: Fri, 15 Jun 2012 23:27:49 +0200
Subject: [PATCH] SVG: use dash parameters from svg file
Change-Id: I86b31156e1a9221d9cfdc40d5670b324ce056a89
---
filter/source/svg/gfxtypes.hxx |3 +-
filter/source/svg/svgreader.cxx | 182 ---
2 files changed, 132 insertions(+), 53 deletions(-)
diff --git a/filter/source/svg/gfxtypes.hxx b/filter/source/svg/gfxtypes.hxx
index 68463c8..7cebe1a 100644
--- a/filter/source/svg/gfxtypes.hxx
+++ b/filter/source/svg/gfxtypes.hxx
@@ -143,7 +143,8 @@ enum PaintType
{
NONE,
SOLID,
-GRADIENT
+GRADIENT,
+DASH
};
enum FillRule
diff --git a/filter/source/svg/svgreader.cxx b/filter/source/svg/svgreader.cxx
index 6db2eb0..52c2078 100644
--- a/filter/source/svg/svgreader.cxx
+++ b/filter/source/svg/svgreader.cxx
@@ -659,11 +659,17 @@ struct AnnotatingVisitor
else
xAttrs-AddAttribute( draw:fill, none);
-if( rState.meStrokeType != NONE )
+if( rState.meStrokeType == SOLID )
{
xAttrs-AddAttribute( draw:stroke, solid);
xAttrs-AddAttribute( svg:stroke-color, getOdfColor(rState.maStrokeColor));
}
+else if( rState.meStrokeType == DASH )
+{
+xAttrs-AddAttribute( draw:stroke, dash);
+xAttrs-AddAttribute( draw:stroke-dash, dash+rtl::OUString::valueOf(mnCurrStateId));
+xAttrs-AddAttribute( svg:stroke-color, getOdfColor(rState.maStrokeColor));
+}
else
xAttrs-AddAttribute( draw:stroke, none);
@@ -694,28 +700,6 @@ struct AnnotatingVisitor
void writeStyle(const uno::Referencexml::dom::XElement xElem, const sal_Int32 nTagId)
{
SAL_INFO (svg, writeStyle xElem xElem-getTagName());
-sal_Int32 nEmulatedStyleId=0;
-if( maCurrState.maDashArray.size()
-maCurrState.meStrokeType != NONE )
-{
-// ODF dashing is severly borked - generate filled shape
-// instead (further down the road - here, we simply
-// emulate a filled style with the next id)
-
-// move all stroke attribs to fill, Clear stroking
-State aEmulatedStrokeState( maCurrState );
-aEmulatedStrokeState.meFillType = maCurrState.meStrokeType;
-aEmulatedStrokeState.mnFillOpacity = maCurrState.mnStrokeOpacity;
-aEmulatedStrokeState.maFillColor = maCurrState.maStrokeColor;
-aEmulatedStrokeState.maFillGradient = maCurrState.maStrokeGradient;
-aEmulatedStrokeState.meFillRule = EVEN_ODD;
-aEmulatedStrokeState.meStrokeType = NONE;
-
-if( writeStyle(aEmulatedStrokeState, nTagId) )
-nEmulatedStyleId = mnCurrStateId;
-else
-nEmulatedStyleId = mrStates.find(aEmulatedStrokeState)-mnStyleId;
-}
sal_Int32 nStyleId=0;
if( writeStyle(maCurrState, nTagId) )
@@ -726,9 +710,7 @@ struct AnnotatingVisitor
xElem-setAttribute(internal-style-ref,
rtl::OUString::valueOf(
nStyleId)
-+$
-+rtl::OUString::valueOf(
-nEmulatedStyleId));
++$0);
}
void push()
@@ -969,12 +951,18 @@ struct AnnotatingVisitor
case XML_STROKE_DASHARRAY:
{
if( aValueUtf8 == none )
+{
maCurrState.maDashArray.clear();
+maCurrState.meStrokeType = SOLID;
+}
else if( aValueUtf8 == inherit )
maCurrState.maDashArray = maParentStates.back().maDashArray;
else
+{
parseDashArray(aValueUtf8.getStr(),
maCurrState.maDashArray);
+maCurrState.meStrokeType = DASH;
+}
break;
}
case XML_STROKE_OPACITY:
@@ -1668,32 +1656,6 @@ struct ShapeWritingVisitor
Re: gdb backtrace burpage ...
Am 13.06.2012 19:57, schrieb Tom Tromey: Michael == Michael Meeksmichael.me...@suse.com writes: Michael #2 0xb784d6f1 in SfxFrame::Create (i_rFrame=warning: RTTI symbol not Michael found for class 'framework::Frame' Michael warning: RTTI symbol not found for class 'framework::Frame' Michael warning: RTTI symbol not found for class 'framework::Frame' Michael warning: RTTI symbol not found for class 'framework::Frame' Michael But is there any way of suppressing that warning thrash for the Michael case where it is not enabled ? There's no way to disable it. File a feature request in gdb bugzilla if you want that. I looked into this a little. The warning here is peculiar. Despite what it says, gdb is not actually looking for an RTTI symbol. Instead it is just looking for the debug info for the indicated type. I don't know a simple way to reproduce this problem, or I would dig into it a bit more. My guess is that it can only be reproduced in relatively odd situations, like where you have some subset of the debuginfo, but not quite all of it. You mean if I compile only a subset of modules with dbglevel0? I'm getting the RTTI messages as well but can't remember, what I did immediately before enabling them...and I have the feeling that gdb -tui crashes quite often since then. Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#39468: translate German comments (= writer)
Hi, there is simian. Quoted from the wiki: A good copy and paste detector is [http://www.harukizaemon.com/simian/ Simian]. The use is free for non-commercial projects. To get a space separated list of .cxx files in a directory, run: find directory -name *.cxx | grep -v unxlng | tr '\n' ' ' files The Simian call to get code pieces with at least 30 equivalent lines is for example: java -jar simian-2.3.33.jar -threshold=30 -language=c++ `cat files` Christina Am 28.05.2012 15:04, schrieb Philipp Riemer: As promised, find the first few files for review attached to this mail. Btw.: I realized a lot of duplicated code in the files I checked so far in sw/source/core/undo. Having no experience in C++, I wanted to ask if there exists a good copy-paste-detection tool to find those root of evil code? Philipp Attachments: 0001-fix-german-adjust-left-margin-comment-in-multiple-files.patch 0002-translated-german-comments-in-sw-inc-docufld.hxx.patch 0003-translated-german-comments-in-sw-inc-swscanner.hxx.patch 0004-translated-german-comments-in-sw-source-core-undo-unnum.cxx.patch 0005-translated-german-comments-in-sw-source-core-undo-unattr.cxx.patch 0006-translated-german-comments-in-sw-source-core-undo-undel.cxx.patch 0007-translated-german-comments-in-sw-source-core-undo-undobj.cxx.patch 0008-translated-german-comments-in-sw-source-core-undo-undobj1.cxx.patch 0009-translated-german-comments-in-sw-source-core-undo-unins.cxx.patch 0010-translated-german-comments-in-sw-source-core-undo-rolbck.cxx.patch 0011-translated-german-comments-in-sw-source-core-undo-unmove.cxx.patch 0012-translated-german-comments-in-sw-source-core-undo-unovwr.cxx.patch 0013-translated-german-comments-in-sw-source-core-undo-unredln.cxx.patch 0014-translated-german-comments-in-sw-source-core-undo-unsect.cxx.patch 2012/5/28 Philipp Riemerruderphil...@gmail.com: After Michael Meeks' enthusiastic talks and a digital chat (sitting side by side is no reason to not type your messages ;-) with him at LinuxTag in Berlin, I got so excited about LibreOffice that I also wanted to help and participate in this project. I do not have much spare time but as I heard also the translation of parts that are still in German does help. Therefore I added my name to the corresponding wiki section https://wiki.documentfoundation.org/Development/Easy_Hacks/Translation_Of_Comments and will submit translations of the writer source code piece by piece in the following weeks as soon as I have some time to work on them. Cheers, Philipp ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW 3-5] fdo#48068 fix parsing of path d-attribute
Hi, in a svg path H 40.5.6 should be parsed in the same way as H 40.5 .6 commit bef8e358b6940fd4a976cb346dfd829643e581b8 makes the double parser stop if a second separator '.' is seen. Furthermore the test wether we are on a number returns 'true' for a '.' that parsing starts even without a digit preceding '.'. Now the w3c test paths-data-18f.svg nearly passes - there is no red anymore - but there is no gold either :-( Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
psp::PrinterInfoManager related build problems
Hi, I've made clean and still can't build LibO (error messages see below). Any idea what might be my problem? Tinderboxes are green, so master should be buildable?!? Christina home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/printerjob.o: In function `psp::PrinterJob::writeJobPatch(osl::File*, psp::JobData const)': printerjob.cxx:(.text+0x1149): undefined reference to `psp::PrinterInfoManager::get()' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/printerjob.o: In function `psp::PrinterJob::writeFeatureList(osl::File*, psp::JobData const, bool)': printerjob.cxx:(.text+0x20ea): undefined reference to `psp::PrinterInfoManager::get()' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/printerjob.o: In function `psp::PrinterJob::writeSetup(osl::File*, psp::JobData const)': printerjob.cxx:(.text+0x2371): undefined reference to `psp::PrinterInfoManager::get()' printerjob.cxx:(.text+0x238c): undefined reference to `psp::PrinterInfoManager::checkFeatureToken(rtl::OUString const, char const*) const' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/printerjob.o: In function `psp::PrinterJob::EndJob()': printerjob.cxx:(.text+0x2ad1): undefined reference to `psp::PrinterInfoManager::get()' printerjob.cxx:(.text+0x2b09): undefined reference to `psp::PrinterInfoManager::get()' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/genprnpsp.o: In function `PspSalInfoPrinter::GetCapabilities(ImplJobSetup const*, unsigned short)': genprnpsp.cxx:(.text+0xef1): undefined reference to `psp::PrinterInfoManager::get()' genprnpsp.cxx:(.text+0xf04): undefined reference to `psp::PrinterInfoManager::checkFeatureToken(rtl::OUString const, char const*) const' genprnpsp.cxx:(.text+0x1101): undefined reference to `psp::PrinterInfoManager::get()' genprnpsp.cxx:(.text+0x110d): undefined reference to `psp::PrinterInfoManager::getPrinterInfo(rtl::OUString const) const' genprnpsp.cxx:(.text+0x1199): undefined reference to `psp::PrinterInfoManager::get()' genprnpsp.cxx:(.text+0x11ac): undefined reference to `psp::PrinterInfoManager::checkFeatureToken(rtl::OUString const, char const*) const' genprnpsp.cxx:(.text+0x11ca): undefined reference to `psp::PrinterInfoManager::get()' genprnpsp.cxx:(.text+0x11dc): undefined reference to `psp::PrinterInfoManager::checkFeatureToken(rtl::OUString const, char const*) const' genprnpsp.cxx:(.text+0x11e9): undefined reference to `psp::PrinterInfoManager::get()' genprnpsp.cxx:(.text+0x11f4): undefined reference to `psp::PrinterInfoManager::getPrinterInfo(rtl::OUString const) const' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/genprnpsp.o: In function `PspSalPrinter::EndJob()': genprnpsp.cxx:(.text+0x2861): undefined reference to `psp::PrinterInfoManager::get()' genprnpsp.cxx:(.text+0x2870): undefined reference to `psp::PrinterInfoManager::getPrinterInfo(rtl::OUString const) const' genprnpsp.cxx:(.text+0x28d1): undefined reference to `psp::PrinterInfoManager::get()' genprnpsp.cxx:(.text+0x28e5): undefined reference to `psp::PrinterInfoManager::getPrinterInfo(rtl::OUString const) const' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/genprnpsp.o: In function `SalGenericInstance::GetPrinterQueueInfo(ImplPrnQueueList*)': genprnpsp.cxx:(.text+0x2d88): undefined reference to `psp::PrinterInfoManager::get()' genprnpsp.cxx:(.text+0x2ddf): undefined reference to `psp::PrinterInfoManager::listPrinters(std::listrtl::OUString, std::allocatorrtl::OUString ) const' genprnpsp.cxx:(.text+0x2e02): undefined reference to `psp::PrinterInfoManager::getPrinterInfo(rtl::OUString const) const' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/genprnpsp.o: In function `SalGenericInstance::GetDefaultPrinter()': genprnpsp.cxx:(.text+0x3009): undefined reference to `psp::PrinterInfoManager::get()' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/genprnpsp.o: In function `PrinterUpdate::doUpdate()': genprnpsp.cxx:(.text+0x3312): undefined reference to `psp::PrinterInfoManager::get()' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/genprnpsp.o: In function `PspSalPrinter::StartJob(rtl::OUString const*, rtl::OUString const, rtl::OUString const, unsigned long, bool, bool, ImplJobSetup*)': genprnpsp.cxx:(.text+0x37f1): undefined reference to `psp::PrinterInfoManager::get()' genprnpsp.cxx:(.text+0x3804): undefined reference to `psp::PrinterInfoManager::getPrinterInfo(rtl::OUString const) const' /home/cr/Software/LibO3/core/workdir/unxlngx6.pro/CxxObject/vcl/generic/print/genprnpsp.o: In function `PspSalPrinter::StartJob(rtl::OUString const*, rtl::OUString const, rtl::OUString const, ImplJobSetup*, vcl::PrinterController)': genprnpsp.cxx:(.text+0x4ab3): undefined reference to
[REVIEW 3-5] fdo#48070 fix parsing of arc paths
Hi, I've changed lcl_importNumberAndSpaces to lcl_importFlagAndSpaces because it is only used to import flags (single digit). Values != 0 or =! 1 return false as does a '-'. Now missing white space between flags isn't a problem any longer. commit 508fcf698ec7cd97af1eb8936ab30b257143bc1b Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW 3-5] SVG import improvements
Hi, commit 79a6e40e6f19a896dbc25640deb3d4507eddad95 clamps FillOpacity to 1 and commit 7c11471666f92e9dfecbec23ebe73bcb0177a963 enables parsing of percent color specifications like rgb(50%,20%,10%) Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: WaE in filter/source/svg/svgreader.cxx
Oops, that's my fault...easiest would be to remove SAL_INFO (I've
introduced it during debugging). I could do this during my next code
cleaning step. Would that be ok?
Christina
Am 08.05.2012 11:31, schrieb julien2412:
Hello,
I've got a WaE in master sources with the file
filter/source/svg/svgreader.cxx.
Here is the result of compilation :
/home/julien/compile-libreoffice/libo/filter/source/svg/svgreader.cxx: In
function ‘void svgi::{anonymous}::visitChildren(const Func,
com::sun::star::uno::Referencecom::sun::star::xml::dom::XElement,
com::sun::star::xml::dom::NodeType) [with Func =
boost::_bi::bind_trtl::OUStringBufferamp;,
boost::_mfi::mf1lt;rtl::OUStringBufferamp;, rtl::OUStringBuffer, const
rtl::OUStringamp;,
boost::_bi::list2boost::reference_wrapperlt;rtl::OUStringBuffer,
boost::_bi::bind_trtl::OUString, boost::_mfi::mf0lt;rtl::OUString,
com::sun::star::xml::dom::XNode, boost::_bi::list1boost::arglt;1
]’:
/home/julien/compile-libreoffice/libo/filter/source/svg/svgreader.cxx:1506:59:
instantiated from here
/home/julien/compile-libreoffice/libo/filter/source/svg/svgreader.cxx:138:691:
error: passing ‘com::sun::star::xml::dom::NodeType’ chooses ‘int’ over
‘unsigned int’ [-Werror=sign-promo]
/home/julien/compile-libreoffice/libo/filter/source/svg/svgreader.cxx:138:691:
error: in call to ‘std::basic_ostream_CharT, _Traits
std::basic_ostream_CharT, _Traits::operator(int) [with _CharT = char,
_Traits = std::char_traitschar]’ [-Werror=sign-promo]
cc1plus: all warnings being treated as errors
make[1]: ***
[/home/julien/compile-libreoffice/libo/workdir/unxlngx6/CxxObject/filter/source/svg/svgreader.o]
Erreur 1
make: *** [filter] Erreur 2
Here are the lines :
136 for( sal_Int32 i=0; inNumNodes; ++i )
137 {
138 SAL_INFO(quot;svgquot;,quot;node type:quot;lt;lt;
xChildren-item(i)-getNodeType() tag name
xChildren-item(i)-getNodeName() value |
xChildren-item(i)-getNodeValue() |);
If either i put a static_cast with sal_Int32 or sal_uInt32 for
xChildren-item(i)-getNodeType(), compilation works.
But I read this link
http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.19 and NodeType is
an enumeration if I don't mistake.
So what's the best way to remove this WaE ?
Julien.
PS : of course it's just a WaE so not urgent at all :-)
--
View this message in context:
http://nabble.documentfoundation.org/WaE-in-filter-source-svg-svgreader-cxx-tp3970842.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
SVG: stroke-width and scale
Hi, what influence is anisotropic scaling supposed to have on stroke-width? Given a line g transform=translate(60,-30) scale(8,2) path d=M 20 40 H 40 stroke-width=4 stroke=black / /g Currently stroke-width in this example get scaled to 8*4=32 which seems to be incorrect to me. If it gets scaled at all it should get the scaling perpendicular to the line direction, i.e. 2*4=8. Any thoughts? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] Move polygon creation from rect attrs into helper method
Then let's bury ShapeRenderingVisitor as well...(already commited locally) Christina Am 03.05.2012 11:40, schrieb Thorsten Behrens: Christina Roßmanith wrote: @Thorsten: The method importSVG which calls the ShapeRenderingVisitor is used for magic file type detection? Hi Christina, nah, type detection happens in filter/source/svg/svgfilter.cxx's SVGFilter::detect() - and is rather crude. ;) And good catch wrt. importSVG(), that once did the metafile import, for embedding an svg as a graphic - that should nowadays be dead code can go, we have vcl/source/gdi/rendergraphicrasterizer.cxx doing that. Cheers, -- Thorsten ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
SVG: tspan
Hi, consider the following SVG example: svgtexttspanq/tspan/text/svg which is rendered blank instead of showing the letter 'q'. tspan prevents q being added to sText here (svgreader.cxx): visitChildren(boost::bind( (rtl::OUStringBuffer (rtl::OUStringBuffer::*)(const rtl::OUString str))rtl::OUStringBuffer::append, boost::ref(sText), boost::bind(xml::dom::XNode::getNodeValue, _1)), xElem, xml::dom::NodeType_TEXT_NODE); In visitChildren() an output of getNodeValue() shows that tspan has an empty value. Who is responsible for that??? I'd expect a value q. Node type is NodeType_ELEMENT_NODE. Is that what is expected? Or should tspan and text both be treated as NodeType_TEXT_NODE? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
SVG: scale question
Hi, what influence does a scale g transform=scale(sx,sy) textfoo/text /g have on font size of foo if sx!=sy? (I'm close to render coords-trans-03-t.svg as expected :-) ) Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] SVG: text elements and graphic elements should not share style ids
...because the text style gets some properties added after style id
lookup. That leads to a stroke=none and fill=none style for a
rectangle following a text element with identical style.
With this patch the rectangle gets its own styleid and is rendered
correctly :-)
This is another step towards rendering coords-trans-03-t.svg as
expected...next step: text placement.
Christina
From b4a26d95edee5591fcf3f434628d29d8b52f6923 Mon Sep 17 00:00:00 2001
From: Chr. Rossmanith chr.rossman...@gmx.de
Date: Sun, 29 Apr 2012 22:12:29 +0200
Subject: [PATCH] SVG: text elements and graphic elements should not share
style ids
---
filter/source/svg/gfxtypes.hxx |8 ++--
filter/source/svg/svgreader.cxx |7 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/filter/source/svg/gfxtypes.hxx b/filter/source/svg/gfxtypes.hxx
index 24c4cbd..daca2be 100644
--- a/filter/source/svg/gfxtypes.hxx
+++ b/filter/source/svg/gfxtypes.hxx
@@ -173,10 +173,11 @@ struct State
maTransform(),
maViewport(),
maViewBox(),
+mbIsText(false),
maFontFamily(), // app-default
mnFontSize(0),
-maFontStyle(RTL_CONSTASCII_USTRINGPARAM(normal)),
-maFontVariant(RTL_CONSTASCII_USTRINGPARAM(normal)),
+maFontStyle(normal),
+maFontVariant(normal),
mnFontWeight(400.0),
meTextAnchor(BEFORE),
meTextDisplayAlign(BEFORE),
@@ -211,6 +212,7 @@ struct State
basegfx::B2DRange maViewport;
basegfx::B2DRange maViewBox;
+boolmbIsText;
rtl::OUString maFontFamily;
/** Absolute: xx-small=6.94 | x-small=8.33 | small=10 | medium=12 | large=14.4 | x-large=17.28 | xx-large=20.736
@@ -263,6 +265,7 @@ inline bool operator==(const State rLHS, const State rRHS )
rLHS.maTransform==rRHS.maTransform
rLHS.maViewport==rRHS.maViewport
rLHS.maViewBox==rRHS.maViewBox
+rLHS.mbIsText==rRHS.mbIsText
rLHS.maFontFamily==rRHS.maFontFamily
rLHS.mnFontSize==rRHS.mnFontSize
rLHS.maFontStyle==rRHS.maFontStyle
@@ -309,6 +312,7 @@ struct StateHash
^ size_t(rState.maViewport.getHeight())
^ size_t(rState.maViewBox.getWidth())
^ size_t(rState.maViewBox.getHeight())
+^ size_t(rState.mbIsText)
^ size_t(rState.maFontFamily.hashCode())
^ size_t(rState.mnFontSize)
^ size_t(rState.maFontStyle.hashCode())
diff --git a/filter/source/svg/svgreader.cxx b/filter/source/svg/svgreader.cxx
index dfb33c8..2c0c09b 100644
--- a/filter/source/svg/svgreader.cxx
+++ b/filter/source/svg/svgreader.cxx
@@ -521,8 +521,12 @@ struct AnnotatingVisitor
rtl::ReferenceSvXMLAttributeList xAttrs( new SvXMLAttributeList() );
uno::Referencexml::sax::XAttributeList xUnoAttrs( xAttrs.get() );
+if (XML_TEXT == nTagId)
+rState.mbIsText = true;
std::pairStatePool::iterator,
bool aRes = mrStates.insert(rState);
+SAL_INFO (svg, size mrStates.size() idconst_castState(*aRes.first).mnStyleId);
+
if( !aRes.second )
return false; // not written
@@ -530,6 +534,8 @@ struct AnnotatingVisitor
// mnStyleId does not take part in hashing/comparison
const_castState(*aRes.first).mnStyleId = mnCurrStateId;
+SAL_INFO (svg, --const_castState(*aRes.first).mnStyleId);
+
mrStateMap.insert(std::make_pair(
mnCurrStateId,
rState));
@@ -750,6 +756,7 @@ struct AnnotatingVisitor
void writeStyle(const uno::Referencexml::dom::XElement xElem, const sal_Int32 nTagId)
{
+SAL_INFO (svg, writeStyle xElem xElem-getTagName());
sal_Int32 nEmulatedStyleId=0;
if( maCurrState.maDashArray.size()
maCurrState.meStrokeType != NONE )
--
1.7.9.5
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Correct handling of corner radii of rectangles
Hi, in createPolygonFromRect the interval [0,1] is scaled to [width/2,height/2]. Hence rx and ry have to be divided by width/2 and height/2 respectively - I totally agree with Marco (cf. Re: svgreader.cxx: XML_RECT question). The attached rounded_rect.svg tests the case that rx=width/2 and ry=height/2 which should be rendered as an ellipse. Christina From aef35520a80a7660c51bbe4a8faf40951abddb86 Mon Sep 17 00:00:00 2001 From: Chr. Rossmanith chr.rossman...@gmx.de Date: Sat, 28 Apr 2012 19:41:35 +0200 Subject: [PATCH] Correct handling of corner radii of rectangles --- filter/source/svg/svgreader.cxx |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/filter/source/svg/svgreader.cxx b/filter/source/svg/svgreader.cxx index f6dc668..23794a7 100644 --- a/filter/source/svg/svgreader.cxx +++ b/filter/source/svg/svgreader.cxx @@ -1335,7 +1335,7 @@ struct ShapeWritingVisitor basegfx::B2DPolygon aPoly; aPoly = basegfx::tools::createPolygonFromRect( basegfx::B2DRange(x,y,x+width,y+height), -rx/width, ry/height ); +rx/(0.5*width), ry/(0.5*height) ); writePathShape(xAttrs, xUnoAttrs, @@ -2179,7 +2179,7 @@ struct ShapeRenderingVisitor basegfx::B2DPolygon aPoly; aPoly = basegfx::tools::createPolygonFromRect( basegfx::B2DRange(x,y,x+width,y+height), -rx, ry ); +rx/(0.5*width), ry/(0.5*height) ); renderPathShape(basegfx::B2DPolyPolygon(aPoly)); break; -- 1.7.9.5 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] enable rendering of text without any attributes
Hi,
text without attributes is displayed now.
Christina
From 6eb292d4c3e64f686b4d6c9ad43ae101228e6941 Mon Sep 17 00:00:00 2001
From: Chr. Rossmanith chr.rossman...@gmx.de
Date: Sat, 28 Apr 2012 20:36:54 +0200
Subject: [PATCH] enable rendering of text without any attributes
---
filter/source/svg/svgreader.cxx | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/filter/source/svg/svgreader.cxx b/filter/source/svg/svgreader.cxx
index 357c732..dfb33c8 100644
--- a/filter/source/svg/svgreader.cxx
+++ b/filter/source/svg/svgreader.cxx
@@ -207,8 +207,24 @@ struct AnnotatingVisitor
maParentStates.push_back(rInitialState);
}
-void operator()( const uno::Referencexml::dom::XElement )
-{}
+void operator()( const uno::Referencexml::dom::XElement xElem)
+{
+const sal_Int32 nTagId(getTokenId(xElem-getTagName()));
+if (nTagId != XML_TEXT)
+return;
+
+maCurrState = maParentStates.back();
+maCurrState.maTransform.identity();
+maCurrState.maViewBox.reset();
+// set default font size here to ensure writing styles for text
+if( !mbSeenText XML_TEXT == nTagId )
+{
+maCurrState.mnFontSize = 12.0;
+mbSeenText = true;
+}
+// if necessary, serialize to automatic-style section
+writeStyle(xElem,nTagId);
+}
void operator()( const uno::Referencexml::dom::XElement xElem,
const uno::Referencexml::dom::XNamedNodeMap xAttributes )
--
1.7.9.5
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
svgreader.cxx: XML_RECT question
Hi, there are two case XML_RECT blocks in svgreader.cxx in two different visitors. The ShapeWritingVisitor scales rx and ry with width and height, the ShapeRenderingVisitor does not apply any scaling. I guess both visitors should treat rx and ry the same way? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Need help: SVG import
That hint helped :-) Now text without any attributes is rendered as well. Christina Am 25.04.2012 13:23, schrieb Marco Cecchetti: After giving a better look, I could have found where the problem is: look at the begin of visitElements routine (line 101): if( xElem-hasAttributes() ) rFunc(xElem,xElem-getAttributes()); else rFunc(xElem); The function called in case the element has at least one attribute or no atribute at all are different. In the first case ShapeWritingVisitor method: void operator()( const uno::Referencexml::dom::XElement xElem, const uno::Referencexml::dom::XNamedNodeMap xAttributes ); is called in the second case the method invoked is: void operator()( const uno::Referencexml::dom::XElement ) that has an empty body (line 1204), so when your example is processed nothing happens. The rationale should be that an element without any attribute does not bring any info to parse. But for a text or tspan element is different because of the characters included between the start and the end tag. -- Marco On Wed, 25 Apr 2012 13:03:08 +0200, Marco Cecchetti mrcek...@gmail.com wrote: That's odd, saxbuilder should be completely agnostic from a element name point of view. Did you try to print element names xElem-getNodeName() (line 1227) for the broken example ? -- Marco On Wed, 25 Apr 2012 11:48:10 +0200, Noel Grandin noelgran...@gmail.com wrote: Looks like the code in unoxml/source/dom/saxbuilder.cxx converts the SAX event stream into a DOM tree. On 2012-04-25 08:34, Christina Rossmanith wrote: for the example without x and y attribute the case XML_TEXT block is never reached. That's why I'd like to understand where and how the tree is built. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Removed unused methods from psp::PrinterGfx
Hi,
an easyhack, to get a feeling of success while trying to understand
import of SVGs.
Christina
From 5b90ab4c0053c09bbd49f1bf3024d70cfb32af6e Mon Sep 17 00:00:00 2001
From: Chr. Rossmanith chr.rossman...@gmx.de
Date: Tue, 24 Apr 2012 20:09:33 +0200
Subject: [PATCH] Removed unused methods from psp::PrinterGfx
---
vcl/generic/print/bitmap_gfx.cxx | 28
vcl/generic/print/common_gfx.cxx |7 ---
vcl/generic/print/text_gfx.cxx | 17 -
vcl/inc/generic/printergfx.hxx | 13 +
4 files changed, 1 insertion(+), 64 deletions(-)
diff --git a/vcl/generic/print/bitmap_gfx.cxx b/vcl/generic/print/bitmap_gfx.cxx
index 3b19b51..cfabe70 100644
--- a/vcl/generic/print/bitmap_gfx.cxx
+++ b/vcl/generic/print/bitmap_gfx.cxx
@@ -467,34 +467,6 @@ PrinterGfx::DrawBitmap (const Rectangle rDest, const Rectangle rSrc,
PSGRestore ();
}
-/* XXX does not work XXX */
-void
-PrinterGfx::DrawBitmap (const Rectangle rDest, const Rectangle rSrc,
-const PrinterBmp /*rBitmap*/, const PrinterBmp /*rTransBitmap*/)
-{
-double fScaleX = (double)rDest.GetWidth() / (double)rSrc.GetWidth();
-double fScaleY = (double)rDest.GetHeight() / (double)rSrc.GetHeight();
-
-PSGSave ();
-PSTranslate (rDest.BottomLeft());
-PSScale (fScaleX, fScaleY);
-PSGRestore ();
-}
-
-/* XXX does not work XXX */
-void
-PrinterGfx::DrawMask (const Rectangle rDest, const Rectangle rSrc,
-const PrinterBmp /*rBitmap*/, PrinterColor /*rMaskColor*/)
-{
-double fScaleX = (double)rDest.GetWidth() / (double)rSrc.GetWidth();
-double fScaleY = (double)rDest.GetHeight() / (double)rSrc.GetHeight();
-
-PSGSave ();
-PSTranslate (rDest.BottomLeft());
-PSScale (fScaleX, fScaleY);
-PSGRestore ();
-}
-
/*
*
* Implementation: PS Level 1
diff --git a/vcl/generic/print/common_gfx.cxx b/vcl/generic/print/common_gfx.cxx
index 662e696..d11ba20 100644
--- a/vcl/generic/print/common_gfx.cxx
+++ b/vcl/generic/print/common_gfx.cxx
@@ -104,13 +104,6 @@ PrinterGfx::Init (const JobData rData)
return sal_True;
}
-void
-PrinterGfx::GetResolution (sal_Int32 rDpiX, sal_Int32 rDpiY) const
-{
-rDpiX = mnDpi;
-rDpiY = mnDpi;
-}
-
sal_uInt16
PrinterGfx::GetBitCount ()
{
diff --git a/vcl/generic/print/text_gfx.cxx b/vcl/generic/print/text_gfx.cxx
index 237bb1b..f7d9acb 100644
--- a/vcl/generic/print/text_gfx.cxx
+++ b/vcl/generic/print/text_gfx.cxx
@@ -697,23 +697,6 @@ const ::std::list KernPair PrinterGfx::getKernPairs( bool bVertical ) const
}
/*
- * advanced glyph handling
- */
-
-sal_Bool
-PrinterGfx::GetGlyphBoundRect (sal_Unicode /*c*/, Rectangle /*rOutRect*/)
-{
-return 0;
-}
-
-sal_uInt32
-PrinterGfx::GetGlyphOutline (sal_Unicode /*c*/,
- sal_uInt16 **/*ppPolySizes*/, Point **/*ppPoints*/, sal_uInt8 **/*ppFlags*/)
-{
-return 0;
-}
-
-/*
* spool the converted truetype fonts to the page header after the page body is
* complete
* for Type1 fonts spool additional reencoding vectors that are necessary to access the
diff --git a/vcl/inc/generic/printergfx.hxx b/vcl/inc/generic/printergfx.hxx
index 57347f3..9308ee3 100644
--- a/vcl/inc/generic/printergfx.hxx
+++ b/vcl/inc/generic/printergfx.hxx
@@ -334,8 +334,7 @@ public:
sal_BoolInit (const JobData rData);
voidClear();
-// query depth and size
-voidGetResolution (sal_Int32 rDpiX, sal_Int32 rDpiY) const;
+// query depth
sal_uInt16 GetBitCount ();
// clip region
@@ -379,11 +378,6 @@ public:
// image drawing
voidDrawBitmap (const Rectangle rDest, const Rectangle rSrc,
const PrinterBmp rBitmap);
-voidDrawBitmap (const Rectangle rDest, const Rectangle rSrc,
-const PrinterBmp rBitmap,
-const PrinterBmp rTransBitmap);
-voidDrawMask (const Rectangle rDest, const Rectangle rSrc,
-const PrinterBmp rBitmap, PrinterColor rMaskColor);
// font and text handling
sal_uInt16 SetFont (
@@ -417,11 +411,6 @@ public:
sal_Int32 GetCharWidth (sal_uInt16 nFrom, sal_uInt16 nTo,
long *pWidthArray);
const ::std::list KernPair getKernPairs( bool bVertical = false ) const;
-// advanced font handling
-sal_BoolGetGlyphBoundRect (sal_Unicode c, Rectangle rOutRect);
-sal_uInt32 GetGlyphOutline (sal_Unicode c,
- sal_uInt16 **ppPolySizes, Point **ppPoints,
- sal_uInt8 **ppFlags);
// for CTL
voidDrawGlyphs( const Point rPoint,
--
1.7.9.5
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
SVG import: svgreader - internal-style-ref
Hi, I've created a small svg sample file just containing some text. If I remove the x and y attribute this has influence on the value of the internal-style-ref attribute. Maybe this is a hint where some problems might have their origin. To get a better understanding: What is the intent of internal-style-ref? Which items should get identical values? Are identical values allowed at all? Are empty values allowed? (Probably not because in that case the text doesn't show up) Below you find two very small svg examples together with the result of dumpTree() (cf. svgreader.cxx) and a short description whether the text is displayed correctly. Christina Text appears on page svg text x=1 y=1 skew x (45)/text /svg name: svg width=210mm height=297mm internal-style-ref=1$0 name: text x=1 y=1 internal-style-ref=2$0 - Text does not appear on page svg textskew x (45)/text /svg name: svg width=210mm height=297mm internal-style-ref=1$0 name: text ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Pushed] Easy Hack Bug No. 42982
Hi, could throw RuntimeException(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(XListener is not equal to 1))... be written as throw RuntimeException(XListener is not equal to 1,... ? Christina Am 11.04.2012 21:20, schrieb Abeer Sethi: I'm attaching the patch for namecont.cxx, I hope this is the correct way to go about it. If yes, I have another patch ready for another file. Thanking You, Abeer Sethi. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Reduced duplicate code detected by simian
Hi,
after replacing string data types I looked for duplicated code in vcl
with simian. Could someone please review it? It builds successfully but
I'm unsure about where to use const...
Thank you,
Christina
From 94b9a014e07133fef3f7432d4d6945cd76e66d4d Mon Sep 17 00:00:00 2001
From: Christina Rossmanith chrrossman...@web.de
Date: Tue, 24 Jan 2012 22:26:45 +0100
Subject: [PATCH] Reduced duplicate code detected by simian
---
vcl/inc/vcl/outdev.hxx |1 +
vcl/source/gdi/outdev.cxx | 32
vcl/source/gdi/outdev2.cxx | 35 +--
3 files changed, 22 insertions(+), 46 deletions(-)
diff --git a/vcl/inc/vcl/outdev.hxx b/vcl/inc/vcl/outdev.hxx
index ea7787c..1c612b5 100644
--- a/vcl/inc/vcl/outdev.hxx
+++ b/vcl/inc/vcl/outdev.hxx
@@ -547,6 +547,7 @@ public:
// tells whether this output device is RTL in an LTR UI or LTR in a RTL UI
SAL_DLLPRIVATE bool ImplIsAntiparallel() const ;
+SAL_DLLPRIVATE Color ImplDrawModeToColor( Color );
// #i101491#
// Helper which holds the old line geometry creation and is extended to use AA when
diff --git a/vcl/source/gdi/outdev.cxx b/vcl/source/gdi/outdev.cxx
index fe49527..b55a237 100644
--- a/vcl/source/gdi/outdev.cxx
+++ b/vcl/source/gdi/outdev.cxx
@@ -1238,38 +1238,36 @@ void OutputDevice::SetLineColor()
// ---
-void OutputDevice::SetLineColor( const Color rColor )
+Color OutputDevice::ImplDrawModeToColor( const Color rColor )
{
-OSL_TRACE( OutputDevice::SetLineColor( %lx ), rColor.GetColor() );
-DBG_CHKTHIS( OutputDevice, ImplDbgCheckOutputDevice );
-
Color aColor( rColor );
+sal_uLong nDrawMode = GetDrawMode();
-if( mnDrawMode ( DRAWMODE_BLACKLINE | DRAWMODE_WHITELINE |
- DRAWMODE_GRAYLINE | DRAWMODE_GHOSTEDLINE |
- DRAWMODE_SETTINGSLINE ) )
+if( nDrawMode ( DRAWMODE_BLACKLINE | DRAWMODE_WHITELINE |
+ DRAWMODE_GRAYLINE | DRAWMODE_GHOSTEDLINE |
+ DRAWMODE_SETTINGSLINE ) )
{
if( !ImplIsColorTransparent( aColor ) )
{
-if( mnDrawMode DRAWMODE_BLACKLINE )
+if( nDrawMode DRAWMODE_BLACKLINE )
{
aColor = Color( COL_BLACK );
}
-else if( mnDrawMode DRAWMODE_WHITELINE )
+else if( nDrawMode DRAWMODE_WHITELINE )
{
aColor = Color( COL_WHITE );
}
-else if( mnDrawMode DRAWMODE_GRAYLINE )
+else if( nDrawMode DRAWMODE_GRAYLINE )
{
const sal_uInt8 cLum = aColor.GetLuminance();
aColor = Color( cLum, cLum, cLum );
}
-else if( mnDrawMode DRAWMODE_SETTINGSLINE )
+else if( nDrawMode DRAWMODE_SETTINGSLINE )
{
aColor = GetSettings().GetStyleSettings().GetFontColor();
}
-if( mnDrawMode DRAWMODE_GHOSTEDLINE )
+if( nDrawMode DRAWMODE_GHOSTEDLINE )
{
aColor = Color( ( aColor.GetRed() 1 ) | 0x80,
( aColor.GetGreen() 1 ) | 0x80,
@@ -1277,6 +1275,16 @@ void OutputDevice::SetLineColor( const Color rColor )
}
}
}
+return aColor;
+}
+
+
+void OutputDevice::SetLineColor( const Color rColor )
+{
+OSL_TRACE( OutputDevice::SetLineColor( %lx ), rColor.GetColor() );
+DBG_CHKTHIS( OutputDevice, ImplDbgCheckOutputDevice );
+
+Color aColor = ImplDrawModeToColor( rColor );
if( mpMetaFile )
mpMetaFile-AddAction( new MetaLineColorAction( aColor, sal_True ) );
diff --git a/vcl/source/gdi/outdev2.cxx b/vcl/source/gdi/outdev2.cxx
index 2003de8..9b0b4f3 100644
--- a/vcl/source/gdi/outdev2.cxx
+++ b/vcl/source/gdi/outdev2.cxx
@@ -1441,40 +1441,7 @@ void OutputDevice::DrawPixel( const Point rPt, const Color rColor )
OSL_TRACE( OutputDevice::DrawPixel() );
DBG_CHKTHIS( OutputDevice, ImplDbgCheckOutputDevice );
-Color aColor( rColor );
-
-if( mnDrawMode ( DRAWMODE_BLACKLINE | DRAWMODE_WHITELINE |
- DRAWMODE_GRAYLINE | DRAWMODE_GHOSTEDLINE |
- DRAWMODE_SETTINGSLINE ) )
-{
-if( !ImplIsColorTransparent( aColor ) )
-{
-if( mnDrawMode DRAWMODE_BLACKLINE )
-{
-aColor = Color( COL_BLACK );
-}
-else if( mnDrawMode DRAWMODE_WHITELINE )
-{
-aColor = Color( COL_WHITE );
-}
-else if( mnDrawMode DRAWMODE_GRAYLINE )
-{
-const sal_uInt8 cLum = aColor.GetLuminance();
-aColor = Color( cLum, cLum, cLum );
-}
-else if( mnDrawMode DRAWMODE_SETTINGSLINE )
-{
-aColor =
[Libreoffice] Cleaning sal/inc/osl/file.hxx
Hi, after removing all redundant #defines from file.hxx (last change not yet pushed - build is going on) I had a look at the enum RC. At a first glance it seems that e.g. E_None is used only in pyuno_module.cxx (and in some comments in file.hxx) and could be replaced by the value osl_File_E_None from file.h. So put into a single question: Can the enum be removed as well? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] remove FileStatusMask_XXX in favour of osl_FileStatus_Mask_XXX
Pushed. Christina Am 13.04.2011 22:19, schrieb Christina Roßmanith: Build was fine. I'll push on next Tuesday because there is no time slot for LO earlier. Christina Am 12.04.2011 22:03, schrieb Christina Roßmanith: Am 11.04.2011 23:30, schrieb Michaël Lefèvre: Actually, this was part of the easy hack hunt and destroy obsolete macros. As I have very little time (2h/week) to join the fun, and taking some vacation for a month, I didn't apply to this on the wiki. To any one, fill free to complete the task. After vcl enum, Christina ;) you' re in ? We could share this. I've continued with the FileStatus group - build is running, so it's not pushed already. Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] dbgmacros.hxx / dbgmacros.cxx
I've made the changes and pushed them. Christina Am 12.04.2011 11:20, schrieb Noel Power: Hi Christina On 09/04/11 22:08, Christina Roßmanith wrote: [...] So I'll remove the definition of PRE_CONDITION and POST_CONDITION and replace the latter with OSL_POSTCOND (the former isn't used). ENSURE will be replaced by OSL_ENSURE and DbgAssert removed. Any objections? yeah, sounds reasonable to me :-) I'd say go for it Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] remove VolumeInfoMask_XXX in favour of osl_VolumeInfo_Mask_XXX
Build was fine. I'll push on next Tuesday because there is no time slot for LO earlier. Christina Am 12.04.2011 22:03, schrieb Christina Roßmanith: Am 11.04.2011 23:30, schrieb Michaël Lefèvre: Actually, this was part of the easy hack hunt and destroy obsolete macros. As I have very little time (2h/week) to join the fun, and taking some vacation for a month, I didn't apply to this on the wiki. To any one, fill free to complete the task. After vcl enum, Christina ;) you' re in ? We could share this. I've continued with the FileStatus group - build is running, so it's not pushed already. Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removed never defined _OLD_FILE_IMPL
_USE_UNO: I thought, that I had removed everything #ifdef'ed with _USE_UNO. BUT I've found some occurences in ./basic. Is there a way to search for all commits I've done so far? I'll finish that, of course! Christina Am 12.04.2011 10:49, schrieb Noel Power: On 11/04/11 15:55, Thorsten Behrens wrote: Noel Power wrote: As far as I understand the code it consists merely of test calls to functions in order to see if they return a valid result. I'm quite sure that you already know whether it has side effects or not... I vote for it hasn't, but I'm absolutely not sure nah, just seems like some testing to see if uno is bootstrapped and the ucp stuff available, it looks to me especially in the case you removed to be completely useless. Btw if you are feeling frisky and wish to kill other related pieces of uselessness :-) there are the #ifdef _USE_UNO associated blocks that you can see around the hasUno() method ( and others ) that need some removing ( afaics _USE_UNO is defined always ) So we're safe to apply the original patch (with the improvements suggested previously)? I'm pretty sure Christina pushed the patch to do with the _OLD_FILE_IMPL IIRC Christina was going to squash the _USE_UNO pieces too, not sure if that happened yet or not, Christina did you get a chance to do that or should we maybe add it as an easy hack if you didn't have time? Thanks, Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removed never defined _OLD_FILE_IMPL
Removed last occurences of _USE_UNO, built successfully and pushed. Christina Am 12.04.2011 10:49, schrieb Noel Power: On 11/04/11 15:55, Thorsten Behrens wrote: Noel Power wrote: As far as I understand the code it consists merely of test calls to functions in order to see if they return a valid result. I'm quite sure that you already know whether it has side effects or not... I vote for it hasn't, but I'm absolutely not sure nah, just seems like some testing to see if uno is bootstrapped and the ucp stuff available, it looks to me especially in the case you removed to be completely useless. Btw if you are feeling frisky and wish to kill other related pieces of uselessness :-) there are the #ifdef _USE_UNO associated blocks that you can see around the hasUno() method ( and others ) that need some removing ( afaics _USE_UNO is defined always ) So we're safe to apply the original patch (with the improvements suggested previously)? I'm pretty sure Christina pushed the patch to do with the _OLD_FILE_IMPL IIRC Christina was going to squash the _USE_UNO pieces too, not sure if that happened yet or not, Christina did you get a chance to do that or should we maybe add it as an easy hack if you didn't have time? Thanks, Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] remove VolumeInfoMask_XXX in favour of osl_VolumeInfo_Mask_XXX
Am 11.04.2011 23:30, schrieb Michaël Lefèvre: Actually, this was part of the easy hack hunt and destroy obsolete macros. As I have very little time (2h/week) to join the fun, and taking some vacation for a month, I didn't apply to this on the wiki. To any one, fill free to complete the task. After vcl enum, Christina ;) you' re in ? We could share this. I've continued with the FileStatus group - build is running, so it's not pushed already. Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Easy hack: expunge duplicate enumerations in vcl
Hi Julien, I forgot to search in the whole code tree. Could you please push your additional changes? Thank you, Christina Am 10.04.2011 22:55, schrieb Julien Nabet: Hello Christina, Compilation failed in padmin (even after a make -r clean make -sr). So here is a simple patch to validate. The compilation is ok but perhaps I missed something or perhaps you planned other changes. If it's ok for you, I can push it myself if you want. Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] code cleanup in embeddedobj
Hi, in docholder.cxx in DocumentHolder::FreeOffice most of the code is commented out with a remark // the following code is commented out since for now there is still no completely correct way to detect // whether the office can be terminated, so it is better to have unnecessary process running than // to loose any data If I understand the output of git annotate correctly, these lines are from 2005. Keep or remove (comment commented code)? Similar in olecomponent.cxx: OleComponent::getTransferData // The following optimization does not make much sence currently just because // only one aspect is supported, and only three formats for the aspect are supported // and moreover it is not guarantied that the once returned format will be supported further // example - i52106 // TODO/LATER: bring the optimization back when other aspects are supported From 2005 as well. Does embeddedobj/test/Container1/BitmapPainter.java belong to a unit test? And is the code of method execute() commented out to prevent the test to fail? What about commented code in module/test directories in general? Keep it because it shall be re-enabled some day? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [partial PATCH] Easy hack: expunge duplicate enumerations in vcl
Finished and pushed. Next step: remove duplicates from vclenum.h and add #include fontenum.h from tools? Christina Am 08.04.2011 17:37, schrieb Caolán McNamara: On Wed, 2011-04-06 at 22:11 +0200, Christina Roßmanith wrote: Hi Caolan, I've continued to remove psp::weight::type. At the end of your last e-mail you mention 3 enums. ... Or shouldn't three be taken literally. Don't take it literally I suppose :-) italic, pitch, family- FontItalic, FontPitch, FontFamily Well, psp::family, psp::weight, psp::pitch, psp::width, psp::italic to be exact I guess. For italic I need some help how to translate the vclenum values into the fontmanager values. psp::italic::Upright = 0 = FontItalic::ITALIC_NONE psp::italic::Oblique = 1 = FontItalic::ITALIC_OBLIQUE psp::italic::Italic = 2 = FontItalic::ITALIC_NORMAL psp::italic::Unknown = 3 = FontItalic::ITALIC_DONTKNOW should do the trick. For the final test, whether it builds or not, I would have to install Qt3 in order to allow --enable-kde. Is that the only way? Or could someone with Qt3 installed test it for me? Well you could always just commit it in and hope for the best :-) And what about the FW_NORMAL, FW_BLACK etc. from sft.h? Shall they be replaced as well? Nah, same logic as before, leave the sft.h enums alone. For this round anyway. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] dbgmacros.hxx / dbgmacros.cxx
Am 05.04.2011 10:50, schrieb Noel Power:
Hi Christina
\On 05/04/11 09:11, Christina Roßmanith wrote:
Hi,
after removal of comments it becomes clear that DbgAssert() is empty.
It is used for the definition of PRE_CONDITION (unused),
POST_CONDITION (used in classfactory.cxx and propertyhdl.cxx) and
ENSURE (used at several places).
I think PRE_CONDITION, POST_CONDITION and ENSURE can be removed from
the code and afterwards dbgmacros.{cxx,hxx} can be removed from the
code base. Should the macros be replaced by some more recent macros?
the OSL_ equivalent macros probably are a suitable replacement(s),
see http://opengrok.libreoffice.org/xref/ure/sal/inc/osl/diagnose.h#53
Noel
So I'll remove the definition of PRE_CONDITION and POST_CONDITION and
replace the latter with OSL_POSTCOND (the former isn't used). ENSURE
will be replaced by OSL_ENSURE and DbgAssert removed. Any objections?
Christina
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [partial PATCH] Easy hack: expunge duplicate enumerations in vcl
Hi Caolan, I've continued to remove psp::weight::type. At the end of your last e-mail you mention 3 enums. Given that width and weight are already two enums there is one left to remove. Or shouldn't three be taken literally. There are still left: italic, pitch, family - FontItalic, FontPitch, FontFamily For italic I need some help how to translate the vclenum values into the fontmanager values. For the final test, whether it builds or not, I would have to install Qt3 in order to allow --enable-kde. Is that the only way? Or could someone with Qt3 installed test it for me? And what about the FW_NORMAL, FW_BLACK etc. from sft.h? Shall they be replaced as well? Christina Am 05.04.2011 21:18, schrieb Caolán McNamara: On Tue, 2011-04-05 at 21:01 +0200, Christina Roßmanith wrote: removed some methods ToFontWidth() which aren't needed anymore. Yup, looks good, the removal of those redundant mappings is the target. After that vcl compiles fine for me. But it tells me that KDE is disabled (who did that?), so this part isn't checked by the compiler. see --enable-kde/--enable-kde4 as arguments to ./autogen.sh / configure If someone could please review this patch. If it is fine I'll go on. Would you recommend a huge push at the end of this work or one for each removed enum? Looks good, obviously remove the commented out code. Just the one push IMO for the three enums. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Removal of bogus comments
Hi Anurag,
this patch was fine. I've additionally removed some lines you've missed.
And skipped this deletion:
-sal_uInt32 exportDoc(enum ::xmloff::token::XMLTokenEnum /*eClass*/)
{return 0;}
+sal_uInt32 exportDoc(enum ::xmloff::token::XMLTokenEnum) {return 0;}
Pushed!
Christina
Am 05.04.2011 03:40, schrieb Anurag Jain:
I've updates my patch as said. I've included some more files in
this.There were lots of German
comments present in the module and I've skipped such comments
containing some bug IDs.
Hoping to see this one getting pushed :) .
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] dbgmacros.hxx / dbgmacros.cxx
Hi,
after removal of comments it becomes clear that DbgAssert() is empty. It
is used for the definition of PRE_CONDITION (unused), POST_CONDITION
(used in classfactory.cxx and propertyhdl.cxx) and ENSURE (used at
several places).
I think PRE_CONDITION, POST_CONDITION and ENSURE can be removed from the
code and afterwards dbgmacros.{cxx,hxx} can be removed from the code
base. Should the macros be replaced by some more recent macros?
Christina
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [WIP] Remove most of dead code in libs-core
shell part pushed. Christina Am 20.03.2011 00:52, schrieb Xisco Faulí: Here we go with the first round of patches. Whitespaces are not deleted anymore and all the bogus have been deleted. Everything builds allright. Part 1 -- http://dl.dropbox.com/u/1274885/removed-commented-code-part1.tar.gz I'll post the second part soon Greetings ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [partial PATCH] Easy hack: expunge duplicate enumerations in vcl
Hi,
to see if I'm walking into the right direction I've replaced
psp::width::type with FontWidth and removed some methods ToFontWidth()
which aren't needed anymore. After that vcl compiles fine for me. But it
tells me that KDE is disabled (who did that?), so this part isn't
checked by the compiler.
If someone could please review this patch. If it is fine I'll go on.
Would you recommend a huge push at the end of this work or one for each
removed enum?
Christina
Am 05.04.2011 11:57, schrieb Caolán McNamara:
On Mon, 2011-04-04 at 23:18 +0200, Christina Roßmanith wrote:
As far as I understand the description, psp::width::UC shall be
removed. But shall the enum from sft.hxx or from vclenum.hxx be kept?
60:40 for vclenum.hxx I would guess.
Yeah, the psprint stuff used to live somewhere else, so the enum was
added there and the mapping stuff to allow that build to work, psprint
got folded into vcl, so no need for the dup of that one anymore. So
a) the psp:: ones definitely go, and
b) definitely get replaced with the vclenum.hxx ones.
The sft.hxx stuff on the other hand are from another piece of code that
got merged into vcl from some third party source IIRC, and describe the
values used in the truetype font format, I think those values match the
physical numbers stored in those files so they should, for now anyway,
get left alone, and the mappings from/to them and the vclenum values
left alone.
why has tools its own WIDTH_ULTRA_CONDENSED?
hum, wasn't aware of that. The original commit there says move this
from vcl to get xmloff free of vcl stuff, so (as a follow up maybe) it
would seem to make sense to e.g. remove the dups from vclenum.hxx and
have it include tools/fontenum.hxx to provide those.
From e78b1c8f6cadeeddfa6c936acdcabbe2604aedb7 Mon Sep 17 00:00:00 2001
From: Christina Rossmanith chrrossman...@web.de
Date: Tue, 5 Apr 2011 20:54:37 +0200
Subject: [PATCH] Replaced psp::width::type with FontWidth
---
vcl/inc/vcl/fontmanager.hxx| 16 ++--
vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx | 23 ---
vcl/unx/headless/svppspgraphics.cxx| 20 +-
vcl/unx/headless/svppspgraphics.hxx|1 -
vcl/unx/inc/pspgraphics.h |2 +-
vcl/unx/kde/salnativewidgets-kde.cxx | 21 +++---
vcl/unx/source/fontmanager/fontcache.cxx |2 +-
vcl/unx/source/fontmanager/fontconfig.cxx | 48 +++---
vcl/unx/source/fontmanager/fontmanager.cxx | 42 ++--
vcl/unx/source/gdi/pspgraphics.cxx | 23 +--
vcl/unx/source/gdi/salgdi3.cxx | 99 ++--
11 files changed, 115 insertions(+), 182 deletions(-)
diff --git a/vcl/inc/vcl/fontmanager.hxx b/vcl/inc/vcl/fontmanager.hxx
index bb03bc3..632e304 100644
--- a/vcl/inc/vcl/fontmanager.hxx
+++ b/vcl/inc/vcl/fontmanager.hxx
@@ -36,7 +36,7 @@
#include vcl/dllapi.h
#include vcl/helper.hxx
-
+#include vcl/vclenum.hxx
#include com/sun/star/lang/Locale.hpp
#include vector
@@ -162,7 +162,7 @@ struct FastPrintFontInfo
std::list rtl::OUString m_aAliases;
family::type m_eFamilyStyle;
italic::type m_eItalic;
-width::type m_eWidth;
+FontWidth m_eWidth;
weight::type m_eWeight;
pitch::type m_ePitch;
rtl_TextEncoding m_aEncoding;
@@ -174,7 +174,7 @@ struct FastPrintFontInfo
m_eType( fonttype::Unknown ),
m_eFamilyStyle( family::Unknown ),
m_eItalic( italic::Unknown ),
-m_eWidth( width::Unknown ),
+m_eWidth( WIDTH_DONTKNOW ),
m_eWeight( weight::Unknown ),
m_ePitch( pitch::Unknown ),
m_aEncoding( RTL_TEXTENCODING_DONTKNOW )
@@ -276,7 +276,7 @@ class VCL_PLUGIN_PUBLIC PrintFontManager
int m_nPSName; // atom
rtl::OUString m_aStyleName;
italic::typem_eItalic;
-width::type m_eWidth;
+FontWidth m_eWidth;
weight::typem_eWeight;
pitch::type m_ePitch;
rtl_TextEncodingm_aEncoding;
@@ -360,7 +360,7 @@ class VCL_PLUGIN_PUBLIC PrintFontManager
rtl::OString aAddStyle;
italic::type eItalic;
weight::type eWeight;
-width::type eWidth;
+FontWidth eWidth;
pitch::type ePitch;
rtl_TextEncoding aEncoding;
@@ -521,10 +521,10 @@ public:
}
// get a specific fonts width type
-width::type getFontWidth( fontID nFontID ) const
+FontWidth getFontWidth( fontID nFontID ) const
{
PrintFont* pFont = getFont( nFontID );
-return pFont ? pFont-m_eWidth : width::Unknown;
+return pFont
Re: [Libreoffice] [PATCH] [WIP] Remove most of dead code in libs-core
Pushed the linguistic part. Christina Am 20.03.2011 00:52, schrieb Xisco Faulí: Here we go with the first round of patches. Whitespaces are not deleted anymore and all the bogus have been deleted. Everything builds allright. Part 1 -- http://dl.dropbox.com/u/1274885/removed-commented-code-part1.tar.gz I'll post the second part soon ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Easy hack: expunge duplicate enumerations in vcl
Hi, I need some more information for the easy hack expunge duplicate enumerations in vcl. For ultra condensed font width there are three places with different names: psp::width::UltraCondensed (fontmanager.hxx) FWIDTH_ULTRA_CONDENSED (sft.hxx) and WIDTH_ULTRA_CONDENSED (vclenum.hxx) and if you have a look not only at vcl/ but also at tools/ which is part of libs-gui as well, you find another WIDTH_ULTRA_CONDENSED. As far as I understand the description, psp::width::UC shall be removed. But shall the enum from sft.hxx or from vclenum.hxx be kept? 60:40 for vclenum.hxx I would guess. And why has tools its own WIDTH_ULTRA_CONDENSED? And if vcl is an acronym: what does it stand for? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need a little help with the easyhack Strip include guards in idl files
Hi Julien, I've executed the modified strip-guards script in the clone directory, not in a module subdirectory. Afterwards your pcregrep command (see below in your first message) only found two guards not stripped: clone/ure/jurt/test/com/sun/star/lib/uno/protocols/urp/interfaces.idl:#ifndef __com_sun_star_beans_XPropertySet_idl_ #include com/sun/star/beans/XPropertySet.idl clone/ure/jurt/test/com/sun/star/lib/uno/protocols/urp/interfaces.idl:#ifndef __com_sun_star_uno_Exception_idl__ #include com/sun/star/uno/Any.idl I have not yet built the resulting code tree - but that sounds promising... Christina Am 27.03.2011 00:20, schrieb Julien Nabet: Hello, Concerning the easyhack Strip include guards in idl files, I pushed 2 patches for the directory ure/udkapi. For the first patch I only used the strip-guards script with just a change to apply for idl + remove of the includes block between the 2 final Find. Then to check it was ok, i used this command to search ifndef line followed by include line in idl files : find . -name *.idl|xargs pcregrep -M 'ifndef.*\n.*include' pcregrep is multiline grep (available for Debian, I don't know for the other Linux distribs, MacOs or Windows). There were few to process manually so I did it and pushed a second patch. Then I took a look at the directory ure/offapi. There are about 3700 files and the strip-guards script lets a lot (more than 3000!) of #ifndef with #include.( I don't know why, a pb of Unix/Dos end-of-line perhaps ?) This time it's too much to do it manually. Some idea to improve the strip-guards script ? BTW I saw there were idl files in some test or qa directories of ure but I don't think they could cause pb. Julien. I know very little of Perl, does anybody got an idea to avoid to process 3700 files by hand ? Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] sal/qa/osl/file/osl_old_test_file.cxx
Hi, is anybody else having trouble to compile osl_old_test_file.cxx? I have to comment out lines 133 and 263, then everything is fine: 133: CPPUNIT_ASSERT_MESSAGE(failure #1.1, target.equalsAscii( aSource1[i+1] ) ); 263: CPPUNIT_ASSERT_MESSAGE(failure #10.1, target.equalsAscii( aSource1[i+1] ) ); Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] HID_STATUSBAR
Hi, I found that HID_STATUSBAR is #defined as 1212 in sw/source/ui/inc/hidfunc.h and #defined as SW_HID_STATUSBAR in sw/inc/helpid.h Strange - but hidfunc.h never seems to be included. Could someone please check this? I've grok'ed and ./g grep'ed with no result. How can a file be removed from the code base? rm of course - and then? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [WIP] Remove most of dead code in libs-core
Hi,
pushed the framework part. Again a lot of files changed their place so
it was quite a lot of work to apply the patch. Additionally I removed
lots of dates, comments above removed commented methods, {} not needed
anymore after the if () has gone and changed
if ( bState = sal_True) to if ( bState == sal_True) in test.cxx.
Hope you don't mind that the additional changes are pushed under your name?
What about these comments (task.hxx):
/*-//**
@short-
@descr-
@seealso-
@seealso-
@param-
@return-
@onerror-
*//*-*/
I'd suggest to remove them...
Christina
Am 20.03.2011 00:52, schrieb Xisco Faulí:
Here we go with the first round of patches.
Whitespaces are not deleted anymore and all the bogus have been
deleted. Everything builds allright.
Part 1 --
http://dl.dropbox.com/u/1274885/removed-commented-code-part1.tar.gz
I'll post the second part soon
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [WIP] Remove most of dead code in libs-core
Hi, formula and sfx2 pushed. The files WriterHelper.java and DocumentMetadataAccess.java changed their place in the code tree but DocumentMetaData.java seems to have been removed. Christina Am 20.03.2011 00:52, schrieb Xisco Faulí: Here we go with the first round of patches. Whitespaces are not deleted anymore and all the bogus have been deleted. Everything builds allright. Part 1 -- http://dl.dropbox.com/u/1274885/removed-commented-code-part1.tar.gz I'll post the second part soon Greetings 2011/3/18 Christina Roßmanith chrrossman...@web.de mailto:chrrossman...@web.de Patch 0025 now is already pushed but I'll wait until I see a new version on the ML. Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] _USE_UNO
Hi, there are some places where _USE_UNO is #defined and some lines later it is queried via #ifdef. It seems that _USE_UNO could be removed in that context. Veto or go? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need a little help with the easyhack Strip include guards in idl files
Sorry, Please move my last e-mail to /dev/null...only .idl files were changed Christina Am 27.03.2011 00:20, schrieb Julien Nabet: Hello, Concerning the easyhack Strip include guards in idl files, I pushed 2 patches for the directory ure/udkapi. For the first patch I only used the strip-guards script with just a change to apply for idl + remove of the includes block between the 2 final Find. Then to check it was ok, i used this command to search ifndef line followed by include line in idl files : find . -name *.idl|xargs pcregrep -M 'ifndef.*\n.*include' pcregrep is multiline grep (available for Debian, I don't know for the other Linux distribs, MacOs or Windows). There were few to process manually so I did it and pushed a second patch. Then I took a look at the directory ure/offapi. There are about 3700 files and the strip-guards script lets a lot (more than 3000!) of #ifndef with #include.( I don't know why, a pb of Unix/Dos end-of-line perhaps ?) This time it's too much to do it manually. Some idea to improve the strip-guards script ? BTW I saw there were idl files in some test or qa directories of ure but I don't think they could cause pb. Julien. I know very little of Perl, does anybody got an idea to avoid to process 3700 files by hand ? Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Removed never defined _ENABLE_CUR_DIR
Hi,
I've continued code cleanup and removed #ifdef'ed blocks because
_ENABLE_CUR_DIR is never #defined.
Christina
From 81a17913da2c94e0cde5c14f4de933de1913b04c Mon Sep 17 00:00:00 2001
From: Christina Rossmanith chrrossman...@web.de
Date: Tue, 22 Mar 2011 19:26:46 +0100
Subject: [PATCH] Removed never defined _ENABLE_CUR_DIR
---
basic/source/runtime/methods.cxx | 53 +
1 files changed, 2 insertions(+), 51 deletions(-)
diff --git a/basic/source/runtime/methods.cxx b/basic/source/runtime/methods.cxx
index d69fb2c..2a319c4 100755
--- a/basic/source/runtime/methods.cxx
+++ b/basic/source/runtime/methods.cxx
@@ -85,8 +85,6 @@ using namespace com::sun::star::script;
#endif /* _USE_UNO */
-//#define _ENABLE_CUR_DIR
-
#include stdobj.hxx
#include basic/sbstdobj.hxx
#include rtlproto.hxx
@@ -489,27 +487,7 @@ RTLFUNC(ChDir)
(void)bWrite;
rPar.Get(0)-PutEmpty();
-if (rPar.Count() == 2)
-{
-#ifdef _ENABLE_CUR_DIR
-String aPath = rPar.Get(1)-GetString();
-sal_Bool bError = sal_False;
-#ifdef WNT
-// #55997 Laut MI hilft es bei File-URLs einen DirEntry zwischenzuschalten
-// #40996 Harmoniert bei Verwendung der WIN32-Funktion nicht mit getdir
-DirEntry aEntry( aPath );
-ByteString aFullPath( aEntry.GetFull(), gsl_getSystemTextEncoding() );
-if( chdir( aFullPath.GetBuffer()) )
-bError = sal_True;
-#else
-if (!DirEntry(aPath).SetCWD())
-bError = sal_True;
-#endif
-if( bError )
-StarBASIC::Error( SbERR_PATH_NOT_FOUND );
-#endif
-}
-else
+if (rPar.Count() != 2)
StarBASIC::Error( SbERR_BAD_ARGUMENT );
}
@@ -519,34 +497,7 @@ RTLFUNC(ChDrive)
(void)bWrite;
rPar.Get(0)-PutEmpty();
-if (rPar.Count() == 2)
-{
-#ifdef _ENABLE_CUR_DIR
-// Keine Laufwerke in Unix
-#ifndef UNX
-String aPar1 = rPar.Get(1)-GetString();
-
-#if defined (WNT) || defined (OS2)
-if (aPar1.Len() 0)
-{
-int nCurDrive = (int)aPar1.GetBuffer()[0]; ;
-if ( !isalpha( nCurDrive ) )
-{
-StarBASIC::Error( SbERR_BAD_ARGUMENT );
-return;
-}
-else
-nCurDrive -= ( 'A' - 1 );
-if (_chdrive(nCurDrive))
-StarBASIC::Error( SbERR_NO_DEVICE );
-}
-#endif
-
-#endif
-// #ifndef UNX
-#endif
-}
-else
+if (rPar.Count() != 2)
StarBASIC::Error( SbERR_BAD_ARGUMENT );
}
--
1.7.0.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] typos in configure script
Hi, I think it should read some packagers may wish (instead of with) to build without. and template (instead of temaplte). Is configure built from configure.in? Or where should the modification be made? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removed never defined _OLD_FILE_IMPL
Am 21.03.2011 18:10, schrieb Michael Meeks: On Mon, 2011-03-21 at 13:44 +0100, Christina Roßmanith wrote: I've removed all blocks of code #ifdef'ed by _OLD_FILE_IMPL because it was never defined. It builds successfully. Could someone please review to make sure that nothing was deleted accidentally? @@ -427,7 +425,7 @@ void OslStream::SetSize( sal_uIntPtr nSize ) maFile.setSize( (sal_uInt64)nSize ); } -#endif +//#endif Of course! I would fully remove that :-) -if( !hasUno() ) and hasUno has no side-effects ? ie. changes no global / local / object state, and calls nothing that does that ? Oops, indeed I didn't pay attention that it's not just a variable. I'll check that. That's why I've asked for more eyes :-) Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removed never defined _OLD_FILE_IMPL
Am 21.03.2011 18:10, schrieb Michael Meeks: On Mon, 2011-03-21 at 13:44 +0100, Christina Roßmanith wrote: I've removed all blocks of code #ifdef'ed by _OLD_FILE_IMPL because it was never defined. It builds successfully. Could someone please review to make sure that nothing was deleted accidentally? @@ -427,7 +425,7 @@ void OslStream::SetSize( sal_uIntPtr nSize ) maFile.setSize( (sal_uInt64)nSize ); } -#endif +//#endif I would fully remove that :-) -if( !hasUno() ) and hasUno has no side-effects ? ie. changes no global / local / object state, and calls nothing that does that ? As far as I understand the code it consists merely of test calls to functions in order to see if they return a valid result. I'm quite sure that you already know whether it has side effects or not... I vote for it hasn't, but I'm absolutely not sure. Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] problems building basic
Hi, I did a ./g pull -r yesterday (Saturday). After applying patches I'd like to build basic. It fails with /bin/bash: /Amanda/LibreOffice3/libo/solver/300/unxlngi6.pro/bin/rscdep: No such file or directory The error message is correct, but instead there is /Amanda/LibreOffice3/libo/solver/330/unxlngi6.pro/bin/rscdep. Note 330 instead of 300. What has to be changed that the correct directory is used? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] SwItemPropertySet
Hi, during removal of comments it became obvious that SwItemPropertySet::FillItem always returns sal_FALSE. Further searching for SwItemPropertySet with grok only finds it in unomap.hxx and unomap.cxx, ./g grep additionally finds it in binfilter. Does binfilter use the binfilter definition of SwItemPropertySet so that I can remove it from writer/sw/inc/unomap.hxx and writer/sw/source/core/unocore/unomap.cxx? Christina http://docs.libreoffice.org/sw/html/classSwItemPropertySet.html#e49f5de28129f77846f556a6f468fd17 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] toplevel make or partial build after modifications?
Hi, I've edited parhtml.cxx in ./svtools and now I'd like to test if the modification fixes bug 34666. What do I have to do? Is a partial build in directory ./svtools enough? Or is there some install-step needed? Or do I have to do a toplevel make? Christina Rossmanith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] [PUSHED] Additional translations of German comments in libs-core/editeng
Hi, I've pushed your patch with minor modifications (some typos, some translations changed the meaning of the German comment). Thank you for your contribution! Christina Rossmanith Am 14.03.2011 20:35, schrieb Albert Thuswaldner: Hi, Now I have fixed the patch. You can commit the patch under the terms of MPL 1.1 / GPLv3+ / LGPLv3+ triple license. /Albert On Fri, Mar 11, 2011 at 10:24, Albert Thuswaldner albert.thuswald...@gmail.com wrote: Please ignore this patch for now, same-line changes have been made in master since I sent this patch. I will merge it in my local repo and resend the patch. /Albert On Sun, Mar 6, 2011 at 20:51, Albert Thuswaldner albert.thuswald...@gmail.com wrote: And now the actual patch /Albert On Sun, Mar 6, 2011 at 20:49, Albert Thuswaldner albert.thuswald...@gmail.com wrote: Hi, While tidying up my local repo I discovered some changes that did not get properly pushed to master. It is all my fault, my patch back then was humungous. You can commit the patch under the terms of MPL 1.1 / GPLv3+ / LGPLv3+ triple license. /Albert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH][PUSHED] Removed unused constant PORTIONKIND_EXTRASPACE
Hi, I've removed the unused constant PORTIONKIND_EXTRASPACE, built editeng successfully and pushed the patch by myself. Christina Rossmanith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] [PUSHED] translate german comments in /sc/inc
Am 10.03.2011 19:24, schrieb Nicolas Christener: Hi all This translates the remaining german code comments in /sc/inc and removes some IMHO unused comments like // [...] The changes are commited per file to avoid a single large patch which is probably a pain to review - please correct me, if I should change this. This are my first patches to libreoffice, so feel free to correct me, if I did something wrong. My contributions are under the LGPLv3+/MPL dual license. kind regards nicolas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Comments in .src files
Hi, can I treat .src files like .cxx or .hxx files and remove commented code? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] bool vs. sal_bool
Hi,
I thought, I could start replacing some BOOL by bool. But when I started
to edit docuno.{hxx,cxx} I saw that there is not only BOOL and bool but
also sal_Bool. When do I use which of the boolean types?
Christina Rossmanith
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHING] translate german comments in /sc/inc
Yes - 0001 - 0003 are pushed as I wrote yesterday. I'll continue as time permits. Christina Rossmanith Am 11.03.2011 17:20, schrieb Kayo Hamid: just to remember: some patchs translating german comments to english are not pushed, 0044 is one and we have others inside this list of patchs. revol_ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] [PUSHING] translate german comments in /sc/inc
Pushed up to 0011 Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] [PUSHING] translate german comments in /sc/inc
Hi, I've pushed patch 1-3. Patch 4 only removes structuring //--- lines. I'm not sure if this is wanted. Maybe someone of the experts can comment on this? Then I'll go on with reviewing. Thank you for your contribution! Christina Rossmanith Am 10.03.2011 19:24, schrieb Nicolas Christener: Hi all This translates the remaining german code comments in /sc/inc and removes some IMHO unused comments like // [...] The changes are commited per file to avoid a single large patch which is probably a pain to review - please correct me, if I should change this. This are my first patches to libreoffice, so feel free to correct me, if I did something wrong. My contributions are under the LGPLv3+/MPL dual license. kind regards nicolas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Comment cleanup writer
Hi, I've applied your monster patch locally, waiting for a complete build before pushing it. Please break you patches in smaller parts in the future (c.f. http://wiki.documentfoundation.org/Development/Patch_Handling_Guideline) Thank you, Christina Rossmanith Am 03.03.2011 03:10, schrieb David Nalley: Hi all: Attached are two patches largely around comment cleanup, though with a few translations and some commented-out-code removal as well. This is my first set of patches to libreoffice, so feel free to critique - you won't hurt my feelings. Cheers, David ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Comment cleanup writer
Hi David, I'm reviewing the patch. You should keep bugids like #i12345# (see the developers wiki - easy hacks - translation of German comments - there you find some details about bugids) and keep comments belonging to bugids. That is what I can tell so far... But nevertheless: Thank you for your contribution! Christina Rossmanith Am 03.03.2011 03:10, schrieb David Nalley: Hi all: Attached are two patches largely around comment cleanup, though with a few translations and some commented-out-code removal as well. This is my first set of patches to libreoffice, so feel free to critique - you won't hurt my feelings. Cheers, David ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] [PUSHED] Code cleanliness
Pushed partially modified (a few bugids were found inside a sentence - modified those that they are still complete meaningful sentences without the bugid / found some additional bugids and removed them as well). Thank you, Christina Rossmanith Am 28.02.2011 00:05, schrieb Guillaume Poussel: And then, the same job in calc (1/3) 2011/2/27 Guillaume Pousselgpous...@gmail.com: Better with files attached :) 2011/2/27 Guillaume Pousselgpous...@gmail.com: Hi, Please find attached 2 patches in base/ which clean useless comments up. Regards, Guillaume (still under LGPLv3+/MPL) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Code cleanliness
Hi Guillaume, partly pushed - only waiting for an information how to handle #n123456# bugids (i.e. ~1% not yet pushed). Thank you. Christina Rossmanith Am 28.02.2011 00:06, schrieb Guillaume Poussel: And then, the same job in calc (3/3) Hi, Please find attached 2 patches in base/ which clean useless comments up. Regards, Guillaume (still under LGPLv3+/MPL) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] [PUSHED] Code cleanliness
Sorry - forgot the [PUSHED] tag. Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] [PUSHED] Code cleanliness
Pushed - thank you. Christina Rossmanith Am 28.02.2011 00:06, schrieb Guillaume Poussel: And then, the same job in calc (2/3) Hi, Please find attached 2 patches in base/ which clean useless comments up. Regards, Guillaume (still under LGPLv3+/MPL) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Nonsense comments?
To summarize: Andras isn't interested in keeping the comments. Christian could tell the meaning of '~'. Nobody votes for keeping the ACHTUNG/ATTENTION comments. So I conclude, we can start to remove them. I guess they aren't of any help if gettext might be used someday?!? Christina Am 28.02.2011 16:37, schrieb Andras Timar: 2011/2/28 Christina Roßmanithchrrossman...@web.de: Hi, I admit, I can't follow the discussion. But during translation: are the '~' important? Some lines of a diff for translation of comments: -/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik kopieren */ -/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik kopieren */ -/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik kopieren */ +/* ### ATTENTION: new text in resource? copy graphic : copy graphic */ +/* ### ATTENTION: new text in resource? copy graphic : copy graphic */ +/* ### ATTENTION: new text in resource? copy graphic : copy graphic */ And it seems that there is a certain redundancy. Or is it important to keep three copies of the same line. Is ACHTUNG a keywort which is searched for? Or is it safe to translate it to ATTENTION? Thank you for any low-level explanation :-) Hi, I don't think we need /* ### ACHTUNG: comments at all in resource files. Probably they were inserted by a script long time ago, when the source language was German. They do not look useful now. They can be removed. Just my 2 cents... Cheers, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Comment translation of writer/sw/source/ui/dochdl
Hi, reviewed and pushed. Changed your translation of Textbaustein = text block to auto text because I think that is what LibreOffice uses as term. Christina Am 27.02.2011 21:21, schrieb Martin Kepplinger: Hi, This translates all german code comments in writer/sw/source/ui/dochdl to english. For reviewing, thanks in advance! martin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Nonsense comments?
Hi, I admit, I can't follow the discussion. But during translation: are the '~' important? Some lines of a diff for translation of comments: -/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik kopieren */ -/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik kopieren */ -/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik kopieren */ +/* ### ATTENTION: new text in resource? copy graphic : copy graphic */ +/* ### ATTENTION: new text in resource? copy graphic : copy graphic */ +/* ### ATTENTION: new text in resource? copy graphic : copy graphic */ And it seems that there is a certain redundancy. Or is it important to keep three copies of the same line. Is ACHTUNG a keywort which is searched for? Or is it safe to translate it to ATTENTION? Thank you for any low-level explanation :-) Christina Am 27.02.2011 10:27, schrieb Andras Timar: Hi, 2011/2/25 Caolán McNamaracaol...@redhat.com: On Fri, 2011-02-25 at 20:37 +0100, Christina Roßmanith wrote: timar: po files can have translator-comments in them to help translators about ambiguous terms/words, while the .src/.sdf format doesn't though, right ? I recall a problem with trying to get the Spanish translation of an obscure paper size (8.5 x 13 ) set as Oficio given that this paper size is known as that in the handful of Latin American nations that use it, rather than some literal Spanish translation of Long Bond as the size is known in e.g. the Philippines. Would it be helpful to have a medium-level hack to add translator-comment support to the translation tools to help flag that sort of thing ? In fact it is possible to add comments to strings, there is the special language code x-comment. Alas, it is not extracted to SDF so it is not very useful for translators. It would be helpful, if it worked. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] removed BMP_FEHLT
Hi,
I've removed BMP_FEHLT in two files. Build was successful.
Christina Rossmanith
From 83e4b188a4655bf55c43161ca1501917b4bb44a1 Mon Sep 17 00:00:00 2001
From: Christina Rossmanith chrrossman...@web.de
Date: Fri, 25 Feb 2011 18:19:26 +0100
Subject: [PATCH] removed BMP_FEHLT
---
sw/source/ui/app/app.src |3 ---
sw/source/ui/inc/app.hrc |3 ---
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/sw/source/ui/app/app.src b/sw/source/ui/app/app.src
index 5a597ae..6771554 100644
--- a/sw/source/ui/app/app.src
+++ b/sw/source/ui/app/app.src
@@ -169,9 +169,6 @@ SfxStyleFamilies DLG_STYLE_DESIGNER
-// Default Bitmap for Toolbox
-BITMAP BMP_FEHLT { FILE = x.bmp ; };
-
// Bitmap for the NumberingTemplates in the Organizer
Bitmap BMP_STYLES_FAMILY_NUM { File = styfamnu.bmp ; };
diff --git a/sw/source/ui/inc/app.hrc b/sw/source/ui/inc/app.hrc
index 30ca41b..9d017f5 100644
--- a/sw/source/ui/inc/app.hrc
+++ b/sw/source/ui/inc/app.hrc
@@ -30,9 +30,6 @@
#include rcid.hrc
-// Default Bitmap fuer ToolBox
-#define BMP_FEHLT (RC_APP_BEGIN + 1)
-
// Document-Icon
#define RC_DOC_ICON (RC_APP_BEGIN + 2)
--
1.7.0.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] [PUSHED] removed BMP_FEHLT
Commented it first, then treated it as commented code, removed it and interpreted Thomas Arnold's reply Why don't you commit this by your self? as the license to push it on my own...any objections :-) Christina Am 25.02.2011 18:21, schrieb Christina Roßmanith: Hi, I've removed BMP_FEHLT in two files. Build was successful. Christina Rossmanith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] [PUSHED] Comment translation of writer/sw/source/ui/dialog
Pushed - thank you.
Christina
Am 25.02.2011 11:18, schrieb Martin Kepplinger:
This translates all code comments in this directory from german to english.
This is contributed under the terms of the MPL 1.1 / GPLv3+ / LGPLv3+ triple
license.
thanks,
martin
---
sw/source/ui/dialog/abstract.src |8 +--
sw/source/ui/dialog/ascfldlg.cxx |2 +-
sw/source/ui/dialog/dialog.src |4 +-
sw/source/ui/dialog/docstdlg.cxx |8 ++--
sw/source/ui/dialog/macassgn.cxx | 16
sw/source/ui/dialog/regionsw.cxx |6 +-
sw/source/ui/dialog/regionsw.src |4 +-
sw/source/ui/dialog/uiregionsw.cxx | 76 ++--
8 files changed, 61 insertions(+), 63 deletions(-)
diff --git a/sw/source/ui/dialog/abstract.src b/sw/source/ui/dialog/abstract.src
index ab5a863..ebb9082 100644
--- a/sw/source/ui/dialog/abstract.src
+++ b/sw/source/ui/dialog/abstract.src
@@ -34,9 +34,7 @@ ModalDialog DLG_INSERT_ABSTRACT
OutputSize = TRUE ;
SVLook = TRUE ;
Size = MAP_APPFONT ( 239 , 68 ) ;
-/* ### ACHTUNG: Neuer Text in Resource? AutoAbstract erzeugen :
AutoAbstrakt erzeugen */
-/* ### ACHTUNG: Neuer Text in Resource? AutoAbstract erzeugen :
AutoAbstrakt erzeugen */
-/* ### ACHTUNG: Neuer Text in Resource? AutoAbstract erzeugen :
AutoAbstrakt erzeugen */
+/* ### ATTENTION: New text in resource? create AutoAbstract : create
AutoAbstract */
Moveable = TRUE ;
FixedLine FL_1
{
@@ -70,7 +68,7 @@ ModalDialog DLG_INSERT_ABSTRACT
{
Pos = MAP_APPFONT ( 12 , 27 ) ;
Size = MAP_APPFONT ( 120 , 8 ) ;
-/* ### ACHTUNG: Neuer Text in Resource? Absätze je Kapitel : Absõtze
je Kapitel */
+/* ### ATTENTION: New text in resource? paragraphs per chapter :
paragraphs per chapter */
Text [ en-US ] = Subpoints per level ;
};
NumericField NF_PARA
@@ -92,7 +90,7 @@ ModalDialog DLG_INSERT_ABSTRACT
{
Pos = MAP_APPFONT ( 12 , 43 ) ;
Size = MAP_APPFONT ( 165 , 16 ) ;
-/* ### ACHTUNG: Neuer Text in Resource? Im Abstrakt erscheint die
ausgewählte Anzahl von Absätzen aus den einbezogenen Kapitelebenen. : Im
Abstrakt erscheint die ausgewõhlte Anzahl von Absõtzen aus den einbezogenen
Kapitelebenen. */
+/* ### ATTENTION: New text in resource? The selected number of
paragraphs from the included outline levels appears in the abstract. : The
selected number of paragraphs from the included outline levels appears in the
abstract. */
WordBreak = TRUE ;
Text [ en-US ] = The abstract contains the selected number of paragraphs
from the included outline levels. ;
};
diff --git a/sw/source/ui/dialog/ascfldlg.cxx b/sw/source/ui/dialog/ascfldlg.cxx
index 893263d..745524c 100644
--- a/sw/source/ui/dialog/ascfldlg.cxx
+++ b/sw/source/ui/dialog/ascfldlg.cxx
@@ -266,7 +266,7 @@ SwAsciiFilterDlg::SwAsciiFilterDlg( Window* pParent,
SwDocShell rDocSh,
SetSizePixel( aSize );
}
-// initialisiere Zeichensatz
+// initialise character set
aCharSetLB.FillFromTextEncodingTable( pStream != NULL );
aCharSetLB.SelectTextEncoding( aOpt.GetCharSet() );
diff --git a/sw/source/ui/dialog/dialog.src b/sw/source/ui/dialog/dialog.src
index f3df744..55860f6 100644
--- a/sw/source/ui/dialog/dialog.src
+++ b/sw/source/ui/dialog/dialog.src
@@ -28,7 +28,7 @@
CheckBox CB_USE_PASSWD
{
-/* ### ACHTUNG: Neuer Text in Resource? ~Paßwort : ~Pa?wort */
+/* ### ATTENTION: New text in resource? ~password : ~password */
Text [ en-US ] = ~Password ;
};
CheckBox CB_READ_ONLY
@@ -37,7 +37,7 @@ CheckBox CB_READ_ONLY
};
String STR_LINKEDIT_TEXT
{
-/* ### ACHTUNG: Neuer Text in Resource? Verknüpfungen bearbeiten :
Verkn³pfungen bearbeiten */
+/* ### ATTENTION: New text in resource? edit links : edit links */
Text [ en-US ] = Edit links ;
};
String STR_PATH_NOT_FOUND
diff --git a/sw/source/ui/dialog/docstdlg.cxx b/sw/source/ui/dialog/docstdlg.cxx
index bd2711b..5b88900 100644
--- a/sw/source/ui/dialog/docstdlg.cxx
+++ b/sw/source/ui/dialog/docstdlg.cxx
@@ -102,7 +102,7 @@ SwDocStatPage::SwDocStatPage(Window *pParent, const
SfxItemSetrSet) :
}
/*
-Beschreibung: ItemSet fuellen bei Aenderung
+Description: fill ItemSet when changed
*/
@@ -115,7 +115,7 @@ void SwDocStatPage::Reset(const SfxItemSet/*rSet*/)
{
}
/*
- Beschreibung: Aktualisieren / Setzen der Daten
+ Description: update / set data
*/
@@ -131,7 +131,7 @@ void SwDocStatPage::SetData(const SwDocStatrStat)
}
/*
-
[Libreoffice] Nonsense comments?
Hi,
while reviewing a patch I came across a lot of comments like
CheckBox CB_USE_PASSWD
{
/* ### ATTENTION: New text in resource? ~password : ~password */
Text [ en-US ] = ~Password ;
};
String STR_LINKEDIT_TEXT
{
/* ### ATTENTION: New text in resource? edit links : edit links */
Text [ en-US ] = Edit links ;
};
The message doesn't sound very exciting - so why all those ATTENTION?
I'd suggest to remove the comments. It always follows the pattern
/* ### ATTENTION: New text in resource? msg : msg */
Text [ en-US ] = msg ;
One of these messages is Subpoints per level which should be subitems.
May I change this (sw/source/ui/dialog/abstract.src)?
Christina Rossmanith
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
