Complaint: "buggy implementations"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Complaint: "buggy implementations"

William Lee Valentine
In response to Mr. Olsson's recent complaint about combining graphics
with text in Writer: my documentation for Writer (distinct from that
provided with OpenOffice) indicates that, when one wants a picture to
appear in one of Writer's documents, one should click on "Insert >
Picture > From file", then select the graphic from the listing displayed
for a given directory, then click on "Open", and the graphic will appear
(at the cursor position?) in the given document.

This seems straightforward. I do not understand why Mr. Olsson would
find this disconcerting or difficult.

In his reply, Martin Groensheij indicates that "the most reliable way
is to insert [the graphic] in a frame." I assume that the frame helps
because it fixes the position of the graphic within the document's
borders.

My question is: does Writer's documentation indicate that it is
preferable to insert graphics within frames?

-- William Lee Valentine


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

W. Robert J. Funnell, Prof.
On Sat, 24 Oct 2020, William Lee Valentine wrote:

> In response to Mr. Olsson's recent complaint about combining graphics
> with text in Writer: my documentation for Writer (distinct from that
> provided with OpenOffice) indicates that, when one wants a picture to
> appear in one of Writer's documents, one should click on "Insert >
> Picture >  From file", then select the graphic from the listing displayed
> for a given directory, then click on "Open", and the graphic will appear
> (at the cursor position?) in the given document.
>
> This seems straightforward. I do not understand why Mr. Olsson would
> find this disconcerting or difficult.

Inserting an image is indeed easy. mr. Olsson's concern was that, in a
large document with a lot of images, the image positions may change in
seemingly random ways and the images themselves may disappear. This
does happen.

> In his reply, Martin Groensheij indicates that "the most reliable way
> is to insert [the graphic] in a frame." I assume that the frame helps
> because it fixes the position of the graphic within the document's
> borders.

Most of my images are in frames because that's a good way to provide
captions. My experience is that frames move around in the same way aa
images do, and that frames don't prevent images from disappearing.

> My question is: does Writer's documentation indicate that it is
> preferable to insert graphics within frames?

If you want captions, I think the answer is yes. If not, I don't know.

- Robert


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

Dan Lewis

On 10/24/20 16:22, Robert Funnell wrote:

> On Sat, 24 Oct 2020, William Lee Valentine wrote:
>
>> In response to Mr. Olsson's recent complaint about combining graphics
>> with text in Writer: my documentation for Writer (distinct from that
>> provided with OpenOffice) indicates that, when one wants a picture to
>> appear in one of Writer's documents, one should click on "Insert >
>> Picture >  From file", then select the graphic from the listing
>> displayed
>> for a given directory, then click on "Open", and the graphic will appear
>> (at the cursor position?) in the given document.
>>
>> This seems straightforward. I do not understand why Mr. Olsson would
>> find this disconcerting or difficult.
>
> Inserting an image is indeed easy. mr. Olsson's concern was that, in a
> large document with a lot of images, the image positions may change in
> seemingly random ways and the images themselves may disappear. This
> does happen.
>
>> In his reply, Martin Groensheij indicates that "the most reliable way
>> is to insert [the graphic] in a frame." I assume that the frame helps
>> because it fixes the position of the graphic within the document's
>> borders.
>
> Most of my images are in frames because that's a good way to provide
> captions. My experience is that frames move around in the same way aa
> images do, and that frames don't prevent images from disappearing.
>
>> My question is: does Writer's documentation indicate that it is
>> preferable to insert graphics within frames?
>
> If you want captions, I think the answer is yes. If not, I don't know.
>
> - Robert

https://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides/OOo3.3_User_Guide_Chapters

Here is the documentation on how to use Writer and other components of
Apache Openoffice. I recommend Chapter 3 of the Getting Started Guide as
well as the entire Writer Guide. In the latter, every chapter has a
large number of screenshots without the problems that are seen in the
OP's original email.

Note how they do this while also learning how it is done.

Dan


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

W. Robert J. Funnell, Prof.
On Sat, 24 Oct 2020, Dan Lewis wrote:

> On 10/24/20 16:22, Robert Funnell wrote:
>>  On Sat, 24 Oct 2020, William Lee Valentine wrote:
>>
>>>  In response to Mr. Olsson's recent complaint about combining graphics
>>>  with text in Writer: my documentation for Writer (distinct from that
>>>  provided with OpenOffice) indicates that, when one wants a picture to
>>>  appear in one of Writer's documents, one should click on "Insert >
>>> Picture >   From file", then select the graphic from the listing
>>>  displayed
>>>  for a given directory, then click on "Open", and the graphic will appear
>>>  (at the cursor position?) in the given document.
>>>
>>>  This seems straightforward. I do not understand why Mr. Olsson would
>>>  find this disconcerting or difficult.
>>
>>  Inserting an image is indeed easy. mr. Olsson's concern was that, in a
>>  large document with a lot of images, the image positions may change in
>>  seemingly random ways and the images themselves may disappear. This does
>>  happen.
>>
>>>  In his reply, Martin Groensheij indicates that "the most reliable way
>>>  is to insert [the graphic] in a frame." I assume that the frame helps
>>>  because it fixes the position of the graphic within the document's
>>>  borders.
>>
>>  Most of my images are in frames because that's a good way to provide
>>  captions. My experience is that frames move around in the same way aa
>>  images do, and that frames don't prevent images from disappearing.
>>
>>>  My question is: does Writer's documentation indicate that it is
>>>  preferable to insert graphics within frames?
>>
>>  If you want captions, I think the answer is yes. If not, I don't know.
>>
>>  - Robert
>
> https://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides/OOo3.3_User_Guide_Chapters
>
> Here is the documentation on how to use Writer and other components of Apache
> Openoffice. I recommend Chapter 3 of the Getting Started Guide as well as the
> entire Writer Guide. In the latter, every chapter has a large number of
> screenshots without the problems that are seen in the OP's original email.
>
> Note how they do this while also learning how it is done.
>
> Dan
I'm afraid I don't understand your meaning. Certainly it helps to read
the documentation, but the fact that the documentation contains
screenshots that don't show the results of unexpected behaviours (or
bugs) doesn't mean that there aren't any unexpected behaviours (or
bugs).

- Robert


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

Hagar Delest-2
In reply to this post by William Lee Valentine
Le 24/10/2020 à 21:38, William Lee Valentine a écrit :

> In response to Mr. Olsson's recent complaint about combining graphics
> with text in Writer: my documentation for Writer (distinct from that
> provided with OpenOffice) indicates that, when one wants a picture to
> appear in one of Writer's documents, one should click on "Insert >
> Picture > From file", then select the graphic from the listing displayed
> for a given directory, then click on "Open", and the graphic will appear
> (at the cursor position?) in the given document.
>
> This seems straightforward. I do not understand why Mr. Olsson would
> find this disconcerting or difficult.
I fully understand Mr. Olsson's complaint. In the Forum, we are indeed
used to advise saving any picture to be embedded in AOO on the HD first
and then to insert it with the relevant menu.
However, this is not a very good user experience.
Why the user should not expect a copy-paste to carry over a picture as
it is?
Very often when I copy a pic from another application, it appears fine
and then after a short while (few seconds or a save operation), it is
replaced by a placeholder.
If AOO manages to display the pic in the first place, then why should it
lose it afterward?
Why AOO can't make a copy of the pic in the temporary files to prevent
any loss? Why can't it accomplish what the user has to do, that is, save
the file in its original format and insert it?
Note that I never filed a bug report for that. First because there
already too many reports for too few coders and second because I often
adjust the pic before actually inserting it in the document.
But still, many users expect a copy-paste to behave as a very trivial
operation.

> In his reply, Martin Groensheij indicates that "the most reliable way
> is to insert [the graphic] in a frame." I assume that the frame helps
> because it fixes the position of the graphic within the document's
> borders.
>
> My question is: does Writer's documentation indicate that it is
> preferable to insert graphics within frames?
>
> -- William Lee Valentine
Personally, I only anchor pics As character, it is clearly the most
robust anchoring. And I use tables if I need to have pics side by side
and/or add a caption.
Frames have always been tricky when it comes to resizing a pic inside.

Hagar


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

Peter Kovacs-3
Hello all,

Thanks for this discussion. Because it has been mentioned multiple times
now, we have a bug report. There is no need to fill a new one.

https://bz.apache.org/ooo/show_bug.cgi?id=115994

A Bug report alone does not fix the Bug. However we have so many of them
that this kind of discussion is really helpful to raise attention and to
structure the Issues.

I guess not all have the Issue on Mac? Maybe if we ciould collect the
current information, I can update the ticket:

I assume we have this now on windows, Linux, Mac? The report states only
mac is affected.

Can you confirm that this happens on 4.1.7?

Am 25.10.20 um 11:29 schrieb Hagar Delest:
> Le 24/10/2020 à 21:38, William Lee Valentine a écrit :
>> This seems straightforward. I do not understand why Mr. Olsson would
>> find this disconcerting or difficult.
> I fully understand Mr. Olsson's complaint. In the Forum, we are indeed
> used to advise saving any picture to be embedded in AOO on the HD
> first and then to insert it with the relevant menu.
> However, this is not a very good user experience.
I agree.
> Note that I never filed a bug report for that. First because there
> already too many reports for too few coders and second because I often
> adjust the pic before actually inserting it in the document.

Despite we are a view Coders it helps if Tickets are updated, and maybe
it would make sense to link support emails / forum issues. It is quite
hard to prioritize Tickets. However a prioritization is not a ranking
for a fix ;)

Everything helps, even if there are only people giving feedback by
updating the bugs. Just be nice when you do. The Software Product is on
community support.


All the best

Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

Rory O'Farrell
In reply to this post by Hagar Delest-2
On Sun, 25 Oct 2020 11:29:21 +0100
Hagar Delest <[hidden email]> wrote:

> Le 24/10/2020 à 21:38, William Lee Valentine a écrit :
> > In response to Mr. Olsson's recent complaint about combining graphics
> > with text in Writer: my documentation for Writer (distinct from that
> > provided with OpenOffice) indicates that, when one wants a picture to
> > appear in one of Writer's documents, one should click on "Insert >
> > Picture > From file", then select the graphic from the listing displayed
> > for a given directory, then click on "Open", and the graphic will appear
> > (at the cursor position?) in the given document.
> >
> > This seems straightforward. I do not understand why Mr. Olsson would
> > find this disconcerting or difficult.
> I fully understand Mr. Olsson's complaint. In the Forum, we are indeed
> used to advise saving any picture to be embedded in AOO on the HD first
> and then to insert it with the relevant menu.
> However, this is not a very good user experience.
> Why the user should not expect a copy-paste to carry over a picture as
> it is?
> Very often when I copy a pic from another application, it appears fine
> and then after a short while (few seconds or a save operation), it is
> replaced by a placeholder.
> If AOO manages to display the pic in the first place, then why should it
> lose it afterward?
> Why AOO can't make a copy of the pic in the temporary files to prevent
> any loss? Why can't it accomplish what the user has to do, that is, save
> the file in its original format and insert it?
> Note that I never filed a bug report for that. First because there
> already too many reports for too few coders and second because I often
> adjust the pic before actually inserting it in the document.
> But still, many users expect a copy-paste to behave as a very trivial
> operation.
>
> > In his reply, Martin Groensheij indicates that "the most reliable way
> > is to insert [the graphic] in a frame." I assume that the frame helps
> > because it fixes the position of the graphic within the document's
> > borders.
> >
> > My question is: does Writer's documentation indicate that it is
> > preferable to insert graphics within frames?
> >
> > -- William Lee Valentine
> Personally, I only anchor pics As character, it is clearly the most
> robust anchoring. And I use tables if I need to have pics side by side
> and/or add a caption.
> Frames have always been tricky when it comes to resizing a pic inside.
>
> Hagar

I have a working workaround, which I find reliable, but I still make regular timed/dated backups of any picture containing Writer or Impress documents, just in case.  

Working on linux (currently Xubuntu 20.04.1, but updating or new installing since 8.04) I disable the making of a backup (my NAS device doesn't like that and I haven't bothered to investigate why) and the regular saving of Autorecovery information. Result: stable editing.  I have found that activation of LanguageTool can also contribute some occasional instability, so if I am authoring/editing an Impress presentation, I will disable LanguageTool for the editing session.

I offer this solution merely as a personal workaround - it may or may not work for you, and does not absolve you from making regular timed/dated backups.

My suspicion - purely that - is that OpenOffice does not correctly Save its environment when it switches into autorecovery mode, and if interrupted by a keypress may lose its pointers to the pictures, which usually remain orphaned in the ODF archive; there may be some crosstalk between the keyboard input code and the autorecovery code.  

LibreOffice commissioned an expensive investigation into the lost pictures problem and spent 44,000 euro on it; however there are still occasional reports on Ask.libreoffice.org of lost pictures; how reliable is the computer experience of those reporting such losses is questionable.
 

--
Rory O'Farrell <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

Martin Groenescheij
In reply to this post by Peter Kovacs-3
The only issue I have seen is when you have a large document with a lot
of images and you start moving or shifting text around by copy and paste
in the document.
The behavior depend on how the images are anchored, in case the are
anchored to a page it is sometimes possible that pictures are laying on
top of each other.

Each author should know his word processing tool and work(around) with
the limitations.

On 25/10/2020 12:11, Peter Kovacs wrote:

> Hello all,
>
> Thanks for this discussion. Because it has been mentioned multiple
> times now, we have a bug report. There is no need to fill a new one.
>
> https://bz.apache.org/ooo/show_bug.cgi?id=115994
>
> A Bug report alone does not fix the Bug. However we have so many of
> them that this kind of discussion is really helpful to raise attention
> and to structure the Issues.
>
> I guess not all have the Issue on Mac? Maybe if we ciould collect the
> current information, I can update the ticket:
>
> I assume we have this now on windows, Linux, Mac? The report states
> only mac is affected.
>
> Can you confirm that this happens on 4.1.7?
>
> Am 25.10.20 um 11:29 schrieb Hagar Delest:
>> Le 24/10/2020 à 21:38, William Lee Valentine a écrit :
>>> This seems straightforward. I do not understand why Mr. Olsson would
>>> find this disconcerting or difficult.
>> I fully understand Mr. Olsson's complaint. In the Forum, we are
>> indeed used to advise saving any picture to be embedded in AOO on the
>> HD first and then to insert it with the relevant menu.
>> However, this is not a very good user experience.
> I agree.
>> Note that I never filed a bug report for that. First because there
>> already too many reports for too few coders and second because I
>> often adjust the pic before actually inserting it in the document.
>
> Despite we are a view Coders it helps if Tickets are updated, and
> maybe it would make sense to link support emails / forum issues. It is
> quite hard to prioritize Tickets. However a prioritization is not a
> ranking for a fix ;)
>
> Everything helps, even if there are only people giving feedback by
> updating the bugs. Just be nice when you do. The Software Product is
> on community support.
>
>
> All the best
>
> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

Dan Lewis
   There is a reason why graphics should be inserted in a frame and the
latter should be anchored to an empty paragraph. When anchored to a
page, the graphic was known to move to other places as in the end of the
document.

Dan


On 10/25/20 09:45, Martin Groenescheij wrote:

> The only issue I have seen is when you have a large document with a
> lot of images and you start moving or shifting text around by copy and
> paste in the document.
> The behavior depend on how the images are anchored, in case the are
> anchored to a page it is sometimes possible that pictures are laying
> on top of each other.
>
> Each author should know his word processing tool and work(around) with
> the limitations.
>
> On 25/10/2020 12:11, Peter Kovacs wrote:
>> Hello all,
>>
>> Thanks for this discussion. Because it has been mentioned multiple
>> times now, we have a bug report. There is no need to fill a new one.
>>
>> https://bz.apache.org/ooo/show_bug.cgi?id=115994
>>
>> A Bug report alone does not fix the Bug. However we have so many of
>> them that this kind of discussion is really helpful to raise
>> attention and to structure the Issues.
>>
>> I guess not all have the Issue on Mac? Maybe if we ciould collect the
>> current information, I can update the ticket:
>>
>> I assume we have this now on windows, Linux, Mac? The report states
>> only mac is affected.
>>
>> Can you confirm that this happens on 4.1.7?
>>
>> Am 25.10.20 um 11:29 schrieb Hagar Delest:
>>> Le 24/10/2020 à 21:38, William Lee Valentine a écrit :
>>>> This seems straightforward. I do not understand why Mr. Olsson would
>>>> find this disconcerting or difficult.
>>> I fully understand Mr. Olsson's complaint. In the Forum, we are
>>> indeed used to advise saving any picture to be embedded in AOO on
>>> the HD first and then to insert it with the relevant menu.
>>> However, this is not a very good user experience.
>> I agree.
>>> Note that I never filed a bug report for that. First because there
>>> already too many reports for too few coders and second because I
>>> often adjust the pic before actually inserting it in the document.
>>
>> Despite we are a view Coders it helps if Tickets are updated, and
>> maybe it would make sense to link support emails / forum issues. It
>> is quite hard to prioritize Tickets. However a prioritization is not
>> a ranking for a fix ;)
>>
>> Everything helps, even if there are only people giving feedback by
>> updating the bugs. Just be nice when you do. The Software Product is
>> on community support.
>>
>>
>> All the best
>>
>> Peter
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

W. Robert J. Funnell, Prof.
I've always had the impression that frames and images act the same in
terms of anchoring and subsequent positioning (including sometimes
unexpected behaviour of paragraph anchoring), and images can disappear
from within frames, so frames don't seem to be a cure-all.

- Robert

On Sun, 25 Oct 2020, Dan Lewis wrote:

>   There is a reason why graphics should be inserted in a frame and the latter
> should be anchored to an empty paragraph. When anchored to a page, the
> graphic was known to move to other places as in the end of the document.
>
> Dan
>
>
> On 10/25/20 09:45, Martin Groenescheij wrote:
>>  The only issue I have seen is when you have a large document with a lot of
>>  images and you start moving or shifting text around by copy and paste in
>>  the document.
>>  The behavior depend on how the images are anchored, in case the are
>>  anchored to a page it is sometimes possible that pictures are laying on
>>  top of each other.
>>
>>  Each author should know his word processing tool and work(around) with the
>>  limitations.
>>
>>  On 25/10/2020 12:11, Peter Kovacs wrote:
>>>  Hello all,
>>>
>>>  Thanks for this discussion. Because it has been mentioned multiple times
>>>  now, we have a bug report. There is no need to fill a new one.
>>>
>>>  https://bz.apache.org/ooo/show_bug.cgi?id=115994
>>>
>>>  A Bug report alone does not fix the Bug. However we have so many of them
>>>  that this kind of discussion is really helpful to raise attention and to
>>>  structure the Issues.
>>>
>>>  I guess not all have the Issue on Mac? Maybe if we ciould collect the
>>>  current information, I can update the ticket:
>>>
>>>  I assume we have this now on windows, Linux, Mac? The report states only
>>>  mac is affected.
>>>
>>>  Can you confirm that this happens on 4.1.7?
>>>
>>>  Am 25.10.20 um 11:29 schrieb Hagar Delest:
>>>>  Le 24/10/2020 à 21:38, William Lee Valentine a écrit :
>>>>>  This seems straightforward. I do not understand why Mr. Olsson would
>>>>>  find this disconcerting or difficult.
>>>>  I fully understand Mr. Olsson's complaint. In the Forum, we are indeed
>>>>  used to advise saving any picture to be embedded in AOO on the HD first
>>>>  and then to insert it with the relevant menu.
>>>>  However, this is not a very good user experience.
>>>  I agree.
>>>>  Note that I never filed a bug report for that. First because there
>>>>  already too many reports for too few coders and second because I often
>>>>  adjust the pic before actually inserting it in the document.
>>>
>>>  Despite we are a view Coders it helps if Tickets are updated, and maybe
>>>  it would make sense to link support emails / forum issues. It is quite
>>>  hard to prioritize Tickets. However a prioritization is not a ranking for
>>>  a fix ;)
>>>
>>>  Everything helps, even if there are only people giving feedback by
>>>  updating the bugs. Just be nice when you do. The Software Product is on
>>>  community support.
>>>
>>>
>>>  All the best
>>>
>>>  Peter
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Complaint: "buggy implementations"

W. Robert J. Funnell, Prof.
In reply to this post by Peter Kovacs-3
I read the bug report and it seems to be exclusively about images that
are copied and pasted? My understanding is that this thread applies
also to images that are inserted from files, and that the behaviour is
much less reproducible.

- Robert


On Sun, 25 Oct 2020, Peter Kovacs wrote:

> Hello all,
>
> Thanks for this discussion. Because it has been mentioned multiple times now,
> we have a bug report. There is no need to fill a new one.
>
> https://bz.apache.org/ooo/show_bug.cgi?id=115994
>
> A Bug report alone does not fix the Bug. However we have so many of them that
> this kind of discussion is really helpful to raise attention and to structure
> the Issues.
>
> I guess not all have the Issue on Mac? Maybe if we ciould collect the current
> information, I can update the ticket:
>
> I assume we have this now on windows, Linux, Mac? The report states only mac
> is affected.
>
> Can you confirm that this happens on 4.1.7?
>
> Am 25.10.20 um 11:29 schrieb Hagar Delest:
>>  Le 24/10/2020 à 21:38, William Lee Valentine a écrit :
>>>  This seems straightforward. I do not understand why Mr. Olsson would
>>>  find this disconcerting or difficult.
>>  I fully understand Mr. Olsson's complaint. In the Forum, we are indeed
>>  used to advise saving any picture to be embedded in AOO on the HD first
>>  and then to insert it with the relevant menu.
>>  However, this is not a very good user experience.
> I agree.
>>  Note that I never filed a bug report for that. First because there already
>>  too many reports for too few coders and second because I often adjust the
>>  pic before actually inserting it in the document.
>
> Despite we are a view Coders it helps if Tickets are updated, and maybe it
> would make sense to link support emails / forum issues. It is quite hard to
> prioritize Tickets. However a prioritization is not a ranking for a fix ;)
>
> Everything helps, even if there are only people giving feedback by updating
> the bugs. Just be nice when you do. The Software Product is on community
> support.
>
>
> All the best
>
> Peter
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]