David in MA

Is Designer V2 able to import text on path from Adobe Illustrator?

Loukash - I use a similar technique to transfer text on a curve from AI to Ade. However, I also have many years of work with hundreds, perhaps thousands of text on a curve items, so having part or all of the process automated would be a big help.

When I import files from Adobe Illustrator, text on a curve is imported with each character in an individual text box with no connection to the rest of the text. The curve is not imported. This makes editing the text on the curve a nightmare. Please import text on a curve as text on a curve, or at least import the curve so text can be attached and positioned correctly.

I'm trying to resurrect some design files originally created with Illustrator and saved as Adobe PDF. Many use gradient shading or blended shapes. These look fine in any PDF viewing app, but Designer is still not able to render or work with these. Very frustrating. I hope they implement gradient shading and blended shapes soon.

Thanks Thomaso. To be clear, when a Shad immediately follows a Tsek, the line break should be after the Shad, not after the Tsek. In all other cases I can think of, a line break can be after the Tsek. Prior to vs 1.8.4, Publisher did not allow line breaks after a Tsek. v1.8.4 fixed that, but there is this one exception that needs to be implemented. Thanks.

Yay! v1.8.4 fixed line-wrapping after Tsek ... almost. There is one exception that still needs fixing. When Tsek(U+0F0B) is followed immediately by Shad ( either U+0F0D, U+0F14, or U+0F07F ), then the line wraps after the shad, not the tsek. This is a great improvement - thanks, but still needs one more tweak.

Once again my hopes were up that the latest release, v1.8.3 , would fix the Tibetan "Tseg" bug that doesn't allow lines to break after a tseg. Unfortunately, fixing that bug didn't make this cut. PLEASE fix this. Thanks.

I just tried laying out some Tibetan text in Publisher 1.8.2 with hopes that the new version fixed the problem with lines not wrapping after the Tsek character. They are referring to it as hyphenation, which I suppose is accurate since Tsek is a syllable delimiter and there is no actual word delimiter for multi-syllabic words. At any rate, it still doesn't work properly. I'm hoping the next update will fix this.

Not exactly. That would work for a square or circle, but for irregularly shaped paths/objects it would scale the whole shape toward the center, even if locally at a point on the curve the interior is away from the center. For example, the outline of a thick letter 'C'. Your method would reduce the size of the whole shape proportionately. What I'm thinking is if you shrink the outline so the C becomes skinnier, ie, the outline of the C moves toward the interior, not toward the center of the whole object.

In Tibetan, especially in pechas, it is considered a special case, if the last syllable of an expression that is terminated by a shad ། breaks to a new line. In that case the shad ། ( U+0F0D ) is replaced by rin chen spungs shad ༑ ( U+0F11 ). This serves as an optitical indication that there is a left-over syllable at the beginning of the line that actually belongs to the preceding line. There does not seem to be a regular expression to find such orphaned syllables when the new lines is a result of formatting rather than an inserted line-break character. It's very tedious to hunt through a text to find and replace shads that occur after the first syllable on a line, so it would be a great help to have a feature that does this.

I'd just like to add another vote for this feature. It's important to our work and we are in the process of switching from Adobe to Affinity. The lack of this feature is a bit of a stumbling block. In the process of trying to find a workaround, I came up with an idea for another tool as well. In Photos, the grow/shrink option under the Selection menu allows one to expand or contract the selection marquee by a specified number of pixels. It would be great to have a similar option in Designer that grows/shrinks a closed path or shape by a specified distance. It should be easy to implement since they've already coded this for selection marquees.

Since you are curious, there is an odd grammar point in Tibetan. "Sentences" usually end with a Shad character ( ། ). If there is just the last syllable of a sentence at the beginning of a line, then the Shad character is replaced by a Rinchen Spungs Shad ( ༑ ), I suppose to indicate that it's connected to the sentence on the preceding line. So I want to be able to search for those orphaned last syllables and replace the Shad with a Rinchen Spungs Shad.

The ^ and $ in regular expressions search for begging and end of lines which are delimited by paragraph or newline characters. I want to search for the beginning or end of a line that has been wrapped by the formatting. For example, if the last word of a paragraph is the only word on that line. I can search for the last word of the paragraph, but there seems to be no way to search for the line wrap just before it.

Walt, I saw your earlier message, but there is no Edit link in my initial post. Dan C edited my second post and renamed the thread in the process. I'm not able to override that, or make any edits to any of my posts. Dan C, if you're listening, please change the name of this thread to "Tsek character not functioning properly in Tibetan", or at least something with Tibetan in the Title. thx.

I was happy to see that Publisher v1.8 added the IDML import feature. This is a big help. But unfortunately, the Tibetan Tsek bug has not been fixed. I wish they would name this thread more appropriately. It strongly affects anyone working in Tibetan as it prevents lines from wrapping properly and paragraphs being justified. Better yet, I wish they would fix the bug. It can't be that difficult to adjust the properties of a single unicode character to work properly.

installing a Tibetan spelling dictionary per instructions did not help. See the bug report at

It looks like this topic was renamed from my original post while I was replying to the previous comment. The new name doesn't exactly fit. There is no hyphenation in Tibetan as syllables are already delimited by Tseks. Words are either a single or multiple syllables which must be recognized as there is no additional grammatical character separating words. The point is that Publisher is treating the Tsek character as an alphabetical letter that is part of a word rather than delimiting words and allowing line breaks after them when needed. Thomaso - you did good research. Those points are all valid. In general, there can be multiple grammatical characters in a sequence that should not be broken up. Line breaks can occur after Tseks or spaces, but if there are additional grammatical characters adjacent to the Tsek, they should not be broken up. I hope they rename this topic to something more fitting. Perhaps "Tibetan Tsek not recognized as a word delimiter"

I followed the directions for installing a spelling dictionary for Tibetan in the Mac OS. (Wow, that feature is really hidden.) It now appears as an option for Spelling Language in Publisher, but does not solve the problem with Tseks not being recognized as word delimiters. To be clear, a Tsek should not force a line break, but should allow a line break when needed, much like a space between words in English except that it appears as a dot. In Tibetan, words and syllables all end with a Tsek. As is, Publisher only wraps new lines where spaces exist between sentences and treats the whole sentence as a single word, breaking it at random places is there is no room on the line. If I add zero width spaces after every Tsek, then line wrapping and paragraph justification work as they should because the added zero-width space allows Publisher to wrap the line after a tsek when needed. But I shouldn't have to add those zero width spaces. Otherwise, I'm finding Publisher to be a good replacement for InDesign and hope that you soon get the feature to import IMDL files working so we can import our old InDesign work without having to reflow all the text. Thanks, David EDIT - This post was merged from a separate topic as it best fits with your thread here.

I do see Tibetan in the Typography script pulldown, and the options within that are working. Tibetan does not appear in the other three pulldowns. There is no documentation I can find about where to put dictionary files. On Mac, the standard location is in the dictionaries folder either in the user Library folder or the global Library folder. Is there some other place the dictionary file should go for Publisher on Mac? Even so, I don't think this is a dictionary problem. In Tibetan, each "word" or "syllable" ends with a tsek. Lines should wrap after any tsek. Publisher is treating the tsek as a non-breaking space or letter within a word. It shouldn't matter whether the word is in a dictionary or not.

I'm using Publisher v 1.7.3 on Mac OS 10.15.2. I have a couple of Tibetan dictionaries installed in the Mac. When I use Unicode Tibetan, I do see the Tibetan option in the typology options. Ligatures and contextual alternates are working fine. I do not see my Tibetan dictionaries as options in the choice of dictionaries, but I don't care about that. The problem is that Publisher is treating the tsek ( or tseg: U+0F0B ) word separator as a letter. So a whole sentence becomes a single word and Publisher does not properly wrap lines after tseks. My workaround is to globally replace tseks with tsek followed by a zero width space. When I do that Publisher properly wraps lines and justifies paragraphs. Microsoft Word fixed this problem in Word for Mac 2019. Recent versions of LibreOffice and NeoOffice handle it properly as well. InDesign required enabling their World Ready paragraph formatter, but we are trying to get away from using InDesign in favor of using Publisher. It would help greatly if you can fix this problem so Tibetan tsek is treated as a word or syllable terminator to allow line wraps after them. Thanks, David Dvore

PPS: I already had two Tibetan dictionaries installed in the Mac OS. So that wasn't the problem. I think it's just a matter of treating the tseg as a whitespace character instead of a letter, thereby allowing line breaks after a trek. I'll submit a bug report as you suggested. Thanks.

PS: Microsoft Word 2011 and 2016 for Mac had this problem, but the Mac supplied TextEdit program and recent versions of LibreOffice and NeoOffice work properly. Microsoft Word for Mac 2019 fixed the problem in Word. So support for this seems dependent on the App and version.

I just looked up the unicode value. I guess the official name is "tseg" and the value is U+0F0B . It functions like a space in english separating words. Publisher is treating like a letter, so it considers a whole sentence as one word and doesn't know where the true word boundaries are. There is no hyphenation in Tibetan. I'll try to figure out how to add a Tibetan dictionary to see if that helps.

Thanks. I had chosen Tibetan in the typography options. That got the contextual alternates working properly. I'll have to figure out about the dictionary and hyphenation, however, I don't think that will do what I want. I don't want to break works at the end of the line, but rather, I want Publisher to treat the "tsak" character as a space separating words (note: tsak, not task as the spell checker wanted to substitute). I used your suggestion about inserting zero-width spaces and found that works. Especially, by using Find and Replace, I searched for all tsaks and replaced them with tsak followed by a zero with space. The extra character is invisible but allows Publisher to properly wrap lines after tsaks without breaking words. Thanks for the tip. It would be nice to not have to do this, so I hope Affinity will someday support unicode foreign languages properly. We had been using Adobe products for years, but with their subscription model, weak support for Tibetan unicode, and the new Mac OS obsoleting the last versions that could be purchased outright, we were very happy to see your products come out as a replacement for the Adobe ones. I'm hoping you can improve the ability to import InDesign and Illustrator files. I understand that when Publisher 1.8 comes out, it will be able to import InDesign IDML files maintaining threaded text boxes. Yay!

I'm using a unicode Tibetan font in Publisher. The character stacking, ie contextual alternates, are working properly. However, the line breaks are not recognizing word boundaries. There is a character called "task" that separates syllables or words and should be treated much as a space or hyphen in English. However, Publisher is treating these as characters in a word, so a whole paragraph is treated as a single word, and line breaks occur in the middle of words rather than after "tasks". The best would be to have Publisher properly treat unicode Tibetan. Is there a way to define a style with appropriate character and paragraph settings to do this? If not, is there a way to define white space characters that Publisher would use for determining word boundaries and where to put line breaks?