Jump to content
deeds

¿HowTo: Convert between Art Text and Frame Text?

Recommended Posts

This is one of those annoyances that all of us have encountered from time to time, and a quick way to convert just the text from artistic text to text frame and vice versa would be GREATLY appreciated. For just a few items, the copy-and-paste song and dance does work well. But for any number above what can be counted on one hand (that's five for most of us), it gets very tedious indeed.

 

My thought would be to have a right-click -> convert to... option, where a new layer is created in the destination format, using just the default settings for that format, and the text dropped into it. Nothing more is needed. Then the user would be able delete or hide the the original layer as he/she sees fit, and format the new layer to their heart's desire.

Share this post


Link to post
Share on other sites
1 hour ago, Michael Sheaver said:

This is one of those annoyances that all of us have encountered from time to time, and a quick way to convert just the text from artistic text to text frame and vice versa would be GREATLY appreciated.

I don't understand what you mean by "just the text" or "just the default settings for that format."

 

Frame text conforms to the width of the frame, so fo example I could have 10-15 sentences in a text frame with no returns -- just a single long paragraph that still fits comfortably on the width of the canvas. But converting that to artistic text would result in one long line of text that could be many times the width of the canvas. Similarly, I could have one or a few sentences in an artistic text block, with returns inserted as needed to control its width. Converting that to frame text would break the sentence(s) at various mid-sentence locations, so that would not conform to the width of the frame.

 

For both, there would still be a lot of tedious work to put them into the format for which that text type is intended. I am assuming that "just the text" is somehow supposed to simplify that, but I don't understand how, nor do I understand what the "default" settings for each format would be or how that would help. Can you explain a bit more about that?


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites

R C-R,

 

In CorelDraw, that's not what happens. There are line breaks inserted at the wrap positions. And if the desire is for the artistic text to be in individual lines, there's a command for that, too. The process can be reversed.


My computer is a nothing-special Toshiba laptop with unremarkable specs running Windows 10 64-bit.

Share this post


Link to post
Share on other sites
40 minutes ago, MikeW said:

In CorelDraw, that's not what happens. There are line breaks inserted at the wrap positions. And if the desire is for the artistic text to be in individual lines, there's a command for that, too. The process can be reversed.

Good to know, but unless I am still missing something, that involves more than a simple one-click 'just the text' conversion between frame & artistic text.


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites

There was also an Illustrator script you could download that used to do this nicely and simply. 

 

Yet, I guess the challenge with Affinty Designer are symbols. Let say you have text frame in a symbol and have various instances of that symbol where you adjusted the frame width, redulting in various rags. If you converted it to artistic text, you would a problem. 

Share this post


Link to post
Share on other sites

 Quote

55 minutes ago, R C-R said:

I don't understand what you mean by "just the text" or "just the default settings for that format."

 

Frame text conforms to the width of the frame, so fo example I could have 10-15 sentences in a text frame with no returns -- just a single long paragraph that still fits comfortably on the width of the canvas. But converting that to artistic text would result in one long line of text that could be many times the width of the canvas. Similarly, I could have one or a few sentences in an artistic text block, with returns inserted as needed to control its width. Converting that to frame text would break the sentence(s) at various mid-sentence locations, so that would not conform to the width of the frame.

 

For both, there would still be a lot of tedious work to put them into the format for which that text type is intended. I am assuming that "just the text" is somehow supposed to simplify that, but I don't understand how, nor do I understand what the "default" settings for each format would be or how that would help. Can you explain a bit more about that?

 

From the standpoint of a software engineer or developer, my proposal is really easy to implement. However, the stuff you are seeking, though it would be VERY NICE to have, it would be a rabbit hole to try and implement programmatically. There are just too many variables to track in order to pull this off gracefully, and when you look at every possible combination of those variables, well just thinking about this makes my head hurt. Sure, others may have made it work, but it was at a great expense, not only in terms of development time and troubleshooting, but also in terms of greatly reduced usability and performance of the software.

There is a reason that Affinity is so much better than others, and that is they have learned the importance of saying "No", and have thus far been able to stay true to the principles of good software engineering. This is a very rare trait in today's world, and Serif has my greatest admiration for keeping on course.

Share this post


Link to post
Share on other sites
3 minutes ago, Michael Sheaver said:

There are just too many variables to track in order to pull this off gracefully, and when you look at every possible combination of those variables, well just thinking about this makes my head hurt.

It makes my head hurt too, particularly when I think about the implications for seamless compatibility across all the apps in the Affinity suite, including the yet to be released but much anticipated Publisher app. I am not aware of any other software company that has ever managed or even attempted to do that. To me, it seems an almost impossible task.


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites
18 minutes ago, R C-R said:

Good to know, but unless I am still missing something, that involves more than a simple one-click 'just the text' conversion between frame & artistic text.

 

First, it's easy to write the VBA (and there are free VBA macros that are available) to do it in one go, both directions. Second, if the goal is simply to convert artistic text to paragraph text and vice versa, then it is one keystroke combination (the same keystroke combination is context sensitive).

 

It is possible in other applications. It is a nice to have facility. It is not on my personal list of the top ten work-flow things I would like to see in AD, but it is on a larger list of things I am likely to never see in AD.

 

Sometimes I think you just like being a naysayer.

 

One thing about AD that I would like to see that makes a lot of requests doable from the end-users perspective is scripting with complete access to the DOM. It would free up Serif from some of these additions.


My computer is a nothing-special Toshiba laptop with unremarkable specs running Windows 10 64-bit.

Share this post


Link to post
Share on other sites
1 minute ago, MikeW said:

Sometimes I think you just like being a naysayer.

I don't particularly like doing that but I think people too often don't consider the complexities involved in adding what they see as some 'easy to implement' feature to the Affinity code base.

 

If nothing else, I firmly believe that should remain platform agnostic, which rules out a lot of things that might indeed be easy to implement in apps written specifically to run on Windows, macOS, or whatever. For example, I too would like to see a full featured scripting language added but making anything dependent on VBA would be just as unacceptable to a Mac user as anything dependent on AppleScript would be to a Windows user.

 

I also believe that prioritized adding features according to their popularity in the numerous & diverse feature request lists would be among the worst things Serif could do. That should remain as it is, with the priority given to what can actually be implemented in the existing code in a reasonable amount of time without having to rewrite substantial parts of it.


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites

CD is Windows only and they (Corel) chose VBA for some reason. I wouldn't have, but hey, they did. I wasn't suggesting that Serif does VBA for Windows and AppleScript for Macs. My vote is for JavaScript, others want Python. Both are cross-platform.

 

I also wasn't arguing that Serif change their implementation of features to cater to demand or otherwise interrupt their plans for development based upon user requests.

 

Both are straw-man arguing.

 

Point is, for some of these suggestions that can be accomplished in JS or Python does relive Serif of certain burdens. If Serif keeps the Affinity products a closed-loop development and therefore doesn't expose the DOM to developers, they (Affinity products) really won't see wide-spread adoption in professional circles. A for instance. Carl just posted a neat image in the Share Your Work section. It's really well done. It takes equation filters. Which is something only a programmer could love (or those so inclined to play with formulas). If the DOM was opened, one could build an interface that hides such equations from the end user (or leave them exposed) and with sliders, knobs or whatever UI interface, achieve the same effect. That would mean that Serif could either forego building an interface to such shadow and warping effects or they could build it in according to their schedule. But people could experience the power of those equations with fiddling around wit the math of it all sooner.


My computer is a nothing-special Toshiba laptop with unremarkable specs running Windows 10 64-bit.

Share this post


Link to post
Share on other sites
5 minutes ago, MikeW said:

Point is, for some of these suggestions that can be accomplished in JS or Python does relive Serif of certain burdens. If Serif keeps the Affinity products a closed-loop development and therefore doesn't expose the DOM to developers, they (Affinity products) really won't see wide-spread adoption in professional circles.

So what exactly is the DOM used in the Affinity core code?


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites
1 hour ago, Michael Sheaver said:

Sure, others may have made it work, but it was at a great expense, not only in terms of development time and troubleshooting, but also in terms of greatly reduced usability and performance of the software. 

 

Don't want to put oil on the fire here, and call me uneducated, but when I look the illustrator scripts that perform that conversion, they are fairly simple and weigh about 1.25 KB, for both (about two paragraphs of code). Of course I see that implementing a full feature function will require more development but I'm somewhat sceptical in the amount of code required. I’m sure it’s more complicated than that, but still. Again, that's leaving the symbols outside of the equation. 

 

Ref: https://ajarproductions.com/blog/2009/03/07/convert-illustrator-point-path-text-to-area-text/

 

Also. Coming from a different field entirely, Autocad had features to combine separate lines of text into one text frame in the mid nineties — it was an add-on script at the time if I recall. As previously mentioned, so did Corel Draw in the same time frame. 

 

Surely, 20 years later, something can be done on modern systems. Or am I just really missing that much?

 

 

 

Share this post


Link to post
Share on other sites
17 minutes ago, R C-R said:

So what exactly is the DOM used in the Affinity core code?

 

Dunno. It's not exposed. It's not documented. DOM = Document Object Model, which likely is inappropriate here in the strict sense. Point is, though, that for scripting (or plug-ins to be made) to work in an application, the objects, methods, calls, etc need to be documented and exposed to third-parties. Scripting & plug-ins can only be made to work on what the application developer exposes to the third-party developers.

 

It'll be a happy day for some when it does happen. And that happiness can/will spread to other users who will be the beneficiaries of that possibility.


My computer is a nothing-special Toshiba laptop with unremarkable specs running Windows 10 64-bit.

Share this post


Link to post
Share on other sites

Twenty years is ancient history in technology, and yes, a LOT has changed since then. They built their system on Java, which, from a user experience perspective, is absolutely hideous. It is extensible and hackable, sure, but an awful pile of bolts to use. "Modern" alternatives like Chromium and Atom are following the same path, and it sucks. These platforms give dev teams the ability to quickly produce fancy systems with lots of bells and whistles, but just under the skin is a rat's nest of spaghetti code that nobody knows how they work. I use a major software built upon Chromium, and despite the devs best efforts to tweak it and fix bugs, is so bad that I cringe every time I open it. 

Share this post


Link to post
Share on other sites
4 minutes ago, arkinien said:

The instructions for those scripts say to place the files in the scripts directory within the Illustrator application directory. There is no such folder in either Affinity app. Even if there was, there is no support for JS or any other kind of third party scrip support built into these apps, at least that we know of. As @MikeW just wrote, we don't know any of the details of what the DOM in the Affinity apps might be, or even if they include DOM-like structures or features a scripting language could use.

 

As for exposing all that would be needed to support that, the developers have already said they are currently not willing to do that because they believe it would reveal too much of what they consider to be their proprietary trade secrets to their competitors. It is a valid concern, one they would be foolish to ignore. 


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites

R C-R,

 

No. As far back as 2014 Serif indicated they were looking at implementing JavaScript ability. It's been reiterated since. What Serif does maintain is not opening up the file format. Two different things.

 


My computer is a nothing-special Toshiba laptop with unremarkable specs running Windows 10 64-bit.

Share this post


Link to post
Share on other sites
30 minutes ago, MikeW said:

No. As far back as 2014 Serif indicated they were looking at implementing JavaScript ability. It's been reiterated since. What Serif does maintain is not opening up the file format. Two different things.

What they said was they were looking at ways to implement some kind of scripting ability in the future, but JS was just one of the possibilities. They also said they needed to see how much of this could be done without revealing any trade secrets. It was never just about the file format.


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites
14 minutes ago, R C-R said:

What they said was they were looking at ways to implement some kind of scripting ability in the future, but JS was just one of the possibilities. They also said they needed to see how much of this could be done without revealing any trade secrets. It was never just about the file format.

 

I’m pretty sure it was mentioned that it would be JS rather than Python.


Alfred online2long.gif
Affinity Designer 1.6.5.123 • Affinity Photo 1.6.5.123 • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.6.11.85 • Affinity Designer for iPad 1.6.4.45 • iOS 12.1.1 (iPad Air 2)

Share this post


Link to post
Share on other sites
27 minutes ago, Alfred said:

I’m pretty sure it was mentioned that it would be JS rather than Python.

I know both have been mentioned as possibilities but I don't know if there ever was any definitive statement about which one it would be ... assuming they ever do actually implement full support for any standardized scripting language, whatever it might be.

 

Either way, I suspect it will not be soon, most likely sometime after the retail version of Publisher is released, & initially offer considerably less scriptability than many users would hope for. Call that naysaying if you want, but I think it is just being realistic.


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites

+1 for this option too.

I've just been importing a couple of different PDFs into AD, one of which was created in Excel (I needed a table). The PDF import seems to choose Frame Text for some cells and Artistic Text in others (depending on what text options are selected during import).

Now what I want to do is scale the table vertically to fit a particular gap, whilst retaining the correct font aspect ratios. Frame Text is good for this but Artistic Text will end up all 'squished'!

If there was an option to 'Convert to Frame Text', it would save me looooads of time.

On 10/11/2017 at 10:33 AM, αℓƒяє∂ said:

If you’re going to be changing the content frequently and you often add extra lines, why not create it as a single line of Frame Text in the first place? :/

I always use Frame Text, but in my example above I have no choice but to start out with Artistic Text.

Share this post


Link to post
Share on other sites

Has this been added as a feature request? Any ETA on if/when the feature is coming?

Illustrator's implementation is a perfect example on how it should be done.

UPDATE:

I just created a feature request for this here .

Edited by shaneparsons
Added a link to the feature request

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×