Apache OpenOffice (AOO) Bugzilla – Issue 19251
FontWork: fonts and/or shadows not always rendered correctly
Last modified: 2003-12-09 10:35:54 UTC
to reproduce: 1. Open a fresh writer document 2. Insert a new Draw-Object 3. Open a text-frame, enter text "TEXT", format with an arbitraey font (either T1 oder TT) 4. activate FontWork 5. Play around with shadows aligning to circle bows etc. (esp. switch between upright and skew shadow).
Created attachment 9085 [details] screenshot
Do you mean that on your screenshot no shadow at all is visible? Or what else means "not always rendered correctly"? Thanks in advance.
"not always rendered correctly" means that in many cases you activate a shadow or switch between the two types of shadows either the text or the shadow or both are not rendered "as expected". What you might see in the attached image is that the shadow has been rendered with a smaller font size. But there are -- if only you "play around" long enough -- even cases where both the original text and the shadow are invisible. "To play around" means click moderately fast on the buttons and observe what happens.
Created attachment 9094 [details] magnification
I found that if you set the shadow to slant and type in 39 degrees and switch forth and back between slant and vertical the slant count changes to 30, 180 and than 0. Upper arc has to be selected. Set to new.
Reassigned to Armin. Please have a look.
AW: Double to #105084#.
I cannot find #105084#. Do you really mean #105084#.?
That is internal numbering user cannot see that, only developer can see it :)
Adding text from internal bug 105084: According to 104626 there is no refresh for the FontWork Flyer when using extras/options/... the units of a application are changed. AW: First thing is to investigate how the common mechanism works... AW: Discussed with CL. ATM this extras/options change leads to changing options globally when no app of that type was open, locally for the one app when it is open. The notify uses ??Module::ApplyItemSet(...). There is NO planned mechanism for FlyFrames ATM at all, this was simply forgotten up to now. All FlyFrames would have to be extended to support unit changes on the fly and a concept how to trigger that change would need to be done. AW: CL and i agree that this fix is too complex and not possible to be done for 6.1 beta. AW->MSC: Pease to 6.y and back to me. MSC->AW: Set to 6.y and back to you. AW: Thanks.
Setting 105084 as duplicate to this one and closing it.
Reassigned to Armin.
AW: OK, closing other bug and using his one. Accepting.
AW: This is an UI bug in a dialog, thus maybe it's better handled by the UI team?
In different places the items and values for distances and angle/percentage were handled identically. That did not work since Get/SetMetricValue was used in that dialog instead of Get/SetValue.
AW->WG: please take a look.
Set to fixed.
Verified in CWS.
Tested in master. Issue closed.