Jump to content

Recommended Posts

Yes! Hard to work with the beta version and do a real evaluation when I cannot enter and use my WORD (.doc) files. Is there really a problem in implementing this?

Share this post


Link to post
Share on other sites
1 hour ago, Phil Martin said:

Is there really a problem in implementing this?

Yes the file format is proprietory (and old), but we hope Word (.docx) should be available at some point. It won't be available before anchored objects and inline images because a Word document is essentially always made of these.


Patrick Connor

Serif (Europe) Ltd.

Share this post


Link to post
Share on other sites
37 minutes ago, magicdesign__ said:

...the quickest solution?

Quick but not ideal. There is a lot more to a Word document than (approximately) the way it looks, which is all that would preserve. PDF is not a good interchange format and was not designed as such.
For quick results with text styles and other formatting export as RTF would be better if not tables and images are involved.


Patrick Connor

Serif (Europe) Ltd.

Share this post


Link to post
Share on other sites
3 minutes ago, Patrick Connor said:

For quick results with text styles and other formatting export as RTF would be better if not tables and images are involved.

@Patrick Connor,

may I point you to this this post from last weekend:

It's about RTF-files exported from Word not working with APub. Perhaps this can looked into?

Thanks,
d.


Affinity Designer 1.7.1.404 (beta 1.7.2.424)   |   Affinity Photo 1.7.1.404 (beta 1.7.2.424)   |   Affinity Publisher 1.7.1.404 (beta 1.7.2.422)
Affinity Designer for iPad 1.7.0.7   |   Affinity Photo for iPad 1.6.8.77

Windows 10 (1809) 64-bit - Core i7 - 16GB - Intel HD Graphics 4600 & NVIDIA GeForce GTX 960M
iPad pro 9.7" + Apple Pencil

Share this post


Link to post
Share on other sites

That thread has taken the last 2 hours of 2 members of staff, and we are still investigating the problem. not sure if it is an encoding problem byte order mark or what. With nothing positive to say we have not replied with a formal answer yet but it is on our radar.


Patrick Connor

Serif (Europe) Ltd.

Share this post


Link to post
Share on other sites
51 minutes ago, Patrick Connor said:

export as RTF would be better if not tables and images are involved.

It actually is possible to have tables and images in RTF files as well, though Publisher might not like them yet.

Share this post


Link to post
Share on other sites
4 hours ago, Phil Martin said:

Yes! Hard to work with the beta version and do a real evaluation when I cannot enter and use my WORD (.doc) files. Is there really a problem in implementing this?

You could open your file in Word and save in RTF format, which is supported. Alternatively you could open it in Word, select all, copy, and paste into a Text Frame in Publisher. RTF may be the better approach, for documents of any significant size.


-- Walt

Windows 10 Home, version 1903 (18362.145), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.1.404 and 1.7.2.424 Beta   / Affinity Designer 1.7.1.404 and 1.7.2.424 Beta  / Affinity Publisher 1.7.1.404 and 1.7.2.422 Beta

Share this post


Link to post
Share on other sites
3 hours ago, Patrick Connor said:

That thread has taken the last 2 hours of 2 members of staff, and we are still investigating the problem. not sure if it is an encoding problem byte order mark or what. With nothing positive to say we have not replied with a formal answer yet but it is on our radar.

Byte Order Mark is intended to help, not be a problem.

I don't know if it will help but a Unicode Text Document saved from WordPad has a Byte Order Mark at the start, and that, because of the file starting with FF then FE rather than FE then FF indicates that the bytes in that type of file has low order byte before high order byte for each sixteen-bit character.

That is because FFFE is not a valid character, so for the first character to be valid, as the first two bytes are FF then FE, the character must be a hexadecimal FEFF, so that is how the order of the two bytes for each character can be deduced automatically. The file is just a sequence of many (low order byte followed by a high order byte).

I have not seen any explicit reasoning for this order, but I suspect that it all goes back to the byte order in early Intel microprocessors where some instructions had 8 bits of data and some had 16 bits of data, those 16 bits being an address in the memory map.

I seem to remember that there is an anomaly in that some 16-bit files do not have a Byte Order Mark. This is to do with it being "known" (maybe +just by some people in relation to a particular file?) which format of byte order is being used.

The following might be helpful.

http://unicode.org/faq/utf_bom.html

Please note that I am not purporting to be an expert on this, it is just bits that I have picked up over the years.

William

 


Using a Lenovo ideapad 510 running Windows 10 in England

Share this post


Link to post
Share on other sites
19 minutes ago, William Overington said:

it is just bits that I have picked up over the years

You might get a byte for every dozen or so bits you have lying about.


MacBook Pro (13-inch, Mid 2012) Mac OS 10.12.6 || Mac Pro (Late 2013) Mac OS 10.14.5

Affinity Designer 1.7.1 | Affinity Photo 1.7.1 | Affinity Publisher 1.7.1 | Affinity Photo Beta 1.7.2.146 | Affinity Publisher Beta 1.7.2.422

Share this post


Link to post
Share on other sites
7 minutes ago, Old Bruce said:

You might get a byte for every dozen or so bits you have lying about.

I think he has reached at least a megabyte by now.

Share this post


Link to post
Share on other sites

Further to my previous post, when Affinity Publisher tries to read in the .rtf file, does it first check to see if the first two bytes are a Byte Order Mark?

If so, then if a Byte Order Mark is detected, there we go, but if a Byte Order Mark is not detected my hunch would be that the characters are in low byte then high byte order for each character.

I do not know about the internal structure of a .rtf file but I have just found the following

http://www.biblioscape.com/rtf15_spec.htm

and there is mention of a format variation.

> An RTF file consists of unformatted text, control words, control symbols, and groups. For ease of transport, a standard RTF file can consist of only 7-bit ASCII characters. (Converters that communicate with Microsoft Word for Windows or Microsoft Word for the Macintosh should expect 8-bit characters.) There is no set maximum line length for an RTF file.

So maybe that implies different "flavours" of .rtf and maybe there is a flavour that is not supported by Affinity Publisher at present.

William

 

 


Using a Lenovo ideapad 510 running Windows 10 in England

Share this post


Link to post
Share on other sites
1 hour ago, William Overington said:

So maybe that implies different "flavours" of .rtf and maybe there is a flavour that is not supported by Affinity Publisher at present.

William

Don't need .rtf these are 'some' of the available flavours from BBEdit which is plain text (my favourite) ...

991040801_Untitled2.thumb.jpeg.36044750c41a2b0a348bf0d8a9064bf2.jpeg


MacBook Pro (13-inch, Mid 2012) Mac OS 10.12.6 || Mac Pro (Late 2013) Mac OS 10.14.5

Affinity Designer 1.7.1 | Affinity Photo 1.7.1 | Affinity Publisher 1.7.1 | Affinity Photo Beta 1.7.2.146 | Affinity Publisher Beta 1.7.2.422

Share this post


Link to post
Share on other sites
2 hours ago, Old Bruce said:

You might get a byte for every dozen or so bits you have lying about.

When I first got started in IT, my job was to empty the bit bucket out in the computer room.  First thing in the morning and last thing at night, schleping out to the computer room and emptying that dang bit bucket.

Share this post


Link to post
Share on other sites
17 hours ago, Patrick Connor said:

It won't be available before anchored objects and inline images because a Word document is essentially always made of these.

Is it really necessary to support importing images within word files? Normal work flows tend to import text only (with full or limited styling, limited to bold/italic is best) and handle images separately from original image files.

I guess some jobs would benefit having both text and images imported from one source file, but generally images-within-word has been considered plain trouble. Possibly Publisher could handle this reliably?

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

×