Bug 63905 - printing with Draw/Impress

2014-03-31 Thread Tibby Lickle
Hi all,

I've been working on fixing fdo#63905 (
https://bugs.freedesktop.org/show_bug.cgi?id=63905) and came across a
comment in the code (
http://opengrok.libreoffice.org/xref/core/include/vcl/print.hxx#524) to the
effect of Draw/Impress never using the page format specified in the Format
- Page dialog for printing but instead using the paper size set by the
printer (unlike Writer and Calc). The bug behaviour seems to back this
up. I've only had a chance to test with a virtual printer so far, but
changing paper size in the printer settings (as well as in Format - Page)
allows the page to be printed to the correct paper size.

I was wondering if anyone could shed some light on this bug and/or why this
design decision was undertaken?

Cheers,

Eilidh
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] FYI: Latest Oracle move wrt to OpenOffice.org

2011-06-01 Thread Tibby Lickle
It's like throwing out the baby with the bath water - they're just
throwing away so much experience. I certainly wouldn't want to be
facing something the size of LO/OOo without a team who've had to deal
with it before :)

I'm fairly new to LibreOffice and contributing to FOSS but the
community have been highly supportive of my questions and
cluelessness. I am fairly shy online and not very confident in my
coding skills but there is so much infrastructure geared toward
getting newbies to contribute that it has been pretty much painless to
just get straight into it despite the terrifying size of the project.

I think that in part it's the people and in part it's the way things
are being done. It seems a shame to waste an opportunity to integrate
with a community with these advantages.

Eilidh


On Wed, Jun 1, 2011 at 6:01 PM, Norbert Thiebaud nthieb...@gmail.com wrote:
 Oracle announce:

 http://www.marketwire.com/press-release/statements-on-openofficeorg-contribution-to-apache-nasdaq-orcl-1521400.htm

 IBM is very happy to be able to continue Symphony without having to
 give code back... (they seems to rejoyce at being able to do selective
 GPL: i.e what is yours is mine... but what is mine is yours only for
 the peice I don't care about and would like you to maintain instead):
 http://www.edbrill.com/ebrill/edbrill.nsf/dx/openoffice-moving-to-apache-good-news-for-the-desktop-productivity-market
 The new project at Apache strengthens IBM's ability to continue to
 offer our own distributions of productivity tools based on the
 OpenOffice code base and make our own contributions to reinforce the
 overall community. 

 And IBM promise to contribute 'inovative' feature in the future:
 We have done a bunch of innovative things and one-plusses on top of
 the OO.o codebase, including accessibility work, the data pilot
 engine, and Office 2007 file format compatibility. 

 Of course 'innovative'(*) feature like Office 2007 compatibility and
 Data Pilot engine are already today in libreoffice...

 Norbert


 (*) aka IBM notorious NIH syndrome:
 http://en.wikipedia.org/wiki/Not_Invented_Here
 ___
 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] [GSoc] libvisio progress update

2011-05-30 Thread Tibby Lickle
A git repository has been set up for the Visio project and I've gotten
access rights to it - so for those of you wondering what the libvisio
folder is, it's this project.

We've gone with a heavily stream-based approach. Internal VSD streams
are decompressed and are seekable and readable. For this, libwpd has
been used as a base (WPXInputStream) as well as a source of utility
functions (e.g. converting bytes to uints) that work with
WPXInputStreams.

Right now, the project is successfully reading the trailer (this is
the compressed list of pointers to the other streams in the doc) and
getting the stream pointers. Success is currently defined by manual
comparison with what OleToy shows. The next step is figuring out which
types of streams are useful and dealing with them appropriately.

Eilidh
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice] [GSoc] Progress report - Visio import filter

2011-05-08 Thread Tibby Lickle
Hi,

Just an update on where I am. So far I've been working on the basics of
extracting the data from the .vsd file.
To read Visio files, the steps are roughly:
1. Get the interesting part (VisioDocument) from the OLE container.
2. Parse the header to get a pointer to the trailer stream (as well as
version, length of file, etc.)
3. Inflate compressed trailer.
4. Parse out pointers in trailer to the various - potentially compressed -
streams that hold the actual Visio document content.

I've done 1 - 3. I'm using the WPXStream and its implementation from libwpd
(WPXStreamImplementation.h
herehttp://libwpd.git.sourceforge.net/git/gitweb.cgi?p=libwpd/libwpd;a=blob;f=src/lib/WPXStreamImplementation.h;h=804453d910f537ffcf985a74ef34d6f25329d213;hb=HEAD)
to read/extract OLE streams.  The implementation of LZW-esque decompression
of the trailer is translated from Python to C++ (i.e. shamelessly ripped
off) from oletoy (thanks frob).
I suspect most of what I'll be doing will be stand-alone for now -
developing and debugging will be too slow if LO integration is included at
this early stage. Once I've got a very basic parser, the callback interface
discussed in my proposal will be implemented and integration with LO should
in theory be relatively easy.

Note to my mentor -- I've got a paper due for next Saturday so my main focus
will be on that. I will, however, be spending some time on the next stage.

Eilidh
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Calc Standard Filter behaviour

2011-03-11 Thread Tibby Lickle
On Fri, Mar 11, 2011 at 2:48 AM, Kohei Yoshida kyosh...@novell.com wrote:

  But before I commit your patches, we'd like to confirm that you are
 submitting your patches under LGPLv3+/MPL dual licenses.


I knew I'd forget something crucial - both are submitted under LGPLv3+/MPL.


  So, I'll retract my suggestion.  I'm convinced that the best solution
 here is not to have auto completion.  Sometimes less is more. :-)


Haha, agreed. Thank you for your advice and patience.

Tibby
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Calc Standard Filter behaviour

2011-03-10 Thread Tibby Lickle
I've attached patch for the (embarrassingly simple) fix for the filter
dialog as well as a German comment translation patch for the filter dialog
cxx and hxx files - feel free to reject this because my German is pretty
weak or if you'd rather have a larger chunk done at once.

On Wed, Mar 9, 2011 at 3:36 PM, Kohei Yoshida kyosh...@novell.com wrote:

 Now, to me the best solution is to *not* show any auto completion value
 in the text box itself, but to show a little popup box with possible
 auto-completion options to choose from, while leaving the typed value in
 the box intact.


What I tried to say before I completely failed to use the mailing list
properly was that I like this idea for a more advanced fix. It still
notifies the user that these special values are available but it doesn't get
in the way. It'd take quite a bit more difficult with a bit more involvement
in libs-gui as far as I can tell but I wouldn't mind giving it a go if you
still think it's a good idea.

For now, the auto-complete function is simply disabled.

Tibby
From 7824b7aedd1a1ff2de7166e53fb91a07ba20b5f0 Mon Sep 17 00:00:00 2001
From: Tibby tibbylic...@googlemail.com
Date: Thu, 10 Mar 2011 19:08:18 +
Subject: [PATCH 1/2] Disabled auto-complete in Calc filter dialog - fix for bug 34898.

A hyphen character caused auto-complete to kick in, changing the user's choice of conditional operator to =. This was not changed back if auto-complete option is overridden.
---
 sc/source/ui/dbgui/filtdlg.cxx |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/sc/source/ui/dbgui/filtdlg.cxx b/sc/source/ui/dbgui/filtdlg.cxx
index 71495f6..a95462a 100644
--- a/sc/source/ui/dbgui/filtdlg.cxx
+++ b/sc/source/ui/dbgui/filtdlg.cxx
@@ -263,6 +263,7 @@ void ScFilterDlg::Init( const SfxItemSet rArgSet )
 aFieldLbArr[i]-SelectEntryPos( nFieldSelPos );
 aCondLbArr [i]-SelectEntryPos( nCondPos );
 aValueEdArr[i]-SetText( aValStr );
+aValueEdArr[i]-EnableAutocomplete( FALSE );
 aValueEdArr[i]-SetModifyHdl( LINK( this, ScFilterDlg, ValModifyHdl ) );
 UpdateValueList( static_castUSHORT(i+1) );
 }
-- 
1.7.3.4

From 0857d20a89df71f614326cad08343baf1fe71c0d Mon Sep 17 00:00:00 2001
From: Tibby tibbylic...@googlemail.com
Date: Thu, 10 Mar 2011 21:18:45 +
Subject: [PATCH 2/2] German comment transation for Calc filter dialog.

---
 sc/source/ui/dbgui/filtdlg.cxx |   69 +++
 sc/source/ui/inc/filtdlg.hxx   |   10 +++---
 2 files changed, 39 insertions(+), 40 deletions(-)

diff --git a/sc/source/ui/dbgui/filtdlg.cxx b/sc/source/ui/dbgui/filtdlg.cxx
index a95462a..56c11b5 100644
--- a/sc/source/ui/dbgui/filtdlg.cxx
+++ b/sc/source/ui/dbgui/filtdlg.cxx
@@ -129,9 +129,9 @@ ScFilterDlg::ScFilterDlg( SfxBindings* pB, SfxChildWindow* pCW, Window* pParent,
 Init( rArgSet );
 FreeResource();
 
-// Hack: RefInput-Kontrolle
+// Hack: RefInput control
 pTimer = new Timer;
-pTimer-SetTimeout( 50 ); // 50ms warten
+pTimer-SetTimeout( 50 ); // Wait 50ms
 pTimer-SetTimeoutHdl( LINK( this, ScFilterDlg, TimeOutHdl ) );
 }
 
@@ -146,7 +146,7 @@ ScFilterDlg::~ScFilterDlg()
 delete pOptionsMgr;
 delete pOutItem;
 
-// Hack: RefInput-Kontrolle
+// Hack: RefInput control
 pTimer-Stop();
 delete pTimer;
 }
@@ -183,7 +183,7 @@ void ScFilterDlg::Init( const SfxItemSet rArgSet )
 pDoc	  	= pViewData ? pViewData-GetDocument() : NULL;
 nSrcTab		= pViewData ? pViewData-GetTabNo() : static_castSCTAB(0);
 
-// fuer leichteren Zugriff:
+// for easier access:
 aFieldLbArr	 [0] = aLbField1;
 aFieldLbArr	 [1] = aLbField2;
 aFieldLbArr	 [2] = aLbField3;
@@ -201,7 +201,7 @@ void ScFilterDlg::Init( const SfxItemSet rArgSet )
 aConnLbArr   [2] = aLbConnect3;
 aConnLbArr   [3] = aLbConnect4;
 
-// Optionen initialisieren lassen:
+// Option initialization:
 
 pOptionsMgr	 = new ScFilterOptionsMgr(
 this,
@@ -223,7 +223,7 @@ void ScFilterDlg::Init( const SfxItemSet rArgSet )
 aStrNoName,
 aStrUndefined );
 
-// Feldlisten einlesen und Eintraege selektieren:
+// Read in field lists and select entries
 
 FillFieldLists();
 
@@ -274,7 +274,7 @@ void ScFilterDlg::Init( const SfxItemSet rArgSet )
 aScrollBar.SetRange( Range( 0, 4 ) );
 aScrollBar.SetLineSize( 1 );
 aLbConnect1.Hide(); 
-// Disable/Enable Logik:
+// Disable/Enable Logic:
 
(aLbField1.GetSelectEntryPos() != 0)
  (aLbField2.GetSelectEntryPos() != 0)
@@ -333,10 +333,10 @@ void ScFilterDlg::Init( const SfxItemSet rArgSet )
 
 if(pDoc!=NULL 
 pDoc-GetChangeTrack()!=NULL) aBtnCopyResult.Disable();
-// Modal-Modus einschalten
+// Switch on modal mode
 //	SetDispatcherLock( TRUE );
-//@BugID 54702 Enablen/Disablen nur noch in Basisklasse
-//	SFX_APPWINDOW-Disable(FALSE);		//! allgemeine 

[Libreoffice] Calc Standard Filter behaviour

2011-03-08 Thread Tibby Lickle
Hi,

I'd like to work on https://bugs.freedesktop.org/show_bug.cgi?id=34898 as my
first ever open source contribution but need some guidance to what the
actual behaviour should be.

Currently, when a minus symbol (-) is entered, the condition combo box is
disabled and set to equals, regardless of the previous input. This is due to
the auto completion on the value combo box kicking in and selecting the
special - not empty - string. However, if the user overrides the auto
complete with a valid value (e.g. -5), the condition box is re-enabled but
stays on equals. I have a few possibilities for how it should behave:

1. Remember the original user-entered condition for each row in the filter
and replace the = with it if the user enters a non-special value.
2. Don't accept the auto complete value as final until some other user
interaction (e.g. the value combo box loses focus or the user clicks the OK
button) occurs.

Seems trivial but I don't want it to seem inconsistent. What would suit
LibreOffice best?

Also - is it best to discuss things like this here or on bugzilla?

Thanks,
Tibby
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice