Re: [Libreoffice] Formula cursor : bug or feature ?
Hi Regina, On 2010-12-31 at 14:21 +0100, Regina Henschel wrote: (Aside from that I have a lot of other wishes, for example: Free choice of color, nice scaling integral sign, easier way to add new symbols, alignment to equal sign in stacks and matrices, inheritance of font size from environment or style.) Go ahead and file all these to the Easy Hacks too! :-) It is no Wiki, so I cannot do it technically, and with regards to content, I do not know whether they are Easy. My point of view is that with enough guidance, every task is easy enough, or can be split into easy enough ones ;-) So let's file it there, if there is somebody interested, I think we can shape some code pointers etc. too. So far I filed it here: http://wiki.documentfoundation.org/Development/Easy_Hacks#General_formula_editor_improvements This is a wiki, you just need to create an account - please feel free to extend it with more information :-) And please - don't bash Jonas for the great work he's done, I am sure he aims to make it perfect for everyone; Please excuse me. I am sad that my posts has caused such an impression. Jonas, I would never bash you. I am sorry I read it as such. I guess it is enough, that they are in the OOo Issuetracker. But you are right for remarks concerning new visual formula editor. I'll file bug reports. Would be great to add URLs of these to the General formula editor improvements too, so that we have a collection of the painful use cases. Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Translated comments from German to English.
Hi,
my first patch...
Christina Rossmanith
From 5967c1f8775734ecf63ac41c8e4766df2147bb7c Mon Sep 17 00:00:00 2001
From: cr chrrossman...@web.de
Date: Mon, 3 Jan 2011 14:04:34 +0100
Subject: [PATCH] Translated comments from German to English.
---
.../source/controller/dialogs/tp_TitleRotation.cxx |2 +-
sc/inc/arealink.hxx|3 +-
sc/inc/attrib.hxx | 20 ++--
sc/inc/bigrange.hxx|2 +-
sc/inc/callform.hxx|4 +-
sc/inc/cell.hxx| 17 +--
sc/inc/cellsuno.hxx| 32 ++--
sc/inc/chartpos.hxx| 18 ++--
sc/inc/chgtrack.hxx| 150 +---
9 files changed, 117 insertions(+), 131 deletions(-)
diff --git a/chart2/source/controller/dialogs/tp_TitleRotation.cxx b/chart2/source/controller/dialogs/tp_TitleRotation.cxx
index f21fa6a..697b3a0 100644
--- a/chart2/source/controller/dialogs/tp_TitleRotation.cxx
+++ b/chart2/source/controller/dialogs/tp_TitleRotation.cxx
@@ -91,7 +91,7 @@ SfxTabPage* SchAlignmentTabPage::CreateWithoutRotation(Window* pParent,
BOOL SchAlignmentTabPage::FillItemSet(SfxItemSet rOutAttrs)
{
-//Seit 4/1998 koennen Texte frei gedreht werden: SCHATTR_TEXT_DEGREES
+//Since 04/1998 text can be rotated by an arbitrary angle: SCHATTR_TEXT_DEGREES
bool bStacked = aOrientHlp.GetStackedState() == STATE_CHECK;
rOutAttrs.Put( SfxBoolItem( SCHATTR_TEXT_STACKED, bStacked ) );
diff --git a/sc/inc/arealink.hxx b/sc/inc/arealink.hxx
index ac46754..b45c207 100644
--- a/sc/inc/arealink.hxx
+++ b/sc/inc/arealink.hxx
@@ -51,8 +51,7 @@ private:
ScRange aDestArea;
BOOLbAddUndo;
BOOLbInCreate;
-BOOLbDoInsert; // wird fuer das erste Update auf FALSE gesetzt
-
+BOOLbDoInsert; // is set to FALSE for first update (Is that comment correct? Can't find statement containing bDoInsert and FALSE using grok)
BOOL FindExtRange( ScRange rRange, ScDocument* pSrcDoc, const String rAreaName );
public:
diff --git a/sc/inc/attrib.hxx b/sc/inc/attrib.hxx
index 7ab362f..9200b88 100644
--- a/sc/inc/attrib.hxx
+++ b/sc/inc/attrib.hxx
@@ -38,8 +38,8 @@
//
-// Flags fuer durch Merge verdeckte Zellen
-// und Control fuer Auto-Filter
+// flags for cells hidden by merge
+// and control for auto filter
#define SC_MF_HOR 0x0001
#define SC_MF_VER 0x0002
#define SC_MF_AUTO 0x0004 /// autofilter arrow
@@ -161,7 +161,7 @@ public:
//
-// ScRangeItem: verwaltet einen Tabellenbereich
+// ScRangeItem: manages an area of a table
#define SCR_INVALID 0x01
#define SCR_ALLTABS 0x02
@@ -180,7 +180,7 @@ public:
inline ScRangeItem operator=( const ScRangeItem rCpy );
-// pure virtual Methoden vom SfxPoolItem
+// pure virtual methods from SfxPoolItem
virtual int operator==( const SfxPoolItem ) const;
virtual SfxItemPresentation GetPresentation( SfxItemPresentation ePres,
SfxMapUnit eCoreMetric,
@@ -201,7 +201,7 @@ private:
};
inline ScRangeItem::ScRangeItem( const USHORT nWhichP )
-: SfxPoolItem( nWhichP ), nFlags( SCR_INVALID ) // == ungueltige Area
+: SfxPoolItem( nWhichP ), nFlags( SCR_INVALID ) // == invalid area
{
}
@@ -223,7 +223,7 @@ inline ScRangeItem ScRangeItem::operator=( const ScRangeItem rCpy )
}
//
-// ScTableListItem: verwaltet eine Liste von Tabellen
+// ScTableListItem: manages a list of tables
//
class ScTableListItem : public SfxPoolItem
{
@@ -236,7 +236,7 @@ public:
ScTableListItem operator=( const ScTableListItem rCpy );
-// pure virtual Methoden vom SfxPoolItem
+// pure virtual Methoden from SfxPoolItem
virtual int operator==( const SfxPoolItem ) const;
virtual SfxItemPresentation GetPresentation( SfxItemPresentation ePres,
SfxMapUnit eCoreMetric,
@@ -255,7 +255,7 @@ inline ScTableListItem::ScTableListItem( const USHORT nWhichP )
{}
//
-// Seitenformat-Item: Kopf-/Fusszeileninhalte
+// page format item: contents of header and footer
#define SC_HF_LEFTAREA 1
#define SC_HF_CENTERAREA 2
@@ -290,13 +290,13 @@ public:
void SetCenterArea( const
Re: [Libreoffice] making binfilter aka StarOffice FileFormat read-only
Hi Pierre-Andre, On 2010-12-30 at 17:30 +0100, Pierre-André Jacquod wrote: Thus, there is a major difference: With READONLY, no lock-file is generated when the file is openend. With filter without the EXPORT, the lock-file is still generated This comes during the load process, where the SfxMedium::IsReadOnly() function is called in order to decide if this lock-file has to be created or not.(Not spotted the exact place yet) Actually, I think this is not a correct behaviour. If the filter is not EXPORT; there is no reason to create the lock-file ? or ??? Should I consider changing the code of the loading part, in order to not create a lock-file if the filter has not EXPORT properties? From file point of view, this is the same case: you can not save this file as-is. This is a good point - as you say, I agree we can omit the creation of the lock file. It would be good to double-check how it behaves when you have a format where you have one filter for reading, and other one for writing ;-) But either way, I don't think that actually creating the lock even though the filter is import-only is that serious issue, ie. you can remove the locking of the file later, it is not blocking your work. Second issue I see: (I just though of it right now, did not yet test / investigate): with opening in read/write and without EXPORT filter, what happens with the auto-save option, after some changes have been done? No idea, without testing myself. I think we could fallback to autosaving in ODF format, if we do not do it yet ;-) The filter, despite write is not usable (no export). ... So ideally could it be: not export, READONLY and pop-up ?? :- / I'd still prefer not to set the read-only flag if possible, it is a terribly annoying feature [see the other threads about read-only mode]. As outlined above, my favorite approach would be to 'disconnect' the binfilter from the save functionality first, add the dialog on open, and dialog pop-up just at the end of loading the document ? will search for the right place. Thanks a lot! Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Replacement table enhancement for Braille table
Hello Sophie, On Tue, 2010-12-28 at 17:12 +0300, Sophie Gautier wrote: Now would it be possible to enhance the replacement table so that we can execute the pattern *oe* to be replaced by the pattern *oeu* in each word containing this first pattern, that could be at the beginning of the word like in oeuf or in the middle like in boeuf. Well, we may have some performance issues trying to match a pattern or regexp against every single word... but that could be interesting to do: this could even be an easy hack. The same for the end of a word containing the pattern *ait at the end, only entering 3 will replace the *ait at the end of the word. Well, I don't really see this use case ;) Of course, we could use the search/replace function at the end, but it's a very different use than entering your whole text using the braille keyboard. What about adding it to the easy hacks list and enable it only with the experimental features? Regards, -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Annoying cursor behavior on sw tables
Hi Octavio, On Wed, 2010-12-29 at 20:58 -0800, Octavio Alvarez wrote: Now, look at this, this blog post documents the patch: :-O http://cedric.bosdonnat.free.fr/wordpress/?p=472 Hum, thanks for poking me on it... I would have skipped the thread otherwise. The thing is that Window::Invalidate() gets called if I move or if I type inside a table cell, which almost any key triggers, which is wrong. bUpdatedTable gets set to True inside SwCallLink::~SwCallLink() after some tests. Another option would be to correct those tests, but that would be far beyond my knowledge. The problem I tried to fix was that the whole row wasn't redrawn in some cases... I can't remember those for sure now but it was something like that: Make sure to have tables like this: +-+---+ |+---+| | || || | |+---+| | | | | +-+---+ Place your cursor in the right cell and go to the left: the cursor should go in the blank paragraph after the nested cell and show it. In that kind of cases some part of the border of the right cell wasn't redrawn IIRC. Considering the above blog post from cbos I removed the Invalidate() and tested inserting a 1x1 table inside the cell of another 1x1 table and it seemed to work and update correctly and open the collapsed cell if I place the cursor inside it (by pressing Left or Right, for example). It closes back again if I go outside the empty cell. Did you test with a case similar to the one above? Regards, -- Cedric ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] starmath / cppunit breakage in master
Hello, I'm very sorry the code I was playing with has caused problems. I guess I wasn't thinking when adding the first header outside the guards. The assertion_traits struct, I was expecting this to be a problem, but I didn't know what to do about it, sorry. Apologies, Luke ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Re: Annoying cursor behavior on sw tables
On Mon, 03 Jan 2011 01:52:01 -0800, Cedric Bosdonnat cbosdon...@novell.com wrote: The thing is that Window::Invalidate() gets called if I move or if I type inside a table cell, which almost any key triggers, which is wrong. bUpdatedTable gets set to True inside SwCallLink::~SwCallLink() after some tests. Another option would be to correct those tests, but that would be far beyond my knowledge. The problem I tried to fix was that the whole row wasn't redrawn in some cases... I can't remember those for sure now but it was something like that: Make sure to have tables like this: +-+---+ |+---+| | || || | |+---+| | | | | +-+---+ Place your cursor in the right cell and go to the left: the cursor should go in the blank paragraph after the nested cell and show it. In that kind of cases some part of the border of the right cell wasn't redrawn IIRC. Did you test with a case similar to the one above? Well, I did try several different combinations including different column sizes and nesting levels. The case you point out was also tested and I just retested it now. It works. I would say it performs better. In the patch included I also remove all uses and declaration of bUpdatedTable because it was only used on the removed if(). -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp 0001-SwCallLink-Removed-unnecesarry-Invalidate-call.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] LO Pootle
Hi Martin, On 2010-12-30 at 10:36 +0100, Martin Srebotnjak wrote: The Slovenian team will be working with sdf files (we have our own localization system that works with sdf, splits to po-s and finalizes back to sdf), so -1 from me. What exactly your system that works with sdf does? Is it available somewhere? [Public git/svn/hg/cvs?] From what you described above, you work with po's in the end, so I am somehow missing the point of insisting on sdf ;-) Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] LO Pootle
Hi Andras, On 2010-12-30 at 09:13 +0100, Andras Timar wrote: BTW - would it help you if we got rid of the sdf files, and instead we had .po files in the l10n git repository? [For sure it would help us who work with the git repos, because the sdf file format is just something incredibly terrible for version control.] Would you be able to merge directly from the OOo Pootle, or from .po files produced by that, or do you still need .sdf for part of your workflow? Assumption: translate-toolkit can convert translatable content back and forth without loss of information. Yes, I assume the same thing :-) I believe this assumption is true. Translate-toolkit has been used for a long time by many teams. My suggestion is that all l10n teams should use Pootle to submit their translations. This does not mean that they must use Pootle to translate. They can use Pootle, offline PO editing tools, xliff, or edit sdf file directly - it does not matter. However at the end translations must be uploaded to Pootle in .po format. Pootle - with a git back-end - will contain the master copy of translations. Sounds great to me. English sdf file should be produced regularly for Pootle update. l10n repository will be obsolete. Build should take .po files from git (Pootle back-end) and generate localized sdf files build-time. Problems: 1. How to import existing LibreOffice translations to Pootle? l10n repository contains monolingual (and sometimes outdated) sdf files. We can export up-to-date bilingual (en-US + translated) sdf files from the source, but we cannot make a difference between untranslated strings and strings that are intentionally same as en-US (URLs, code, function names, language names etc.). Sun stored translations in a database (not public) and they kept track of this information - this cannot be extracted from the source. I think that with a simple heuristic, we might get quite good results: - if there exists a language that has a translation = mark the string as not translated - if there no translation in any language, mark as fuzzy; it probably is an URL or something We can play a bit with the % of languages that have the translation for the fuzzy / not translated at all split; I hope it might work reasonably well. 2. How to merge translations from OpenOffice.org? I think it should be decided individually for each language team. Automatic merge should happen for only those languages that do not have LibreOffice translators. Of course technical support should be provided for all. Translators don't need to understand the technical details. I think members of this list have the knowledge, we can put together a good process. Sounds good to me. Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] De-Java-ise flat XML export
Hi Jan,
I'm attaching a patch I somehow managed to patiently pull out of git :-)
As I'm new to C++, libxslt, git and a few other things involved in
creating the patch I feel it must be full of warts and cause random
crashes, but it seems to work and might be useful anyway.
Basically, the patch provides an alternative service implementation
to be used by XSLTFilter.cxx. Use of the libxslt implementation can be
triggered by adding libxslt as second parameter to the UserData
configuration of an xslt filter. This second parameter is currently
unused for xslt filters.
To completely remove the java dependency for xslt filters, the
xsltvalidation service would also need to be replaced by an
implementation based on libxslt.
Also, the Office 2003 XML export filters use a saxon extension
implemented in Java, which needs to be replaced by a libxslt extension
if Office 2003 XML export should be supported without Java, too.
The flat xml export could be implemented as a pure C++ xml Filter
indendendently of the xslt filter, as proposed in the SDK examples, I
suppose, and I'd like to do that next.
I personally like the idea to make the implementation to use
configurable, instead of completely removing the Java based xslt filter
implementation.
Cheers,
Peter
Am Donnerstag, den 30.12.2010, 02:07 +0100 schrieb Jan Holesovsky:
Hi Peter,
On 2010-12-29 at 14:29 +0100, Peter Jentsch wrote:
I've gotten so far as to have a working implementation of XSLTFilter
which uses libxml2/libxslt to do the XSL transformation. It's still
missing some details like passing parameters to the xslt script, but it
works for the flat xml export and for xhtml export as well. Using this
implementation would remove the java dependency from xslt filter
processing,
Wow, cool! :-) Can you please post the patch here, so that we can have
a look? This sounds great.
Regards,
Kendy
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
From f3e5ff4c1ec9ecc01f92263f6fbe9a3f35dcfb16 Mon Sep 17 00:00:00 2001
From: Peter Jentsch pj...@guineapics.de
Date: Sun, 2 Jan 2011 14:02:18 +0100
Subject: [PATCH 1/2] Added support for libxslt in xsltfilter
libxslt will be used to perform xsl transformations if either Java is
not available/configured at compile time or the 2nd, currently unused
UserData parameter of the xslt filter is libxslt (w/o the quotes)
---
filter/source/xsltfilter/LibXSLTTransformer.cxx | 282 +++
filter/source/xsltfilter/LibXSLTTransformer.hxx | 145
filter/source/xsltfilter/XSLTFilter.cxx | 129 +++
filter/source/xsltfilter/makefile.mk| 16 ++-
4 files changed, 526 insertions(+), 46 deletions(-)
create mode 100644 filter/source/xsltfilter/LibXSLTTransformer.cxx
create mode 100644 filter/source/xsltfilter/LibXSLTTransformer.hxx
diff --git a/filter/source/xsltfilter/LibXSLTTransformer.cxx b/filter/source/xsltfilter/LibXSLTTransformer.cxx
new file mode 100644
index 000..da51908
--- /dev/null
+++ b/filter/source/xsltfilter/LibXSLTTransformer.cxx
@@ -0,0 +1,282 @@
+ /* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
+ // MARKER(update_precomp.py): autogen include statement, do not remove
+ #include precompiled_filter.hxx
+
+ #include stdio.h
+ #include list
+ #include map
+ #include iostream
+ #include libxml/parser.h
+ #include libxml/tree.h
+ #include libxml/xmlIO.h
+ #include libxslt/transform.h
+ #include libxslt/xsltutils.h
+ #include libxslt/variables.h
+
+ #include cppuhelper/factory.hxx
+ #include cppuhelper/servicefactory.hxx
+ #include cppuhelper/implbase4.hxx
+ #include cppuhelper/implbase.hxx
+ #include osl/module.h
+ #include osl/file.hxx
+ #include osl/process.h
+ #include com/sun/star/lang/XComponent.hpp
+ #include com/sun/star/lang/XInitialization.hpp
+ #include com/sun/star/uno/Any.hxx
+ #include com/sun/star/beans/NamedValue.hpp
+ #include com/sun/star/io/XInputStream.hpp
+ #include com/sun/star/io/XOutputStream.hpp
+ #include com/sun/star/io/XActiveDataSource.hpp
+ #include com/sun/star/io/XActiveDataSink.hpp
+ #include com/sun/star/io/XActiveDataControl.hpp
+ #include com/sun/star/io/XStreamListener.hpp
+
+ #include LibXSLTTransformer.hxx
+
+ using namespace ::rtl;
+ using namespace ::cppu;
+ using namespace ::osl;
+ using namespace ::com::sun::star::beans;
+ using namespace ::com::sun::star::io;
+ using namespace ::com::sun::star::uno;
+ using namespace ::com::sun::star::lang;
+ using namespace ::com::sun::star::registry;
+ using ::std::list;
+ using ::std::map;
+ using ::std::pair;
+
+ namespace XSLT {
+ const char* const LibXSLTTransformer::PARAM_SOURCE_URL = sourceURL;
+ const char* const LibXSLTTransformer::PARAM_SOURCE_BASE_URL = sourceBaseURL;
+ const char* const LibXSLTTransformer::PARAM_TARGET_URL = targetURL;
+ const char* const
Re: [Libreoffice] [PATCH] UX New layout Move/Copy sheet in calc
Hello Joost, On Tue, 2010-12-28 at 16:45 +0100, Joost Eekhoorn wrote: Hoi Kohei and all, I hope you enjoy the lovely weather. Hereby a patch to give a better user experience to the Move/Copy sheet dialog. The changes are: - Removed the Renamecheckbox. The New name textfield is always available, when one sheet is selected. It is disabled, when multiple sheets are selected. - OK, Cancel and Help buttons placed at the bottom of the dialog. - Copy checkbox replaced by Copy and Move option buttons. - Added 3 section headers: Action, Location and Name. - Placed the text (Current document) behind the name of the of the current document in the list To document. - Display the yellow warning ! This name is already used, when applicable. This all looks good. Once again, I've taken the liberty of making some follow-up modifications after your patch. I basically did: * adjusted the dialog layout a bit to make it look more consistent make better use of available spaces if possible. With this, the list box etc are little wider. * added three different warning messages for different causes: 1) name already used, 2) name is empty, and 3) name has invalid characters. * disable the OK button when the new name is invalid. I did not know a better way to display the warning (I searched several hours.) I think the way you did it is sufficient; but I'd like us to eventually find a way to turn the background of the sheet name box pink (or light red, whatever the actual color is) the same way the chart dialogs do while the background color of the warning text stays transparent. IMO that would fit a little better and more consistent with the rest of our UI. I haven't found a way to change the color of edit box either, so we can leave that a future project for now. I did not changed the Insert before listbox. I think it's best if we leave this alone for now. We'll probably come back to it later. I do not display the current sheet name. I assume you mean displaying the current sheet name in the title bar of the dialog box. Yeah we'll leave this a future project too. Thanks a lot for your patch. :-) Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] starmath / cppunit breakage in master
On Mon, Jan 03, 2011 at 02:46:53PM +, Luke Dixon 6b8b4...@gmail.com wrote: I'm very sorry the code I was playing with has caused problems. I guess I wasn't thinking when adding the first header outside the guards. The assertion_traits struct, I was expecting this to be a problem, but I didn't know what to do about it, sorry. No problem, that happens[1]. :) [1] http://article.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/1349 pgpIuOHrBBqtO.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] provide the long prefix '--' for options, e.g., --help
Hello Takeshi, On Fri, 2010-12-31 at 14:04 +0900, Takeshi Abe wrote: Hi, Here is the patch for providing the long prefix -- for soffice's options; this solves the Easy Hack 3.7 [1]. The patch looks good. I just pushed it to master. The only changes I made are just fixing some coding styles and updating the cmdline help to promote --foo style options. Thanks a lot! Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Translated comments from German to English.
On Mon, 2011-01-03 at 14:22 +0100, Christina Roßmanith wrote: Hi, my first patch... Nicely done for your very first patch. :-) BTW, since you asked the following question -BOOLbDoInsert; // wird fuer das erste Update auf FALSE gesetzt - +BOOLbDoInsert; // is set to FALSE for first update (Is that comment correct? Can't find statement containing bDoInsert and FALSE using grok) bDoInsert can in fact be FALSE in ScDocFunc::InsertAreaLink (docfunc.cxx line 4923) where the flag value is set via SetDoInsert() method. If bFitBlock value there is false, then bDoInsert will become false too. For future reference, we ask that you set your real name in your local git configuration in order to get your real name appear in your commit log. You can do so by git config --global user.name Your Name For this commit, I put your real name manually from your post. Thanks a lot! Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removed dependencies on tools/solar.h
On Mon, 2011-01-03 at 21:47 +0100, Soeren Moeller wrote: Hi I have removed dependencies on tools/solar.h in some files in sc (according to http://wiki.documentfoundation.org/Easy_Hacks#write_tools.2F_pieces_out ) please review and commit. Thanks, pushed! BTW, we generally prefer the standard bool over sal_Bool, so I replaced sal_Bool with bool in your patch. The only place we need to use sal_Bool is when dealing with the UNO API. Other than that, the standard boolean type is preferred. Also, it's a bit weird to use sal_uIntPtr which isn't used much in our code base. So I replaced that with sal_uInt32. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] cppcheck at writer, performance.
On Thu, 2010-12-30 at 13:23 -0200, Kayo Hamid wrote: So, it's a small patch that I send for review because I do not know if it's ok to do what the cppcheck says to do. In this case, he says that for non-primitive types we can do ++test instead test++. My fear is if in the code really need to be test++, understand? In those use cases it makes no difference whether it's a post- or pre-increment. It matters only when its return value is stored used. I pushed your patch to master. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] starmath / cppunit breakage in master
On Tue, 2011-01-04 at 04:08 +0100, Miklos Vajna wrote: Hi, Looks like there is something similar in sc as well, see the attached log. I tried guarding #include mdds/mixed_type_matrix.hpp using #include preextstl.h / #include postextstl.h but that does not seem to help. Any other idea? :) Does setting #define MDDS_HASH_CONTAINER_STLPORT 1 before #include mdds/mixed_type_matrix.hpp help? I also saw someone having a similar issue in the same exact spot, which I haven't been able to reproduce. I guess this is specific to system-mdds. Conceptually there should be no difference whether it's system or internal, since mdds is just a collection of header files with no libraries to build or link against. From the looks of the log file, it *may* have some issues with gcc 4.5.x's implementation of unordered_map, but I'm not sure 100%... Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Patch] Make SVG filter export text color
Dear LibreOffice community,
I wrote patches for SVG export filter.
These fix a bug that texts in an exported SVG are invisible.
The most of codes come from Flash export filter
(filters/filter/source/swfwriter1.cxx).
Regards,
--
KUROSAWA, Takeshi taken@gmail.com
From e10fcbcc9d95eb24505126e6b9ea0313cccd7434 Mon Sep 17 00:00:00 2001
From: Takeshi Kurosawa taken@gmail.com
Date: Tue, 4 Jan 2011 13:18:55 +0900
Subject: [PATCH 1/4] Add 'px' unit to 'font-size'
Firefox and Opera don't accept unitless font-size values.
---
filter/source/svg/svgwriter.cxx |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/filter/source/svg/svgwriter.cxx b/filter/source/svg/svgwriter.cxx
index 8b18650..af305ac 100644
--- a/filter/source/svg/svgwriter.cxx
+++ b/filter/source/svg/svgwriter.cxx
@@ -265,6 +265,7 @@ NMSP_RTL::OUString SVGAttributeWriter::GetFontStyle( const Font rFont )
aStyle += B2UCONST( ; );
aStyle += B2UCONST( font-size: );
aStyle += SVGActionWriter::GetValueString( rFont.GetHeight() );
+aStyle += B2UCONST( px );
// font style
/*
--
1.7.1
From 8a4d52c041f691003a34c5107c88c0f820bd1178 Mon Sep 17 00:00:00 2001
From: Takeshi Kurosawa taken@gmail.com
Date: Tue, 4 Jan 2011 13:22:26 +0900
Subject: [PATCH 2/4] Use simple syntax for glyph definition
Opera and Chrome don't support complex syntax for SVG fonts glyph definition (child elements of glyph element).
---
filter/source/svg/svgfontexport.cxx | 27 ++-
1 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/filter/source/svg/svgfontexport.cxx b/filter/source/svg/svgfontexport.cxx
index 605f878..0c00a06 100644
--- a/filter/source/svg/svgfontexport.cxx
+++ b/filter/source/svg/svgfontexport.cxx
@@ -168,15 +168,11 @@ void SVGFontExport::implEmbedFont( const ::rtl::OUString rFontName, const ::std
mrExport.AddAttribute( XML_NAMESPACE_NONE, horiz-adv-x, SVGActionWriter::GetValueString( aSize.Width() ) );
+mrExport.AddAttribute( XML_NAMESPACE_NONE, style, B2UCONST( fill:none;stroke:black;stroke-width:33 ) );
+mrExport.AddAttribute( XML_NAMESPACE_NONE, d, SVGActionWriter::GetPathString( aMissingGlyphPolyPoly, sal_False ) );
+
{
SvXMLElementExport aExp3( mrExport, XML_NAMESPACE_NONE, missing-glyph, TRUE, TRUE );
-
-mrExport.AddAttribute( XML_NAMESPACE_NONE, style, B2UCONST( fill:none;stroke:black;stroke-width:33 ) );
-mrExport.AddAttribute( XML_NAMESPACE_NONE, d, SVGActionWriter::GetPathString( aMissingGlyphPolyPoly, sal_False ) );
-
-{
-SvXMLElementExport aExp4( mrExport, XML_NAMESPACE_NONE, path, TRUE, TRUE );
-}
}
while( aIter != rGlyphs.end() )
@@ -213,18 +209,15 @@ void SVGFontExport::implEmbedGlyph( OutputDevice rOut, const ::rtl::OUString r
mrExport.AddAttribute( XML_NAMESPACE_NONE, horiz-adv-x, SVGActionWriter::GetValueString( aBoundRect.GetWidth() ) );
+const ::rtl::OUString aPathString( SVGActionWriter::GetPathString( aPolyPoly, sal_False ) );
+
+if( aPathString.getLength() )
+{
+mrExport.AddAttribute( XML_NAMESPACE_NONE, d, aPathString );
+}
+
{
SvXMLElementExportaExp( mrExport, XML_NAMESPACE_NONE, glyph, TRUE, TRUE );
-const ::rtl::OUString aPathString( SVGActionWriter::GetPathString( aPolyPoly, sal_False ) );
-
-if( aPathString.getLength() )
-{
-mrExport.AddAttribute( XML_NAMESPACE_NONE, d, aPathString );
-
-{
-SvXMLElementExport aElem( mrExport, XML_NAMESPACE_NONE, B2UCONST( path ), TRUE, TRUE );
-}
-}
}
}
}
--
1.7.1
From da3b25f75fd1293b5278e056b080703ad531ce29 Mon Sep 17 00:00:00 2001
From: Takeshi Kurosawa taken@gmail.com
Date: Tue, 4 Jan 2011 13:25:12 +0900
Subject: [PATCH 3/4] Remove redundant 'g' element
pTransform is completely redundant.
---
filter/source/svg/svgwriter.cxx |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/filter/source/svg/svgwriter.cxx b/filter/source/svg/svgwriter.cxx
index af305ac..608f6b5 100644
--- a/filter/source/svg/svgwriter.cxx
+++ b/filter/source/svg/svgwriter.cxx
@@ -848,7 +848,6 @@ void SVGActionWriter::ImplWriteText( const Point rPos, const String rText,
const Font rFont = mpVDev-GetFont();
const FontMetric aMetric( mpVDev-GetFontMetric() );
PointaBaseLinePos( rPos );
-SvXMLElementExport* pTransform = NULL;
// always adjust text position to match baseline alignment
switch( rFont.GetAlign() )
@@ -904,7 +903,6 @@ void SVGActionWriter::ImplWriteText( const Point rPos, const String rText,
aTransform += ')';
mrExport.AddAttribute( XML_NAMESPACE_NONE, aXMLAttrTransform,
Re: [Libreoffice] Test script patch review request (1)
Hi Tor, Thanks a lot for reviewing and the comments, I haven't even known the '(un)expand' until you told :) To make it concise, do you think it is enough to replace 'Inital' Tabs with 4 space characters, while change other tabs with 1 space character. In addition the trailing spaces could be removed at the same time as the final step. Here is the method I intend to update the patch, your further comments are appreciated, thank you! step 1. Replace Initial tabs with 4 space characters: $ cat /tmp/tabfile | while read fn ; do expand -i -t 4 $fn /tmp/no_initabfile; mv /tmp/no_initabfile $fn; done step 2. Replace all tabs in the middle/at the end of code with 1 space character: $ cat /tmp/tabfile | while read fn; do expand -t 1 $fn /tmp/no_tabfile; mv /tmp/no_tabfile $fn; done step 3. Remove all trailing spaces stepping through inc and bas files: $ find | grep -e bas$ -e inc$ | while read fn; do sed -r 's/ +$//' $fn /tmp/no_trailingspaces ; mv /tmp/no_trailingspaces $fn; done Best wishes, Yifan On Mon, Jan 03, 2011 at 04:51:28AM -0700, Tor Lillqvist wrote: cat /tmp/tabfile | sed 's/ //' /tmp/notabfile; Sorry, but just replacing every TAB character with a fixed number (in this case, four) of SPACE characters is incorrect. To properly expand TAB characters, each TAB needs to be replaced with a variable number of SPACE characters, depending on which column the TAB is in. For instance if you have a line: foo bar (i.e. foo, a TAB, and bar), the TAB should be replaced with just one SPACE. (Assuming the intended tab width is four columns, as it is in OOo/LO. Note that traditionally the tab width is eight columns.) (Also, you would want to use the g modifier in the sed 's' command to replace every TAB on each line, not just the first.) Anyway, the expand command is the right tool to expand tabs. P.S. Your script can be written much simpler, no need to use cat so much: while read fn /tmp/tabs.auto.filelist.txt; do sed 's/ //g' $fn /tmp/notabfile mv /tmp/notabfile $fn done (Here still incorrectly using sed and not expand.) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] cppcheck cleaning in vcl
On Thu, Dec 30, 2010 at 06:43:12PM +0100, Julien Nabet wrote: Hello, Here is a patch for cppcheck cleaning in vcl Compiling was ok. I'm not sure if what I did about realloc pb in the file : vcl/unx/source/gdi/xlfd_attr.cxx was sufficient (even correct !). If Enlarge() failed, Insert() silently returns whatever value mnLastmatch happened to be, that means that you replaced possible segfault with possible wrong behaviour :( IMHO the right thing here is to throw std::bad_alloc if the reallocation failed and I changed the patch accordingly. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] cppcheck cleaning in vcl
On Tue, Jan 04, 2011 at 08:23:36AM +0100, David Tardon wrote: On Thu, Dec 30, 2010 at 06:43:12PM +0100, Julien Nabet wrote: Hello, Here is a patch for cppcheck cleaning in vcl Compiling was ok. I'm not sure if what I did about realloc pb in the file : vcl/unx/source/gdi/xlfd_attr.cxx was sufficient (even correct !). If Enlarge() failed, Insert() silently returns whatever value mnLastmatch happened to be, that means that you replaced possible segfault with possible wrong behaviour :( IMHO the right thing here is to throw std::bad_alloc if the reallocation failed and I changed the patch accordingly. And I committed it under my own name by mistake. Sorry for that. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] starmath / cppunit breakage in master
Hi, Does setting #define MDDS_HASH_CONTAINER_STLPORT 1 before #include mdds/mixed_type_matrix.hpp help? I also saw someone having a similar issue in the same exact spot, which I haven't been able to reproduce. Maybe this is related. I had also a problem after having upgraded to mds 0.4.0 with an up to date (25.12.2010) git At the ende, I managed to compile making a hack to 0.4.0 (very dirty...). Since this part was outside of my understanding, I am not able to know if the error was from my side or not... and since you were on holliday I kept it if someone also run in trouble. Below more explanation. Since then, I did not recompile the whole stuff... take too long by me.:- ) regards I guess this is specific to system-mdds. Conceptually there should be no difference whether it's system or internal, since mdds is just a collection of header files with no libraries to build or link against. From the looks of the log file, it *may* have some issues with gcc 4.5.x's implementation of unordered_map, but I'm not sure 100%... I have tried make clean, make distclean I have used ./autogen.sh --with-num-cpus=2 --without-junit --disable-kde --enable-binfilter compiler: gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux) I did not success to compile, until I changed: libo_dev/solver/330/unxlngi6.pro/inc/mdds/hash_container/map.hpp simulating having MDDS_HASH_CONTAINER_STLPORT defined: like this: #else // c++0x #include hash_map #define _mdds_unordered_map_type ::std::hash_map //#include unordered_map //#define _mdds_unordered_map_type ::std::unordered_map #endif Else, I got error like Compiling: sc/source/core/tool/scmatrix.cxx In file included from /usr/include/c++/4.5/bits/stl_algobase.h:63:0, from /usr/include/c++/4.5/unordered_map:41, from /home/pjacquod/LibO_dev/libo_dev/solver/330/unxlngi6.pro/inc/mdds/hash_container/map.hpp:41, from /home/pjacquod/LibO_dev/libo_dev/solver/330/unxlngi6.pro/inc/mdds/mixed_type_matrix_flag_storage.hpp:32, from /home/pjacquod/LibO_dev/libo_dev/solver/330/unxlngi6.pro/inc/mdds/mixed_type_matrix.hpp:34, from /home/pjacquod/LibO_dev/libo_dev/clone/calc/sc/source/core/tool/scmatrix.cxx:45: /usr/include/c++/4.5/bits/cpp_type_traits.h:78:10: error: redefinition of 'struct _STL::__true_type' ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removed dependencies on tools/solar.h
On Mon, Jan 3, 2011 at 10:36 PM, Kohei Yoshida kyosh...@novell.com wrote: On Mon, 2011-01-03 at 21:47 +0100, Soeren Moeller wrote: Hi I have removed dependencies on tools/solar.h in some files in sc (according to http://wiki.documentfoundation.org/Easy_Hacks#write_tools.2F_pieces_out ) please review and commit. Thanks, pushed! BTW, we generally prefer the standard bool over sal_Bool, so I replaced sal_Bool with bool in your patch. The only place we need to use sal_Bool is when dealing with the UNO API. Other than that, the standard boolean type is preferred. Also, it's a bit weird to use sal_uIntPtr which isn't used much in our code base. So I replaced that with sal_uInt32. Kohei, I have not read the related code, but in principle uintptr_t and int32_t are not interchangeable. int32_t is 32 bit long, uintptr_t is supposed to be the same size than void* (that is 32 or 64 bits) in our sources, ULONG is typedef'ed as sal_uIntPrt (in tools/solar.h) , which is wrong (*) but that explain why Soeren used sal_uIntPtr. (*) it is wrong because there are multiple model of 64 bits support. Notoriously, Microsoft, as usual, instead of fixing their 64 bits support bugs, have, once again, turn their bugs into a standard and use the so-called LLP64 model, in which sizeof(long) != sizeof(void*) Note that ULONG is defined at multiple place, most of them as unsigned long (which conflict with the main definition of ULONG = sal_uIntPtr). Which raise the following question: has anyone successfully built LibreOffice for Win64 ? Note: C99 has been a standard for quite a while now. why are we not using the standardized type for these. that is: int8_t uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t, intptr_t, uintptr_t,... see http://en.wikipedia.org/wiki/Stdint.h Yes, I know, Microsoft still do not have a compiler compliant with the C-standard published 10 years ago... but that can be worked around with a compat.h header to hide Microsoft's screw-ups, without 'uglyfying' the rest of the code. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.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
Re: [Libreoffice] [PATCH] [PUSHED] new cppcheck cleaning in svx
On Fri, Dec 31, 2010 at 03:04:29PM +0100, Julien Nabet wrote: Hello, Here is a new patch for cppcheck cleaning in svx Compiling was ok I have no more this pb : [./svdotxln.cxx:67]: (style) The class 'ImpSdrObjTextLink' does not have a constructor. Julien (LGPLv3+ / MPL) commit 2441e55a06e314cf1876bee1809c7846f260087a Author: Julien Nabet serval2...@yahoo.fr Date: Fri Dec 31 14:59:47 2010 +0100 cppcheck cleaning diff --git a/svx/source/accessibility/AccessibleShape.cxx b/svx/source/accessibility/AccessibleShape.cxx index 1b2577a..8f7fddf 100644 --- a/svx/source/accessibility/AccessibleShape.cxx +++ b/svx/source/accessibility/AccessibleShape.cxx @@ -513,7 +513,7 @@ awt::Rectangle SAL_CALL AccessibleShape::getBounds (void) aValue = aBoundingBox; bFoundBoundRect = true; } -catch (beans::UnknownPropertyException e) +catch (beans::UnknownPropertyException e) I changed these from catch (SomeException e) to catch (SomeException const e) and removed the parameter name where it clearly was not used in the catch block. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
