I know there has been much discussion about dealing with RTFs in Xojo, with the conclusion that it’s pretty kludgy and slow. However, I wonder if my really (really) low end requirements might find a solution.
I need to parse text from a database into formatted paragraphs. One font, no character, or even word level styling - all paragraph level. Ten limited, hard coded paragraph styles that involve left and right indents, some pars are all caps and, in one case, the par is enclosed in parenthesis. I also need to access page breaks to add page numbers and specific end of page functions (breaking pars across pages)
I don’t need to open anything generated anywhere else. I just need my user to be able to write WYSIWYG in a text area and to be able to print and send to PDF.
Is this too much to ask of Xojo? My other option seems to be to create small, platform specific apps in Xcode/Visual Studio to supplement my Xojo created, cross platform app, accessing the same SQLite. I’d be more than happy with RTF, XML, HTML or whatever markup is required so long as I can hide the markup from my user and present them with a WYSIWYG editor.
It’s a little hard to understand exactly what you need to do; sounds like there is both formatting data from a database into a text document and user entry of free text. If you are dealing with such a mix, are there elements the user is not allowed to edit/reformat? If so, then using the rich text in the textarea will be a problem if it’s all mixed together.
A couple ideas:
Generate an HTML page from the database information and insert input divs for the free text. You could do this as a template you load so that you can iteratively make updates. Use CSS and HTML formatting to get the structure you want. Tricky to get the pagination and numbers.
Use the Report object. This will handle the database piece, but you’ll have to get the free text separately and merge it with the database results to feed to the report. Should handle pagination, though.
Get the data and text and generate PDF directly with PDFDocument. More work
Canvas-based custom control – full control over everything, but a lot of work.
Your main problem is going to be combining free text entry with the level of control you want over the overall structure. Don’t think you’ll be able to do that with a rich text control in any environment all by itself. If you can collect the free text from the user without being fully WYSIWYG for the whole document, you have lots of options in Xojo to generate the output without a lot of work. The full WYSIWYG end-to-end experience is going to be a bit of work anywhere, if I understand what you’re trying to do.
Thanks Matthew. Think of it as importing text into a word processor, applying a style sheet and then editing that document, maintaining paragraph styles to current paragraphs and applying styles to new paragraphs. MS Word 2.0 or any other RTF capable app.
The problem seems to be that Xojo have never really seen the need to support basic word processing capabilities. Guess I’m aiming outside their remit…
Hey Michel, I’m assuming the 16Kb (should that be 16KB?), is based on the limitations of StyledText needing to reparse each character. I know there was some talk years back about having the parser work at paragraph level instead of character level to save time but I can’t even find a way to count pars instead of lines. Do you know if anything came of that? I’ve read through half a dozen threads on the subject but, aside from a couple of now defunct plugins, we seem to have regressed from 2013 to now.
This should be bread and butter stuff. Unfortunately, these are the issues you may run into:
Slow parsing of RTF.
Incorrect parsing of RTF (corrupted Unicode characters).
StyledTextPrinter has been removed for MS-Windows meaning that there is no built-in way to draw formatted text to a graphics context (ie: printing). My replacement class which you’ll find in another topic might help.
Xojo PDF creation does not support Unicode so you are limited in what characters you can output.
Xojo PDF creation does not support font sub setting so you could end up with large PDFs.
Xojo PDF creation does not support any kind of font fallback / missing glyph detection meaning that the font you draw in must contain all of the characters.
I suggest you create a very rough proof of concept to test the key functionality to see if you run into any of the above or other problems.
If you do run into problems then you might be able to replacement parts with 3rd party tech. For example, both MBS & Einhuger have PDF plugins. There was also a 3rd party text editor product called Formatted Text Control but that got discontinued by the original developer partly due to direction Xojo Inc. have taken the product. If I remember correctly, FTC has been bought by someone and might become open source.
Thanks for the PDF advice Keving and Christian. I’ll bear that in mind should I get the rest to work in Xojo. I’m familiar with MBS from my Filemaker days.
[quote=“keving, post:7, topic:64194”]
This should be bread and butter stuff
[/quote] I would have thought so. The term WYSIWYG was coined in the 70’s but Xojo’s telex operator never got the memo
[quote=“keving, post:7, topic:64194”]
There was also a 3rd party text editor product called Formatted Text Control
[/quote] And another called WordGuise but both have gathered dust.
[quote=“keving, post:7, topic:64194”]
StyledTextPrinter has been removed for MS-Windows
[/quote] Really? I didn’t know about that one. Ouch!
I find this so very frustrating. Xojo’s cross platform abilities are so compelling but this blind spot is going to force me to native app development which will, eventually, mean moving away from Xojo to keep the code base all together. Coding the database interface in Xojo means one project, which is great. If I have to then write two word processors in VS/Xcode, one for each platform, that makes three. I can reduce that by one by going full native.
The sad fact is that Xojo is getting worse and not better. Unfortunately, it seems that the only people who don’t realise this are Xojo Inc themselves.
I fear you’re right. When I spoke to them about this very matter, one, they had less to say than those here on the forum, telling me that it couldn’t be done - not even mentioning the RTF capabilities they do have and two, defending their position by saying that TextArea “was never meant to do this”. What?!
On second thoughts, I just tested that with text of a length my users will typically need to work with and, like the standard RTF parser, it’s so slow as to be unusable. Shame.
Pity there isn’t some way to restrict either the RTF or HTML (or XML) parsers to just reference paragraphs and not characters…
You can search the end of lines and set the html styles to them…
Then save the data as html file, load it in an HTMLViewer and print to PDF from there.
