Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 200450 - how to determine what fonts are in use for editor
how to determine what fonts are in use for editor
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: Painting & Printing
7.0
All All
: P3 (vote)
: TBD
Assigned To: Miloslav Metelka
issues@editor
:
Depends on:
Blocks: 179047
  Show dependency treegraph
 
Reported: 2011-07-27 22:28 UTC by err
Modified: 2011-08-03 18:03 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description err 2011-07-27 22:28:05 UTC
In some ways this is really a jVi enhancement. I'm just looking for info. Can assign to me after you consider.

I'd like to give a warning if not all fonts are the same size and monospace. Many jVi operations will misbehave in such a situation.

Can you suggest a way to check what fonts are in use for a particular editor? Is there a particular preference node that has all the info?
Comment 1 Vladimir Voskresensky 2011-07-28 13:13:48 UTC
err, have a look at implementation in options.editor/src/org/netbeans/modules/options/colors/SyntaxColoringPanel.java 
i.e. getFont can help you
Comment 2 err 2011-07-29 20:37:16 UTC
Vladimir, thanks. That helped a lot.
(jVi avoids getting into settings. I can spend a lot of time being confused when I go near EditorSettings; this time was no exception)

AFAICT, there's no "public" way to determine font for category; even with jVi as a friend of EditorSettingsStorage, though that helps. It looks like resolution and defaults are cooked into private methods of the dialog. Ending up with the private method "getDefaultFontSize" which has a hardcoded 12 in it.

I wonder if there are any public methods, even if they are not API, somewhere to do this. I didn't look through the new view hierarchy to see how it determines which font to use. Any pointers to that code would be appreciated.

Does
        EditorSettings.getDefault().getFontColorSettings(new String[] {""})
                                   .getAllFontColors(profile)
produce the categories for "All languages"?

I want to come up with a checking technique that does not have to run each time a JEditorPane gets focus. That means detecting when preferences are changed and that looks complicated for this. Any hints apreciated.


Backing up from getFont I came up with

        String profile = EditorSettings.getDefault().getCurrentKeyMapProfile();
        MimePath mimePath
                = MimePath.parse(NbEditorUtilities.getMimeType(jep));
        String[] mimeTypes = convert mimePath to array of strings
        FontColorSettingsFactory fcs
                = EditorSettings.getDefault().getFontColorSettings(mimeTypes);
        categories = fcs.getAllFontColors(profile);

Then going forward from getFont there are the private methods
        getValue()
        getDefault()
which resolve the attribute heirarchy recursively. And will finally resolve through
        ColorModel.ALL_LANGUAGES
but of course that class/field is inaccessible (though at least its public).

Its still confusing to me, for example for text/xhtml there is
    tag
        name:tag
        display name:Tag
        default:markup-element
but markup-element is nowhere to be found. But I know how to copy code, so I'm guessing it will work.
Comment 3 err 2011-07-29 20:47:47 UTC
> markup-element is nowhere to be found

Oh, it's in "All languages". Who would have guessed?
Comment 4 err 2011-07-31 23:07:10 UTC
Is it possible to determine font attributes using APIs? This is about the Family/Size/Bold/Itiac attributes.

Two things that need to be done
    1) resolve font attr through chain within language, then all language.
       Works for some settings using FontColorSettings.getTokenFontColors
       but not for the Default settings, even if manually change Default.
    2) generate a font from font attributes.
       unmodified Default in AllLang has no associated size or family.

Is it guaranteed that JTextComponent.getFont() is the "Default"?

Example attributes using FontColorSettings.getTokenFontColors

    With AllLang Default font size at 18

        mod-enum
            name:mod-enum
            display name:Enum Use
            default:identifier

    With AllLang Default font size at 18, and AllLang Identifier to 14
        mod-enum
            size:14
            bold:false
            italic:false
            name:mod-enum
            display name:Enum Use
            default:identifier

BTW, using Vladimir's hints. I think I have something that works, but I'd like to do it the "right" way. If that's not possible, then I'd like to do it the most maintainable way.
Comment 5 err 2011-07-31 23:09:02 UTC
and AFAICT the two example in comment 4 have fonts:
    java.awt.Font[family=Monospaced,name=Monospaced,style=plain,size=18]
    java.awt.Font[family=Monospaced,name=Monospaced,style=plain,size=14]
Comment 6 Miloslav Metelka 2011-08-01 15:04:21 UTC
Apologies, I was on vacation.
In theory the highlighting layers can use any sort of attributes from StyleConstants. Of course in practice they should only use the attributes defined in options. However each language may have specific attributes and the embeddings in general are defined by lexers so there's no direct way to determine all the possible fonts. So you could examine all the colorings of all languages in EditorSettings.getMimeTypes() (although it will lead to loading of all that coloring information into memory).
The new view hierarchy only waits of what the highlihgting layers will come with and if it would exceed current default line height it will recompute the line height and the rebuild paragraph views (the VH could work with non-uniform line height too but it's not expected in code editor to have non-uniform line height).
Comment 7 err 2011-08-02 01:25:06 UTC
(In reply to comment #6)
> on vacation.
I hope more than you were looking for

> ... could examine all the colorings of all languages ...

My approach is to check the attributes that are defined in the Options dialog. Only done for mime types that are in use. Recheck mimetypes as triggered by Result<FontColorSettings>. Put up a warning dialog if not all fixed and same WxH. This will catch the problems/complaints I've gotten.
(and after avoiding settings for years, I've dug in a little).

Is there some likely exposure I'm not considering? For example some highlights that are certainly going to be a different size?

Can you provide some insight into the two issues from comment 4? This is about the default font. In particular, 

    Is it guaranteed that JTextComponent.getFont() is the "Default"?

I'm currently replicating the behavior from Font&Color options dialog to pick pick the default values.

If not, do you know someone who can?
Comment 8 Miloslav Metelka 2011-08-02 09:18:13 UTC
> Is it guaranteed that JTextComponent.getFont() is the "Default"?

The default font is determined from FontColorSettings.getFontColors(FontColorNames.DEFAULT_COLORING);

DocumentView.updateDefaultFontAndColors() in new view hierarchy ensures propagation into JTC.getFont().

The resulting font for a particular text is the default font possibly modified by the extra attributes from AS provided by highlighting layers. When multiple layers affect the same text the resulting AS is a merge according to HL's z-order. So for the same piece of text one HL could e.g. only change the font's height and the other one could e.g. make the text to be italic.

AFAIK there is currently no HL that would change the font's height or family to anything not present in the options.
Comment 9 err 2011-08-02 20:27:02 UTC
(In reply to comment #8)

Thanks for the clarifications. (and there's a bug, see the last half)

> The default font is determined from
> FontColorSettings.getFontColors(FontColorNames.DEFAULT_COLORING);

I took another look at how this gets satisfied. Like how it flips to doing getTokenFontColors and finally ends up at getHardcodedDefaultColoring().

> DocumentView.updateDefaultFontAndColors() in new view hierarchy ensures
> propagation into JTC.getFont().

Took another look here. I see more clearly now how it starts with JTC.getFont() and uses ViewUtils.getFont(). (and that "customFont" flag is something I'm content to ignore and forget about (at least for now))

> The resulting font ... is a merge ... one ... height and the other ... italic.

Ah, I hadn't quite realized that.

=== BUG ===

There's a bug concerning the default font size and the Options Dialog; in
o.n.m.editor.settings.storage.fontscolors.CompositeFCS.getHardcodedDefaultColoring

    defaultFontSize < 13 ? 13 : defaultFontSize

and in o.n.m.options.colors.SyntaxColoringPanel.getDefaultFontSize 

    if (s < 12) s = 12;

If I bring up the Fonts&Colors dialog, AllLanguages, press on Font: xxxx ..., and then click OK. The font size changes. The display says Mono-12 for both settings. There are other anomalies because of this discrepency.

Should this issue be converted to a bug about the real default size and the OptionsDialog default size? Not sure it it is againt Options-12 or Settings-13. I guess options should be fixed since the other change would be very visible.
Comment 10 err 2011-08-03 18:03:18 UTC
Closing this. Filed Bug 200650 about the editor/options font size difference.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo