By now… on iOS only the PDF Standard 14 fonts are supported. Very probably
we will be able to support other installed fonts in the future.
Meanwhile, it is possible to use other fonts that are previously added to
the iOS project. Some resources you may be interested on about this:
First off, iOS has native PDF support
and that Native support provides access to EVERY FONT ON THE DEVICE!
So this tells me that Xojo is doing 100% “roll our own” when infact they could easily created a Xojo syntax wrapper to what iOS provides…
I know it can be done, as I wrote a Swift class that does PDF using the same syntax as the Xojo class, but with support for much much more.
The entire point is: people don’t want to change the ship and don’t want to change the direction. So they will complain for their entire time. There is no help you can spend. Alternating search for other low code or somehow code platforms is in the same direction. They have their Ideas while they have no perspective and - that sounds weird - they do not want any new perspective other than thy think it is fitting to their workflow.
And differing to many others their workflow has no ; and mostly no { so they have some kind of panic when ; stands at the end of the line. That’s their life. They like to program with GO instead with a rock solid language with a huge eco system. They like to program mobile with flutter and dart instead of a rock solid programming language. So: let’s do it.
There is no need and no chance to help somebody as long as he thinks he knows better. And we should respect that Jeannot. While respecting that reduces also the amount of time we spend in trying to change their direction. You will get a camel and an elephant through a needle hole but not that kind of people to a new and industry level programming language.
I would have welcomed a native PDF creation for macOS and iOS where PDF support is part of the system too. Anyway, this would have let other systems without support, so they decided to adopt and extend an existing RB/Xojo-Solution. Makes sense from an xplatform point of view, but … well yes, could as well be related to the “adequately staffed” question.
I disagree… Xojo should leverage the tools provided by each OS to solve a problem. And if that means a different INTERNAL solution for PDF on each platform that is what it should be… Obviosliy we know that macOS and iOS offer a simple OS level solution. I would “assume” that Windows has something, as should Linux.
But then again as you mentioned, Xojo is “adequately staffed”
I feel no disagreement. Would have been my preferred solution too, esp. under the viewpoint of nativity of controls as promised by Xojo. But it would have meant much higher development times, and I think so we are back at famous argument #1 …
Each OS is different. My humble opinion is that Xojo is primarily a Mac based solution. When I have to write C++ code, create a plugin/declares to have beginner/intermediate functions in Windows and Linux, then the language is not ready for the target operating systems.
It is much easier to write the entire Windows program in C/C++ than to go through the hassle of making code compatible with Xojo. I write plugins and declares to help others target Windows and Linux. I am just helping others so they don’t have to reinvent-the-wheel.
Windows could have generated an XPS document which I think they have API’s for at the OS level - but that was some time ago
Now ? lord knows what they have but “something”
As some who has needed to write X-Platform software I disagree in general … That way results in sometimes significant platform differences… In My mind RB/Xojo has always been about not having tp worry about such things as much as possible/reasonable…
They have started using native underpinnings with things like URLConnection and from what I’ve see from others, that causes X-Platform coding issues…
Using Xplatfrom libraries does mean more work for them but IMO THAT is SUPPOSED to be one of the value propositions for using Xojo.
That’s one thing I live with java. Java itself catches nearly all xplatform stuffs. And so I have nothing to deal with except building different installers.
I would say if different OS platforms created visually divergent PDF files from the same document description than there is something wrong with one of more.
So you would rather have a solution that is cobbled together that supported the least common denominator, that a platform specific solution that leverages the OS level commands?
On the subject of PDF… the same document created by any OS should (and I bet does) look identical, the only potential diffence being if a particular font is or is not installed
TrueType is a font description format
Like HTML is a description of a web page
Its not the underlying rendering engine so MS and Apple may differ there based on whats possible on each OS in the same way each browser may look slightly different
for example
Increasing resolutions and new approaches to screen rendering have reduced the requirement of extensive TrueType hinting. Apple’s rendering approach on macOS ignores almost all the hints in a TrueType font, while Microsoft’s ClearType ignores many hints, and according to Microsoft, works best with “lightly hinted” fonts.
try it out and find out. They differ in rendering. With a Vinyl Cutter, same file, same software the fonts also differ minimal. I found the interesting.
TrueType was developed by Apple. Microsoft licensed the technology (format) at a later date in exchange for some Microsoft technology that Apple never used. TrueType was then extended by Microsoft and Adobe to create OpenType.
macOS, MS-Windows and Linux all have their own font renderers / text layout engines which means you never get the exact same result. Quite often the differences are minor and not really noticeable but sometimes they can be significant. The same goes for some desktop applications such as DTP applications and web browsers as they also use a mix of the operating system text layout engines and 3rd party (open source) text layout engines.
