[pdf4st] Encoding and Basic Text Attributes
- From: "Christian Haider" <Christian.Haider@xxxxxxxxxxxxxxxxxxxxxxx>
- To: <pdf4st@xxxxxxxxxxxxx>
- Date: Fri, 20 Apr 2012 16:28:05 +0200
Submitted by mac on Tue, 2012-01-31 14:41
Great Job! pdf4smalltalk is indeed a very valuable contribution to the
smalltalk community.
Experimenting with your "quickstart" expamples in Document class.... Maybe you
could add few more examples on basic text and font handling there besides your
impressive graphical ones:
E.g. trying:
renderer textObjectDo: [ ... renderer setFont: #Helvetica size: 16.
renderer showString: 'Übertrag 100,00 €']
does not show the non-basic characters correctly on my standard windows
machine. Do I have to provide the string in a certain encoding (of the font)?
Another example of an application of basic text attributes would be to show how
an underlined string can be added, and so on.
Guess a lot of people out there would be interested in knowing how to address
basic topics like that "out of the box" without having to to delve deeply into
the specs!?
Text handling
Submitted by ChristianHaider on Wed, 2012-02-01 15:54.
The font handling for non-basic characters in standard fonts was wrong. Thank
you for noticing and reporting this bug! It is fixed with the latest version.
I also added a few demo methods for text: your example, a font character table,
using different fonts and underline.
Text is handled only on the very low level of the spec. And this is not very
pleasant - I agree. In Painting a Page
<https://gitorious.org/pdf4smalltalk/pages/PaintingAPage> I discuss some of
the issues. Text is complex and it is not a good idea, IMHO, to just define one
out of the blue without really using it. I am hoping that a good text model
will emerge when several people have built their own abstractions. But maybe we
can develop one here as a community. I can start with a few requirements which
come to my mind:
Requirements for a proper PDF text model API:
Basic:
* being able to use all PDF text features
size, color, char and word spacing, horizontal scaling, leading,
rendering modes, rise, knockout, positioning and painting
* use font families to map styles
any combination of #bold and #italic should be mapped to the right font
* use font metrics for using text graphically
paint underline, background, sensitive links
* multi-line text with justification
left, right, centered, justified (spread out in a box)
With the above, VisualWorks Texts could be used.
More advanced:
* kerning
text may or may not be kerned. (Kerning is not implemented yet)
* ligatures
f+f+i -> ffi (Not implemented yet)
* (internal) Font subsetting
for legal and space considerations. (Not implemented yet)
* being able to use any glyphs from a font, not only the encoded ones
there is some ad-hoc support for tabular glyphs (equal spaced digits,
instead of the default proportional ones for tables), but no general solution.
* support for right-to-left and top-to-bottom writing directions
for arabic and asian scripts
* hyphenation
maybe by using external packages
* advanced typography
support for modern OpenType features: variants by culture or position,
flexible combination of diacriticals
What do you think?
(Text Model) API (How to use pdf4smalltalk in visualworks)
Submitted by mac on Thu, 2012-02-09 09:57.
Thnx for the fixes, it works!
Visualworks offers an abstract API for all (not only text) displaying/printing
tasks.
It consists of a GraphicsContext that has to be accessed, together with a
GraphicsMedium and GraphicsDevice.
Concrete implementations of that framework build the - display system for VW
windows on the screen - hostprinting for windows printers - postscript printing
system
The API fully supports Visualworks Texts/ComposedTexts and therefore the basic
features you listed above. (Although not all of your 'More advanced' - as far
as I can see).
Pdf4smallalk could be seamlessly integrated into Visualworks by implementing an
additional implementation/subsystem of the framework mentioned above building
the pdf4smalltalk API:
That approach looks straight forward to me:
Setup a 'PdfGraphicsContext" referencing a 'PdfGraphicsMedium' that acts as a
wrapper of a PDF.Document
And that approach would promise great opportunities:
- Applications that do use the Visualworks printing system to print on paper
could instantly create pdf-Documents of their documents (Graphics.Document
objects) without having to change them.
- WYSIWYG graphical end user report builder where the layout of a page can be
build interactively by placing widgets on the screen and printed as
pdf-documents by just displaying them on the 'PdfGraphicsContext' instead of a
ScreenGraphicsContext
Have you ever taken that solution into account ??
PS: I have to admit that this is really a VisualWorks point of view. Another
general/independent aproach towards an API like the - very interesting - report
builder that Bob Nemec is working on is naturally better suitable for porting
to other Smalltalk dialects and therefore for the smalltalk community as a
whole.
Using VW GraphicsContext
Submitted by ChristianHaider on Thu, 2012-02-09 11:23.
What you describe is exactly what I meant with "With the above, VisualWorks
Texts could be used". This would be nice to the VisualWorks application
programmers who could just use their graphics/text drawing and have it as PDF.
To do that, the library needs a few more features: TrueType fonts, Font
subsetting and Bitmap support (as I wrote in the blog entry
<https://gitorious.org/pdf4smalltalk/pages/Blog#Quo+vadis?> ).
The problem is that the VW graphics API (aka GraphicsContext and friends) is
very outdated and limiting - that was actually the whole reason for me to do
EPS and now PDF for professional graphics. Some of the limits: no gradients, no
transparency, no kerning, weird font selection, only RGB, no dashed lines, no
arbitrary paths, no clipping...
I think it would be good to have a VW PDF GraphicsContext, but I would not use
the model of VisualWorks. Rather, I would define new abstractions for graphics
and text close to the PostScript/PDF imaging model. A VW GC could then do the
translation from VW to the PDF model, which should be easy once the three
missing features from above are done.
For such a new model, I would try to get inspiration from other libraries (PDF
and Graphics) like Cairo, SVG, iText etc., but I really would like to do one
from scratch allowing for all the possibilities PDF has to offer.
A VW PDF GC is a nice addon, but a sideline for progress. The main direction
should be (1) to evolve good models and (2) keep the library dialect
independent to ease ports to other Smalltalks.
Other related posts:
- » [pdf4st] Encoding and Basic Text Attributes - Christian Haider