Jump to:
| Project: | Signwriter |
| Version: | master |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Agileware |
| Status: | postponed |
Issue Summary
Just a suggestion:
Management of multi line text, vertical and/or horizontal alignment, underline or strikethrough, and other many specifics of text layout doesn't seem to be well handled by GD, the base library for this module (and probably these text layout feature are not the core features of such an image oriented library).
Then I was thinking about the benefits that would provide to go through PDF.
Because PDF has been built with *every* options for text layout (while PDF generation library don't always support every feature, for sure).
Once the PDF has been generated by an API like dompdf , it could be captured as an image with another one like imagemagick
It could seem weird, but I have the intuition that the result could be much more predictable.
I would also allow to have multiple fonts being used into the same image, or text fragments aligned left and some other aligned right, etc...
What do you think about this ?
Comments
#1
G'day, thanks for the suggestion. There are definitely some great examples on Imagemagick text processing here, http://www.imagemagick.org/Usage/text
I don't think the dompdf library could be of any benefit as that is HTML to PDF conversion. However, it may be useful to do a postscript to image conversion as shown here, http://www.imagemagick.org/Usage/text#postscript
Replacing the GD library with Imagmagick and the associated options is a fair amount of work at this stage and the GD library provides sufficient control for Signwriters requirements.
Moving this suggestion to postponed for consideration later when Signwriter is up for a major overhaul again.
#2
Thanks for your attention.
HTML to PDF : well, I believe that writing HTML is far easier than writing PDF (at least drupal users are more experienced in HTML)
It would avoid to cope will all the internals of imagemagick options and stay at a high level of description.
I understand that moving to imagemagick isn't really required today.
But my proposal is to take another approach: forget about image libraries options, expose text and font properties easily and get them rendered as images through a two step process (internally, yes), that would appear to the end user as a straight forward and more predictable process.
#3
So you are proposing that users set up the Signwriter profile using HTML & CSS to define how the text should be rendered. And then Signwriter should use this information to convert HTML to PDF (dompdf) and then PDF to image for display on the page.
Is that correct?
#4
+1 from me on the general goal
I was able to exactly match a client's company logo text with this CSS, at least in Firefox, but of course IE doesn't cooperate - feedback by CSS wizards welcome:
div#site-name,h1#site-name {float:left;
margin:.49em 0 0 .4em;
overflow:hidden;
white-space:nowrap;
text-transform:lowercase;
font-family:"Gill Sans MT","Gill Sans",Tahoma,Verdana,Arial,Helvetica,"Bitstream Vera Sans",sans-serif;
font-size:2.3em;
font-weight:lighter; /* 100 doesn't work for FF, nothing does for IE */
letter-spacing:.25em;
}
So we need to work with an image - I'm also planning on checking out Flir when I have some time.
For a logo, this isn't a big issue, but if this module or one like it could dynamically generate a consistent image from html/css markup for node titles, menu links etc I think that would be very useful to many people.
Of course if I'm mistaken and I can accomplish my original goals with our logo using Signwriter, please let me know, but in the case of the logo it does need to be pretty darn close to pixel-perfect.
Thanks
#5
@HansBKK: Could you not just use the company logo as a background image? Otherwise, which part could you not do in Signwriter?
#6
Yes,
the benefits of using HTML would be:
- mixing multiple fonts, sizes, styles in the same image
- support complex layouts, including a mix of image (background, bullets) and text
- ease the authoring of complex layouts since it would be in HTML
some drawbacks of this would be:
- every transformation has its own limitations, and then some CSS properties may not be supported or not rendered as expected in the HTML2PDF conversion process
- the same thing may apply to the PDF2Image process
- more complex debugging to understand where there is a failure in the transformation processing
could be an extension or a collaboration with another module : http://drupal.org/project/print which already does HTML->PDF
#7
another approach : Flash
http://drupal.org/project/render
#8
An obvious question would be:
If you can get the layout and effects you want using HTML+CSS, why are you even needing an image-renderer to print text?
:-)
ImageMagick, GD processes etc are only there to do things that HTML cannot do well enough. There is not much point in rendering HTML on the server and sending a picture of the result!
However, some other non-html based convergence of processing is to be hoped for.
#9
Because you can't control which fonts are installed on client machines (unless you use font embeding in Flash or in PDF), but you can achieve it in a controlled environment like on your server and build the image from their.
That's the key difference !
#10
Plus browsers' support of CSS typography properties vary widely even if you're just spec'ing "sans-serif"