Re: What should we focus on in the future development of TinyMCE
If it's possible, please add more fonts to tinyMCE.
Get your own copy
Don't hesitate! Just download and test it all by yourself for free!
Re: What should we focus on in the future development of TinyMCE
Add it your self. Check the manuals.
Best regards,
Spocke - Main developer of TinyMCE
Spocke - Main developer of TinyMCE
Re: What should we focus on in the future development of TinyMCE
video converter to flv
Re: What should we focus on in the future development of TinyMCE
gpo1 wrote:
video converter to flv
Video is completely independent of websites... so this would be a most definite NO! This has NOTHING to do with editing an HTML document.
Plus, there are enough free video editing tools out there. Use them and don't bother Moxiecode with that!
Re: What should we focus on in the future development of TinyMCE
spocke wrote:
Add it your self. Check the manuals.
Ok, i looked at theme_advanced_fonts and with that can add the few browser-compatible fonts that aren't in the default font list of tiny.
Is it at all possible to push custom fonts to the browser?
I'd like to use fonts from my windows fonts directory..
Re: What should we focus on in the future development of TinyMCE
Remember that the target browsers run on the visitors' computers, not on your computer. So one way or another you will have to make your fonts available to those browsers.
There seems to be a possibility to include fonts in websites. But I remember I have seen publications saying this is pretty unreliable. It also would make your website to load slower! Just search on Google.
The general advice, however, is to limit yourself to the standard fonts available on standard Windows computers.
As for the technical part of your question: You can specify fonts in CSS style declarations. This has absolutely nothing to do with whatever front-end editor, as mr. Riesterer already said.
Greetings from the Netherlands
H. Hahn
Correction:
Fonts for TinyMCE are specified in TMCE's init function. But they are not "browser-compatible" fonts, as you suggest, but "fonts avalable on the computer".
H. Hahn
Last edited by HHahn (2008-11-13 23:47:35)
Re: What should we focus on in the future development of TinyMCE
well i have an already heavy CMS, a few extra KB to push a font wont matter (each website would use only a few, i'd recommend to my users).
so i'll google for it then..
edit: found http://typeface.neocracy.org/examples.html
its got a couple of drawbacks though.. you can't select text drawn by it, and it gets slow if you put a lot text in a custom font. (hopefully that'll change in ff3 and ie8)
display intergration with tiny could be a problem, i suspect...
at least i have no idea yet on how to integrate the two yet..
Last edited by ReneVeerman (2008-11-14 01:57:38)
Re: What should we focus on in the future development of TinyMCE
ReneVeerman wrote:
well i have an already heavy CMS, a few extra KB to push a font wont matter (each website would use only a few, i'd recommend to my users).
so i'll google for it then..
edit: found http://typeface.neocracy.org/examples.html
its got a couple of drawbacks though.. you can't select text drawn by it, and it gets slow if you put a lot text in a custom font. (hopefully that'll change in ff3 and ie8)
display intergration with tiny could be a problem, i suspect...
at least i have no idea yet on how to integrate the two yet..
Did you also find sIFR? the current most used font-replacement?
Grtz, Laurence
Re: What should we focus on in the future development of TinyMCE
Well, this sounds like the fonts are converted to images. Not a nice solution.
Try this website: http://www.fontembedding.com/fonts-and-the-web/
And this one: http://home.tiscali.nl/developerscorner … edding.htm
And, above all, this one: http://www.w3.org/Fonts/Misc/eot-report-2008
H. Hahn
Last edited by HHahn (2008-11-14 11:12:26)
Re: What should we focus on in the future development of TinyMCE
It is not a nice solution but with the most fonts, if you use commercial fonts from linotype like Helvetica LT etc., you aren't allowed to redistributed those font files.
with sifr you create a flash movie which get passed a text and renders it with the font saved in the flash file. It also don't turn it's back on usability because screenreaders only see the normal html text.
And it's supported by all common browsers(IE, FF, Safari, Opera, Chrome)
Grtz, Laurence
Re: What should we focus on in the future development of TinyMCE
The license problem is exactly what the last-mentioned link in my previous post is all about: http://www.w3.org/Fonts/Misc/eot-report-2008.
H. Hahn
Last edited by HHahn (2008-11-14 13:30:24)
Re: What should we focus on in the future development of TinyMCE
Thanks for the info guys, i think i'll wait with adding more fonts until its more properly supported. I dont like the hacks very much, and doubt they could be intergrated with tiny atm..
Re: What should we focus on in the future development of TinyMCE
The majority of its users however do not want the functionality you're asking for. I can say from personal experience that you can create a plugin to set all the functions / code cleanup & display / valid elements & attributes, then just add that in your config and voila. Maybe you can do this and share? It wouldn't be that difficult. 
Re: What should we focus on in the future development of TinyMCE
ReneVeerman wrote:
Thanks for the info guys, i think i'll wait with adding more fonts until its more properly supported. I dont like the hacks very much, and doubt they could be intergrated with tiny atm..
It does not seem to be a matter of support in the first place. You are simply not allowed to upload fonts that are copyright-protected. And most "good" fonts are copyright-protected.
This copyright limitation may be the reason that the CSS-support for fonts is not very well-known, and maybe even limited. If you happen to have open-source fonts, then I suggest you have a look at https://developer.mozilla.org/en/CSS/@font-face, though it seems to refer to Firefox 3.1 only.
Last edited by HHahn (2009-01-19 11:50:54)
Re: What should we focus on in the future development of TinyMCE
Bond wrote:
HaHA! I have already seen the great thing!!!
Has this anything to do with the topic? Let's remain serious; this is not a fun site or so!
Re: What should we focus on in the future development of TinyMCE
use the easier Firefox spell checker in context menu, instead the hard Aspell installation process.
Re: What should we focus on in the future development of TinyMCE
speednet wrote:
If I were to place them in order, this is my vote:
1. DHTML windows, possibility to use layers instead of popups
Sometimes we should make frameworks more easier and more flexible.
I want accessibility. DHTML-Layers with mootools are not accessible, you get a javascript overkill. Have a look on the iframes, maybe they are a security-risk. I gave my vote to popup-windows.
Last edited by Paracelsus (2009-02-07 13:15:18)
Re: What should we focus on in the future development of TinyMCE
My wishes:
- More information, examples, tutorials for developer, so that they could part of it
- Forms
- Presets for button toolbar, saved in cookie and cms-db
- Rescue older versions of text / Versions
- Plugin-intergrated accessiblity checker (I show my results that worked for me here in a few months)
Best regards
Re: What should we focus on in the future development of TinyMCE
Paracelsus wrote:
- More information, examples, tutorials for developer, so that they could part of it
For real webdevelopers (and I mean professionals!) the wiki contains more than enough information already. This is why only amateurs and "script kiddies" ask for technical help with the most basic things like integration, configuration, external image/link lists and so on.
Paracelsus wrote:
- Forms
Use the forms plugin if you need TinyMCE to create pages with forms. And please tell me in what way creating forms via WYSIWYG goes together with server-side scripting (the part processing the submitted form contents)!
Paracelsus wrote:
- Presets for button toolbar, saved in cookie and cms-db
Again that's an implementation problem and not a TinyMCE feature to be asked for. If you need to have "presets" then set them via your CMS/wiki/forum/board software and not via TinyMCE.
Paracelsus wrote:
- Rescue older versions of text / Versions
Again this is an implementation problem. The autosave plugin (search the forum for it) addresses this problem but it requires a server-side component which cannot and never will be an official part of TinyMCE since TinyMCE is and will always be a pure JavaScript application.
Paracelsus wrote:
- Plugin-intergrated accessiblity checker (I show my results that worked for me here in a few months)
I am looking forward to reading your information on your accessibility checks. It is a topic I am very interested in not necessarily from a TinyMCE-related point of view.
Re: What should we focus on in the future development of TinyMCE
Felix Riesterer wrote:
Again this is an implementation problem. The autosave plugin (search the forum for it) addresses this problem but it requires a server-side component which cannot and never will be an official part of TinyMCE since TinyMCE is and will always be a pure JavaScript application.
Actually, the TinyAutoSave plugin, which I've posted about a number of times in this forum, does not require a server-side component, and is programmed with 100% JavaScript. It has saved my butt a number of times when I click the wrong button.
TinyAutoSave is highly configurable and you can even extend it with your own functionality through its event model. So, for example, if you have non-editor information (like input fields) that you want to save in addition to the editor, you can write your own save function for the input fields and hook it into the TinyAutoSave onPreSave or onPostSave event. The plugin handles all the timing and other housekeeping necessary, and you just add the custom save piece for the non-editor parts. You would normally use onPostSave, but if you want to be able to abort the editor save, use onPreSave.
Naturally, you also have the onPreRestore and onPostRestore events so that your code can respond to a request for restoring the information.
You can download the plugin from its project page: http://tinyautosave.googlecode.com
The wiki on the project page has extensive documentation, and the source code is thoroughly documented as well.
If you haven't already given it a go, I'd recommend trying it.
Re: What should we focus on in the future development of TinyMCE
@speednet
Thanks for your plugin, I will tryout and give you a feedback.
Felix wrote:
For real webdevelopers (and I mean professionals!) the wiki contains more than enough information already. This is why only amateurs and "script kiddies" ask for technical help with the most basic things like integration, configuration, external image/link lists and so on.
Maybe, maybe not. I'm in the middle of an amateur and a professional, I think, a good tutorial or examples (like selfhml) can speed up the learning curve. But you are right too.
Felix Riesterer wrote:
Use the forms plugin if you need TinyMCE to create pages with forms. And please tell me in what way creating forms via WYSIWYG goes together with server-side scripting (the part processing the submitted form contents)!
I use the forms plugin. In firefox this plugin causes javascript errors and I see no guidelines, but nevertheless its good.
I write my own postprocessing scripts or take a postprocessing framework. Maybei I write a cms component, which parses the xhtml content and take over the field types and values in the admin area configuration. So, where is the problem?
Felix Riesterer wrote:
Again that's an implementation problem and not a TinyMCE feature to be asked for. If you need to have "presets" then set them via your CMS/wiki/forum/board software and not via TinyMCE.
Ups, You think I'm a nope. You can restrict the use of plugins for the users of your cms, like JCE for Joomla does and let your users configure theres toolbars via browser cookie, give them presets for tinyMCE-parameters and buttons. If a user don't want see some buttons, he can switch them off, change the position, the skin and so on.
Felix Riesterer wrote:
Again this is an implementation problem. The autosave plugin (search the forum for it) addresses this problem but it requires a server-side component which cannot and never will be an official part of TinyMCE since TinyMCE is and will always be a pure JavaScript application.
I know I know, but there are 2 different problems. First, save content quickly, dont loose content, second, make revisions of your content to go back to an old version. The autosave plugin is for the first problem an I will test it. The second problem needs to be solved in TinyMCE and with a CMS bridge. You cannot manage it without your cms.
Felix Riesterer wrote:
I am looking forward to reading your information on your accessibility checks. It is a topic I am very interested in not necessarily from a TinyMCE-related point of view.
Its much easier for me as german to talk in german, so let us write emails, skype or something like this.
Last edited by Paracelsus (2009-02-09 01:09:16)
Re: What should we focus on in the future development of TinyMCE
1. Performance and loading time
2. Better documentations and function helps
3. More examples, tutorials for developer
Re: What should we focus on in the future development of TinyMCE
@urdoll
Your post is pointless. All your demands have been fulfilled long ago. If you use the Gzip compressor your loading times will be dramatically reduced. Documentation is sufficient if you only would take a look into the wiki. As for examples and "tutorials"... no real developer would need them since the existing information is more than enough.
And yes, I've deleted your signature link - since this post is your first here I figured that its only purpose was to advertise your business as everything else is pointless (see above).
Re: What should we focus on in the future development of TinyMCE
Take a couple of humor and see spam.
In the wiki of the API reference under Core Classes [enlargement breast] is pointless too.
Re: What should we focus on in the future development of TinyMCE
Paracelsus wrote:
In the wiki of the API reference under Core Classes [enlargement breast] is pointless too.
Thanks for mentioning! I've deleted that nonsense.