TODO: - Add a color picker. - If it is a color with name: - It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" " - If not: - It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" "+ colorvalue.getRed() +" "+ colorvalue.getGreen() +" "+ colorvalue.getBlue() +" " - Note that those will habe eType with value TRGB or TRGBA.
@Dante, replacing [1] the prior fixed SM color scheme (black, white, cyan, magenta, red, blue, green, or yellow) with selection of the X11, SVG 1.0, CSS2/CSS3 derived colors might not be the best choice. It will result in OLE formulas in line on canvas with color theme that does not match the default RYB color names we implemented for Standard colors (bug 114719). Working with the OLE on canvas, users would have to switch the color picker over to the 'html' theme to be able to match the document text to the formulas. Naming is not critical--as we pass colors out without the color name, but expect these new expanded _SM_ static colors (name & RGB hex) *should* match value of the 'html' color palette (bug 104048). I did not check. Otherwise, I had kind of hoped to find a way to have our full color picker dialog available to SM to pick colors from *any* palette -- thus far this only expanded the formula 'color' attributes to a subset of the normative [2] standard. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/105892 [2] https://en.wikipedia.org/wiki/Web_colors
(In reply to V Stuart Foote from comment #1) > @Dante, replacing [1] the prior fixed SM color scheme (black, white, cyan, > magenta, red, blue, green, or yellow) with selection of the X11, SVG 1.0, > CSS2/CSS3 derived colors might not be the best choice. > > It will result in OLE formulas in line on canvas with color theme that does > not match the default RGB color names we implemented for Standard colors > (bug 114719). > > Working with the OLE on canvas, users would have to switch the color picker > over to the 'html' theme to be able to match the document text to the > formulas. > > Naming is not critical--as we pass colors out without the color name, but > expect these new expanded _SM_ static colors (name & RGB hex) *should* match > value of the 'html' color palette (bug 104048). I did not check. > > Otherwise, I had kind of hoped to find a way to have our full color picker > dialog available to SM to pick colors from *any* palette -- thus far this > only expanded the formula 'color' attributes to a subset of the normative > [2] standard. > > > =-ref-= > [1] https://gerrit.libreoffice.org/c/core/+/105892 > [2] https://en.wikipedia.org/wiki/Web_colors I'm not really sure to understand. The palettes we dispose on starmath are HTML ( made from MDN documentation ), even if not visible on UI, and dvipsnames is on work ( color dvip colorname, follow overleaf documentation ). On core/starmath/starmathdatabase there are also functions that allow to identify a color name. That bug seems to be closed. And the colors definitions match the documentation ones. It is possible to add X11 colors. Something like color x colorname or even colorx colorname. Have to check if there's a list somewhere or if I have to define them _SM_. And also other palettes can be added. I added as naturals the HTML colors because the previous colors where already following the HTML standard and not X11. Changing they're definitions to match X11 would break old documents. For now the color picker can only have the HTML palette. But I can keep adding colors as long as there is someone willing to do the UI work. If interested I can explain you how does work starmath color identifier to pass them.
@Dante, * Sorry, but issue is that using "named colors" for StarMath/MathML formula parsing is only *valid* for a limited set of colors [1]. Loading a bunch of non-normative named colors disrupts interoperability and makes it harder to integrate SM OLE with other LibreOffice modules. And in general having a lot of named colors preloaded is poor UX as they are not exposed via GUI--the core of this issue. I'd suggest instead that using our SVX color picker with our supported color theme(s), as found in core/extras/source/palettes, to apply #RGB or #RRGGBB colors to the formula bar seems preferable. Otherwise for filter import of MathML we should not be expanding named colors beyond the MathML norms. Just the set of HTML4 colors, #RGB/#RRGGBB with color fallback for any unrecognized named colors arriving from ill-formed MathML. =-ref-= [1] This is the W3C spec for MathML, para 2.1.5.3 color, listing only the HTML4 colors ("aqua", "black", "blue", "fuchsia", "gray", "green", "lime", "maroon", "navy", "olive", "purple", "red", "silver", "teal", "white", and "yellow") as valid for use in MathML: https://www.w3.org/TR/MathML/chapter2.html#type.html-color These were the commits changing color handling in the sm module. https://gerrit.libreoffice.org/c/core/+/105526 https://gerrit.libreoffice.org/c/core/+/105892
(In reply to V Stuart Foote from comment #3) > @Dante, * > > Sorry, but issue is that using "named colors" for StarMath/MathML formula > parsing is only *valid* for a limited set of colors [1]. Loading a bunch of > non-normative named colors disrupts interoperability and makes it harder to > integrate SM OLE with other LibreOffice modules. > > And in general having a lot of named colors preloaded is poor UX as they are > not exposed via GUI--the core of this issue. > > I'd suggest instead that using our SVX color picker with our supported color > theme(s), as found in core/extras/source/palettes, to apply #RGB or #RRGGBB > colors to the formula bar seems preferable. > > Otherwise for filter import of MathML we should not be expanding named > colors beyond the MathML norms. Just the set of HTML4 colors, #RGB/#RRGGBB > with color fallback for any unrecognized named colors arriving from > ill-formed MathML. > > > =-ref-= > [1] This is the W3C spec for MathML, para 2.1.5.3 color, listing only the > HTML4 colors ("aqua", "black", "blue", "fuchsia", "gray", "green", "lime", > "maroon", "navy", "olive", "purple", "red", "silver", "teal", "white", and > "yellow") as valid for use in MathML: > https://www.w3.org/TR/MathML/chapter2.html#type.html-color > > These were the commits changing color handling in the sm module. > > https://gerrit.libreoffice.org/c/core/+/105526 > > https://gerrit.libreoffice.org/c/core/+/105892 Here I have to apologize. I used the MDN documentation for this and added the HTML full set because it said "The text color. You can use #rgb, #rrggbb and HTML color names.". Should have looked for better. That also means I have introduced a bug in the mathml export / import system, handling all HTML 5. For some reason firefox does seem to support all html colors, so as you say, will have to deal with ill formated colors. However the export needs correction. I guess only people who knows CSS and latex would be able to exploit this new function. Actual starmath can load from mathml #RRGGBB, but not #RGB. It suports on parser color rgb r g b , color hex num16 and ~ color #RRGGBB ( it is interpreted as an exadecimal number even if missing left zeros, but most compact form, color#RRGGBB would be understood, looking like a single keyword). Dvipsnames are been implemented as a future compatibility layer for importing / exporting latex. TODO: - Remove from mathml export Css2 and later colors. - Add support for #RGB colors. - Add a dvipsnames palettes. I'll do it this weekend (excepting third point which requires more time). Are those the changes I think you want to do? Is it actually possible to implement the color picker?
(In reply to dante19031999 from comment #4) > TODO: > - Remove from mathml export Css2 and later colors. > - Add support for #RGB colors. These of course are still RGB colors, but they are a short hand representing a double Hex value 0-F. That is, #123 would be shorthand for #112233, or #0F0 would be #00FF00, etc. > - Add a dvipsnames palettes. > I'll do it this weekend (excepting third point which requires more time). > > Are those the changes I think you want to do? > Is it actually possible to implement the color picker? I expect it is possible, it would need to be integrated into the Elements dock. The SVX Picker GUI could be embedded onto the Element pane (might be a lot of work), or simpler just popup when either the hex or the rgb attribute button is picked. The SVX color picker would allow selection of color from any .SOC palette, or its Custom Color dialog. Either case, would use the HEX color string from the picker as the #RRGGBB hex or the doubled #RGB being inserted/modified in the Formula Editor panel as rendered in the Preview Window. Would not be capable of directly applying a color to a rendered node--just applied via the 'color' [hex|rgb] command. The HTML 4.0 "named colors" would remain in their block on the Attributes panel of the Elements Dock, could reposition the "hex" and "rgb" to another panel, or just add a separator.
(In reply to V Stuart Foote from comment #5) > > - Add support for #RGB colors. > > These of course are still RGB colors, but they are a short hand representing > a double Hex value 0-F. That is, #123 would be shorthand for #112233, or > #0F0 would be #00FF00, etc. > And, seems the current 7.0 "rgb" implementation is not the doubled HEX, but is instead the decimal representation of the Hex value 0-255--I was wondering about that. Seems more useful than the doubled shorthand of the MathML standard. For "rgb" is color rgb 255 0 0 Green is color rgb 0 255 0 Blue is color 0 0 255
(In reply to V Stuart Foote from comment #6) > (In reply to V Stuart Foote from comment #5) > > > > - Add support for #RGB colors. > > > > These of course are still RGB colors, but they are a short hand representing > > a double Hex value 0-F. That is, #123 would be shorthand for #112233, or > > #0F0 would be #00FF00, etc. > > > > And, seems the current 7.0 "rgb" implementation is not the doubled HEX, but > is instead the decimal representation of the Hex value 0-255--I was > wondering about that. Seems more useful than the doubled shorthand of the > MathML standard. > > For "rgb" is color rgb 255 0 0 > Green is color rgb 0 255 0 > Blue is color 0 0 255 Here added #RGB (from mathml): https://gerrit.libreoffice.org/c/core/+/106286/3 With some basements over here: https://gerrit.libreoffice.org/c/core/+/106224/3 Corrected mathmlexport with w3 standards: https://gerrit.libreoffice.org/c/core/+/106286/3 For 7.0 is is as you say. For 7.1 you will have (already implemented): Named: color colorname ; Blue is color blue Decimal: color rgb r g b ; Blue is color 0 0 255 Hexadecimal: color hex colornum ; Blue is color hex FF or color hex 0000FF Hexadecimal: color # colornum ; Blue is color # FF or color # 0000FF Can also be written color#0000FF like a single keyword. Can load from mathml: colorname; #RRGGBB; #RGB; Can write on mathml: colorname; #RRGGBB; It's because of this changes I thought the color picker could be interesting.
Created attachment 169283 [details] Math Highlighting Comments Dante, I built your patch and I have a few suggestions to make (see the attached ODG file "Math Highlighting Comments"). 1) Keywords could be marked as bold to make it clear for the user that a format command is being used. This is important because sometimes the user thinks the word will be treated as text when it is in fact a command. For a complete list of commands, refer to the Math Guide (https://wiki.documentfoundation.org/images/a/a2/MG70-MathGuide.pdf). 2) The double quotes for strings could be formatted together with the string itself (see the example in the attached file) The following two comments are not part of this patch, but could be considered in a future enhancement you'll submit. 3) I liked the color combination you chose. However, in the future there could be options for Math under Tools > LibreOffice > Application Colors for the user to change the colors if h/she desires (as currently there is for other LO components). 4) Currently in the Formula Editor, the line breaks at a weird position, near the middle of the editor. It could be better to use all the available screen space. 5) There could be way to increase the size of the font in the Formula Editor (I mean the font used for the markup language). The current size is a bit small. I think the easiest way to implement this is to use the same configuration that's applied for the Basic IDE (which is the font set under Tools > Options > Fonts in the "Font Settings for HTML, Basic and SQL Sources". I'm available to test/comment future versions of this patch or new patches you submit to the Math component.
Dante, my comment was made in the wrong bug report. I was following a link sent by Heiko by e-mail, but only now I noticed my mistake. I'll post my comment in the right