Comments on pdf file size in 4.4 alpha; and a new bug?

users
#1

Hi:

I'm using 64 bit Ubuntu 14.04 with a parallel installation of LibreOffice
Version: 4.4.0.0.alpha2+
Build ID: d273a60bfdbf9bb7623bed38667ec0647753157c - TinderBox:
Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-11-20_03:05:21 -
Locale: en_US

I installed this in parallel with my 4.3 installation mostly because of
having been burned so many times in the past by new bugs, but the recent
commentary on what are apparently "fixes" to the pdf export function
compelled me to try this alpha just to see; I often need to transfer pdfs of
documents and reducing sizes is important. (I often wondered why the files
were so huge, but never thought to question the sizes)

I can confirm that the 4.4 alpha does indeed produce significantly smaller
pdf sizes with (as far as I can tell) the same quality as earlier versions
have produced.

BUT - as usual, there is a huge caveat ... When I first tested this, I
thought that perhaps the smaller size resulted from the fact that Writer
just left out quite a few of my graphics, which didn't appear in the pdf. A
little further exploration, however, showed that they were not visible in
the document either, although were in fact still there - just hidden under
totally (and newly) opaque frames. Thinking that maybe this was a result of
some sloppy formatting on my part, I changed a few of the frames to 100%
transparency - permitting the graphic, which was already marked as "on top"
to be displayed in Writer and saved the file (yes - under a new name - I
have used betas before). I generated a new pdf and - viola - the graphics
whose frames I had "fixed" showed up in the pdf.

However, when reloading the document, all of the frames were again totally
opaque. To cut this short, I checked and changed the style for frame
contents to 100% transparency, but that did made no difference in the
results.

So, as they say (or paraphrase), the developers giveth and the developers
taketh away.

Which brings up an interesting and related question ... On the "most
annoying bugs for 4.3 section (under DEV), there are several comments where
a moderator (?) chastised several folks for posting about 4.2 bugs, although
the submitters all seemed to be reporting 4.2 bugs that were still present
(and annoying at least to them) in 4.3. This is confusing to me, and I can't
quite figure out what the development process is. I poked around, but all
the discussions I've run across are not at all clear. Is there a description
somewhere about how all this works?

My questions - in no particular order - are:

Why would a bug that is annoying in one version (e.g. 4.2 above) not be
given some sort of priority or at least inclusion in a later version's (e.g.
4.3) list?

Is there any form of regression testing involved in assessing bug fixes?

Are these "versions" treated as separate "forks" and handled by separate
developers?

How do "fixes" in one version make their way into other versions? And how
are dependent "fixes" tracked to insure that something that fixes one branch
doesn't improve but still break a different branch?

I guess my overall observation based on using LO since somewhere in the
early 3.x versions is that every time some bug that annoys me (or precludes
me from being able to use earlier documents without having to tweak the heck
out of them) is "cured," some other feature that previously worked just fine
becomes broken.

I'm not trying to be a wet dish rag here - and I certainly appreciate the
level of work involved, but I can't help but suspect that there is some
issue with the PROCESS of development and testing when these sorts of things
continue to happen. That's why I'd like to understand more about the whole
process.

Thanks for listening ...

#2

Hi :slight_smile:
I think there might be a few different things going on there.

Firstly i have no idea how the devs think or work. Clearly they think very
differently from most users. What seems obvious and makes sense to us is
clearly 'wrong'.

To me, i'd agree with you, that if it's annoying in one branch and still
exists in the next then it's likely to be annoying in that branch too.
Clearly the devs don't think like that at all. Trying to argue the point
is likely to get you in trouble here. It's one of the reasons i am under
moderation or even chucked off mailing lists here.

What normal users, like us, tend to think of as bugs or stability issues is
often technically called something else. So far i can only think of 5 but
i'm sure there are more. The most frequent type of 'bug' reported by
normal users is often really a "broken feature". That is very different
from what the devs would call a "bug", as far as i can make out. It's
certainly NOT a stability issue. Very few bugs are anything to do with
stability. So when something is broken we have to try to figure out
whether the devs would call it;
1. something that behaves differently from certain other programs (but the
LO way might well be better)
2. something behaving weirdly
3. something that changed behaviour
4. a broken feature/thing
5. a bug
or
6. a bug causing a stability issue

Sometimes there is no practical difference between 1 and 2 or it might be
just a difference of opinion, ie immensely long and argumentative threads.

We rarely discuss items such as 3 because we mostly just adapt or new
people are unaware it used to be any different. Sometimes it's intriguing
or interesting. Occasionally a change in behaviour only happens to 1
person and indicates weird things going wrong which all gets fixed by
renaming the User Profile. More usually it's a positive thing that a few
people find annoying but most people either don't care or find it an
improvement. (like when some obscure graphs got smoothed out in a better
way that gave better results and looked nicer (i think in 3.4.0)).

Mostly what we get here is 4. A long running feature/thing suddenly stops
working in a new branch. We try renaming the User Profile jic it's that
(despite it seeming really unlikely) and post a bug-report only to find we
gets loads of aggro from devs telling us to fix it ourselves or that
individuals should pay to get it fixed. Sometimes it gets all bitter and
unnecessary blaming individuals who are all trying to do a good job but
that sometimes leads to unexpected complications "out in the wild". Maybe
we should post these as "feature request"s and pretend that it's new in
order to avoid hurting anyone's feelings?

Very occasionally we get a real 5 but it's actually quite unusual, and
quite difficult to spot since everything else is also called by the same
name by most normal users.

We seem to get a real 6 much more often than a real 5 but then it turns out
to be a Java or other 3rd party issue. We still quite often help fix it.
I think one time it turned out to be a wobbly graphics card and another
time a defective fan but usually it's just a case or trying a different
version of either Java or LibreOffice.

Unfortunately pretty much all those things can only be reported by posting
a bug-report. Feature requests use the bug-reporting systems. In that
system one of the drop-downs has an option labelled "feature request". We
can often help with most of them, especially 1 and 2 and even 6 but the
only route to escalate problems is to post a bug-report. I tried liaising
with other mailing lists to see if they could help with other issues but it
earned me a bad reputation so i wouldn't advise it!

Now is the ideal time to take the 4.4.0 for a test-drive. It's the number
1 time that the most devs are looking for problems in the new branch. It's
also THE best time to get stuff fixed. New stuff is still fresh in
people's minds so they might instinctively put their finger right on the
source of the problem even if the code seems fine to everyone else.

So, please do take the 4.4.0 for a test-drive now and post bug-reports
about whatever you find (maybe ask here first maybe) even if it doesn't
really seem to be a bug and seems to fall into one of the other categories
i made-up on the spot there or some other not-quite-a-bug-really type
category.

This is also a good time to join in with the QA team to help do routine
office type work to help make sure the different bugs are all neatly filed
and stuff so that the devs can focus on the coding rather than getting
bogged won with filing and routine stuff.
Regards from
Tom :slight_smile:

#3

@Tom, *,

Nicely put. Thanks!

@CVAlkan, *,

The transparency issues with PDF export in the 4.3 branch, is a reported in
bugzilla,
fdo#84294 <https://bugs.freedesktop.org/show_bug.cgi?id=84294>
fdo#83963 <https://bugs.freedesktop.org/show_bug.cgi?id=83963>

I believe frame transparency is fixed with current 4.4.0.0 builds (rc2,
beta1) and in the dailys of master, but transparent text fields is not yet
correct. Testing appreciated.

Stuart

-=ref=-
fdo#80468 and fdo#81223

#4

Oops, correct that last... s/rc2/alpha2/ we're not that far along with the
4.4 branch.

#5

very well said.
+1
regards,
som

#6

Hi :slight_smile:
Thanks Stuart and Dr Som too :slight_smile: There were a few tpyos in there so i'm
glad it makes enough sense!

I just heard from another mailing list that the QA team are right in the
middle of one of their special bug-hunting sessions. So it's an especially
good time to join in there. A lot of new people join in for those so even
just lurking on their mailing list can be a good way of learning how to
join in, if you are a bit shy of daring to ask :wink: Also it's a good time
to "ask stupid questions" aimed at trying to figure out how to join in
because other people lurking there will probably be relieved you asked and
it gives some other new people a chance to help (ie maybe good for
morale).

At the very least it's a good time for the rest of us to at least
test-drive the new branch
Regards from
Tom :slight_smile:

#7

Tom,

I think this is really well explained.

I've been professionally involved in defect reporting for years, and the problems seem to be the same in all organisations.

Problems in defect reporting:
1- Qualification of type (A bug is unexpected behaviour which does not comply to the requirements; An enhancement request is new development which changes both requirements and code)
2- Severity (How serious is the bug/enhancement request from users perspective)
3- Priority (What is the priority with respect to other bug/enhancement reports)

Neither of these I see in out bugzilla defect reporting...

There should be a moderator (not a developer) to map out the priority. One can set out rather strict rules for this, think about amount of complaints for the same, file corruption, system crash, etc.
If we would go along these lines we might get away with the tension between (expert-) users and developers.

But again, good effort here to get things ironed out,
Thanks Tom,

Rob.

#8

@Rob, *,

Rob Jasper wrote

I think this is really well explained.

I've been professionally involved in defect reporting for years, and the
problems seem to be the same in all organisations.

Problems in defect reporting:
1- Qualification of type (A bug is unexpected behaviour which does not
comply to the requirements; An enhancement request is new development
which changes both requirements and code)
2- Severity (How serious is the bug/enhancement request from users
perspective)
3- Priority (What is the priority with respect to other bug/enhancement
reports)

Neither of these I see in out bugzilla defect reporting...

There should be a moderator (not a developer) to map out the priority. One
can set out rather strict rules for this, think about amount of complaints
for the same, file corruption, system crash, etc.
If we would go along these lines we might get away with the tension
between (expert-) users and developers.

But again, good effort here to get things ironed out,
Thanks Tom,

Rob.

Actually, the LibreOffice project is rather well organized in this
regard--please review the QA Wiki here:
https://wiki.documentfoundation.org/QA

QA is a distinct entity to Development--and while there is certainly some
cross over, the developers are not moderators of the process. That falls to
the Engineering Steering Committee with input from the entire community--QA
team, UX and Design team, Documentation team,
Localization/Internationalization team, Marketing team and the occasional
needs of TDF board.

So, always room to participate. Please start as Tom suggested by loading a
current build of the 4.4.0 build, or a daily Tinderbox of master and test
there.

We can always use additional help with the QA process--get a login on our
FDO hosted Bugzilla instance <https://bugs.freedesktop.org/> and dive in,
plenty of triage work to go around.

Regards,

Stuart

#9

Unexpected behaviour is a bug when it was unexpected by the programmer.
In the eyes of a user, some program may do weird and unexpected things
but if it does the exact weird things that it has been programmed for
then there is no bug.

#10

Tell that to my clients :slight_smile:

I can assure you that if a program, while acting exactly as I intended
it to when I coded it, does not do what the spec requires it to, then
the client calls it a bug, and expects me to fix it. And rightly so.

Of course, with LO the situation is a little different, due to the lack
of a formal client and thus a formal requirements document. If a
feature doesn't work as expected by the users, but does work as
expected by the developer who implemented it, then perhaps calling it a
bug is incorrect. Instead it is merely a feature that was implemented
in a manner that proved not to be useful. It's also not an enhancement
request, really. It all comes down to what is taken as the requirement
of the feature. If the feature started life as an enhancement request,
then that, if it is complete in this regard, will be the requirement.

If I, as a user, were logging a ticket for a feature that didn't work
the way I expected, and there was no original enhancement request or
clear feature specification, my choice of ticket type would depend on my
understanding of the feature. If I understood where the developer was
coming from, but had a different opinion of how the feature should
work, or desired an alternative implementation alongside the existing
one, I would log the ticket as an enhancement request. But if I felt
the feature should work differently, and working the way the developer
had coded it was incorrect in my opinion, then I would log it as a bug.
It would be up to those in charge of such matters to determine which
way they felt was correct, and to either fix the bug, or close the
ticket.

#11

Hi :slight_smile:
I was trying to postulate a possible reason why we sometimes get such
extremely hostile reactions, or at best total apathy from devs sometimes.
It's more about perception than reality.

Most of what normal users would call a bug is something that the devs would
call something else. In order to get their support rather than their
apathy or rejection then we need to start figuring out what words they
would use and how they would expect it to be handled. I think that a lot
of times we should be suggesting people post what they see as bugs as
"feature requests", including when a feature that has been running
successfully for years gets broken!

To me that is upside-down. It should be the techie people that make things
easier for the normal end-users rather than the other way around. However
we hit a brick-wall that way

Regards from
Tom :slight_smile: