They are anti-aliasing lines/vector graphics now, too, right? Not that I feel the need to vote for that, but that would explain the need to change so many lines (that, and "Firefox engineering syndrome"--where doing everything you possibly can yourself, avoiding the OS's pre-existing functions at all costs, is seen as the highest goal)
I took a look at the OpenOffice.org 3.1.1 Mac OS X code and it appears that they are using native anti-aliased line and shape drawing. So, I suspect that the huge number of lines changes was necessary to remove all of the "XOR drawing" calls from the OpenOffice.org application code and replace those XOR drawing calls with "clear background and repaint all lines and shapes" drawing calls.
We have always had the ability to draw anti-aliased lines and shapes. The problem has been that when the OpenOffice.org code tries to erase a drawn line or shape by drawing the same line or shape a second time with the drawing surface set to XOR mode, XOR the semi-transparent pixels that Mac OS X draws to make anti-aliased lines and shapes does not work and so a faint outline is left.
Because of OpenOffice.org's extensive use of XOR drawing, we turn off anti-aliased line and shape drawing in all but a few cases. I assume that OpenOffice.org ran into the faint outline problem and had to go through every piece of code that uses XOR drawing and rewrite it to not use XOR drawing.
That isn't bad in and of itself. The risk is that, in our experience, any massive changes to the OpenOffice.org code seems to introduce lots of new crashing bugs so we tend to wait a few releases after such massive changes for OpenOffice.org to find and fix any crashing bugs before we upgrade to their code.
Well, EAP isn't even finished yet, so it has some time to cook, at least. By the time you really get ready to do 3.0.2, the boys in Hamburg will have OpenOffice.org 3.2 out the door (it is in feature freeze now).
Best wishes,
Oscar _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Well, EAP isn't even finished yet, so it has some time to cook, at least. By the time you really get ready to do 3.0.2, the boys in Hamburg will have OpenOffice.org 3.2 out the door (it is in feature freeze now).
Now that the support load is at a manageable level, I think it might be reasonable to upgrade NeoOffice to the OpenOffice.org 3.2.1 code when it comes out. I never trust a X.X.0 release of OpenOffice.org as they seem to get rushed out the day before OOoCon each year and, as a result, they inevitably push out an X.X.1 bug fix release a few months afterwards.
Assuming donations stay at a reasonable level and OpenOffice.org releases 3.2.1 in the first few months of 2010, I can work towards a NeoOffice 3.2.1 Early Access Program in Spring of 2010.
In the meantime, while we are stuck using the OpenOffice.org 3.0.1 code I have made use of the development time that our reduced support load has provided and I have implemented real native highlighting in Calc. While I am not sure of exact dates yet, I am thinking that implementing real native highlighting in Writer, Calc, and Impress could be done before the end of 2009 and we could have a short NeoOffice 3.0.2 Early Access Program for this feature in January or so of 2010.
There have been several few posts recently about native highlighting on this site and since it is rare for more than one or two donors to request a feature, I spent a few days trying to see if I could replace OpenOffice.org difficult to see native highlighting with the same native highlighting style that TextEdit and Safari uses.
Below are two screen snapshots. The first is the current faded native highlighting style that OpenOffice.org 3.1.1 uses. The second is my real native highlighting style that I implemented in NeoOffice 3.0.1 Calc. Note that in the NeoOffice screen snapshot that both the highlight color and the highlight text is full color and is not faded like in OpenOffice.org.
Is anyone interested in seeing an Early Access Program release with real native highlighting at the beginning of 2010?
Joined: Jun 11, 2006 Posts: 481 Location: Great Britain
Posted: Wed Nov 04, 2009 12:38 am Post subject:
pluby wrote:
Is anyone interested in seeing an Early Access Program release with real native highlighting at the beginning of 2010?
I like it! But do you think native highlighting justifies an EAP? I know you need to keep the motivation high for donations, however if you squeeze the EAP too hard it will lose its "event" status.
One feature I have wondered about for some time is the issue of subpixel kerning. Over the years, Patrick has repeatedly mentioned that it is a prime reason why OOo and NeoOffice cannot be used for proper DTP.
I am wondering if this is something the user would have to input something for, or whether the text drawing routines could be adapted to have that extra bit of fidelity..
I might be wildly off the mark here (and it is not backporting), but I thought I would throw it up as a possibility.
Best wishes,
Oscar _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Joined: Jul 05, 2005 Posts: 685 Location: North West England
Posted: Wed Nov 04, 2009 8:23 am Post subject:
djpimley wrote:
I like it! But do you think native highlighting justifies an EAP? I know you need to keep the motivation high for donations, however if you squeeze the EAP too hard it will lose its "event" status.
Unless, of course, there is a risk of native highlighting throwing up a significant support load which would be eased by the EAP.
TBH, provided it is clear what the new release includes, then people always have the option of not going for EAP and waiting for general release - without feeling that they are being unduly pressured.
Maybe the danger of 'squeezing' the EAP can be avoided by suitable presentation.
I like the new native highlighting too - especially the way it really is 'in' the cells, and not over the top of the document. _________________ MacBook Pro
13-inch, Mid 2012
Processor 2.5 GHz Intel Core i5
Memory 4 GB 1600 MHz DDR3
Graphics Intel HD Graphics 4000 512 MB
OS X 10.9.3 (13D65)
I like it! But do you think native highlighting justifies an EAP? I know you need to keep the motivation high for donations, however if you squeeze the EAP too hard it will lose its "event" status.
You are wrongly assuming that the Early Access Program is for fundraising. Your assumption is incorrect as our revenues are usually lower during an EAP than just after an official release.
The primary of purpose of an EAP is to test the new features. What justifies an EAP is the fact that we are modifying the OpenOffice.org features and those feature changes need to be tested.
NeoOffice has always been tested by users as we don't have a professional test staff to think up all of the potential use cases that our code changes might affect. As a result, we have an EAP to keep the number of users restricted to the large donors and focus all of our time during EAP on fixing the bugs found by EAP members.
Only when it is stable for EAP members do we push it out to the masses.
Edit: I realized that part of your assumption may have been that you would need to have donated after the end of the NeoOffice 3.0.1 Early Access Program to be a member in the next one. That will not be the case and, instead, we would use the same policy as we did for the NeoOffice 3.0.1 Early Access release: any donations made within the last year before the start of the Early Access Program will count.
Patrick
Last edited by pluby on Wed Nov 04, 2009 12:04 pm; edited 1 time in total
One feature I have wondered about for some time is the issue of subpixel kerning. Over the years, Patrick has repeatedly mentioned that it is a prime reason why OOo and NeoOffice cannot be used for proper DTP.
Sorry, this is not feasible and likely will never be. The OpenOffice.org code uses integers for coordinates throughout a significant percentage of its several thousand source code files so there is no central place to change to floating point coordinates.
Even worse, the OpenOffice.org application code in some places (like Writer) are constantly overriding the native text layout coordinates that our code generates. As a result, rendering text in floating point coordinates is probably a bigger project than OpenOffice.org 3.1's antialiased line and shape drawing.
That said, there is a hacky method that OpenOffice.org supposed allows for some subpixel positioning in some cases. I remember turning it on when we first upgraded NeoOffice to the OpenOffice.org 2.0 code but it didn't seem to have any effect other than to increase CPU usage.
I can try turning their hacky method back on in an EAP and we can see if anything noticeable kerning changes occur.
No need to try that on my account. I doubt that I would have much use for it.
I just remember you mentioned it several times and thought it might be of interest to a few people, or at least a nice headline feature.
But if it is infeasible, don't do it
I don't see too much risk in trying the hacky method. That method would only require a couple days of work to enable again and we can quickly see if the choppy kerning like in the attached snapshot is better or if the OpenOffice.org Writer code overrides the hacky method.
If it has some improvement (I doubt it will work in all cases but some improvement is probably better than none), Fran and I can see if performance degrades at all using the performance tests in this NeoWiki article. If performance does not degrade, then we can include the hacky method in the next EAP so that it gets tested by a few thousand people.
BTW, I edited my previous post regarding why there needs to be an EAP for these changes. I realized that there may have been an assumption that you would need to have donated after the end of the NeoOffice 3.0.1 Early Access Program to be a member in the next one. That will not be the case and, instead, we would use the same policy as we did for the NeoOffice 3.0.1 Early Access release: any donations made within the last year before the start of the Early Access Program will count.
Holy cow! Highlighting in Calc both using my selected highlight color and actually visible!
On the flip side, what about the administrative overhead of the EAP? To me, on the outside looking in, it seems like a lot of administrative work for "just one" feature (and one that only works in one module).
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Joined: Jun 11, 2006 Posts: 481 Location: Great Britain
Posted: Wed Nov 04, 2009 12:25 pm Post subject:
pluby wrote:
You are wrongly assuming that the Early Access Program is for fundraising.
Ah, I see your point of view. Because you've allowed donors to request features and because of the general clamour there always seems to be for the most recent OOo code, I thought of EAP as kind of reward scheme. I didn't think of its more useful role as a beta programme by another name. Without giving it much thought, I did make that assumption about donations as well. As I'm wrong on both counts, please go for it.
Smokey: Patrick wrote in his post that he would try to enable native highlighting for all modules, not just Calc.
Smokey: Patrick wrote in his post that he would try to enable native highlighting for all modules, not just Calc.
Oh, indeed; I missed that part while I was scrolling the page left and right, and instead only saw the part where he said he had implemented it in Calc
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Oh, indeed; I missed that part while I was scrolling the page left and right, and instead only saw the part where he said he had implemented it in Calc
Rewriting the Calc code to do real native highlighting was the proof of concept. The key that I found was that I have to remove OOo's "draw a semi-transparent color on top of content" code and use a completing different approach of forcing a complete repaint the highlighted and recently unhighlighted areas but during such a repaint, draw the native highlight color in the selected subareas immediately after the OOo code draws the document's regular background color but before any of the lines, text, images, etc. are repainted.
Now that I know how to implement this, I feel reasonably confident that I can implement the same process in the Writer, Impress, etc. modules as my approach does not depend on any of OOo 3.1's faded highlighting code.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
