Jump to content
You must now use your email address to sign in [click for more info] ×

¿HowTo: Convert between Art Text and Frame Text?


Recommended Posts

  • 3 weeks later...

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.

Link to comment
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?

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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. 

Link to comment
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.

Link to comment
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.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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.

Link to comment
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.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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.

Link to comment
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?

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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?

 

 

 

Link to comment
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.

Link to comment
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. 

Link to comment
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. 

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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 spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
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.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

  • 3 months later...
  • 2 months later...

+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.

Link to comment
Share on other sites

  • 4 weeks later...
  • 1 year later...

Switching back and forth is extremely helpful when developing pieces. This is especially true if you start with frame text and several words, and then cut one word out to format it as a separate object. When you paste, it assume frame text, but in fact, it's more functional (one word) as artistic text.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.