Jump to content

Recommended Posts

I'm using the latest Publisher to format a novel, all text, no images. Anything over 20 pages, and everything slows down. I've struggled to page 120, and my novel is around 400 pages...

It now takes around five seconds to highlight a line or paragraph of text, and another ten to apply styles, and it's getting slower. Just about everything is now so slow as to make it unworkable. I need to finish this work this week, not sometime next year! Looking around on the web it seems I'm not the only one with speed issues. Turning off Baseline Grid (common advice) has no effect.

Applying text styles (for example) takes CPU usage to 98%. I can forget about changes to the Master Page, or turning on Baseline Grid -- either of those take forever.

I have Intel i5 2.9Ghz, 16Gb RAM. Would more RAM make a difference here?

I even reinstalled the software, with no effect. Feeling a bit desperate with Publisher now, after such an excellent start. Any advice?

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

Feeling a bit desperate with Publisher now, after such an excellent start. Any advice?

I doubt that more RAM would help.

How are you putting the text into Publisher?

I use plain text files and have no problems with applying styles. This is with several hundred pages, I did a few tests with the text from Moby Dick and a few Dickens novels from Gutenberg's public domain works.

How many fonts are you using in your novel, how many do you have on your machine, a few hundred fonts should be fine, a few thousand could slow things down.

The way I work is to import all the text and flow it through the document and then select all the text and apply a basic Paragraph Style then go and find the different headings and apply a heading to those using the find and replace function. I use approximately three paragraph styles for the text and two for headings plus one for page headers (name of the book) and one for the page numbers (in a page footer)

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

Affinity Designer 1.9.3 | Affinity Photo 1.9.3 | Affinity Publisher 1.9.3 | Beta versions as they appear.

Link to post
Share on other sites

Thank you again Bruce... I was importing from Word (.doc) converted to .docx, and it was not good. I saved it all as .txt and it's made such a difference.

I knew Word was not good to import (at least when it's been done without any styles & with lots of tabs, as mine was) but I'd written the book without thinking to self-publish -- so it could have been someone else's problem!

Hopefully I won't be a newbie for ever.

Link to post
Share on other sites

This might be entirely off-base and less than helpful. Publisher is not the tool I would use to write large text-based documents that are intended for publication. If you're serious, you might obtain any free version of LaTex that comes bundled with many relevant packages, e.g., Memoir, geometry, etc., which provide total control over dimensions and produce truly publication quality galleys in a variety of formats, such as PDF, PS.

LaTex is free; it runs on a variety of platforms, Windows, Macintosh and a variety of Linux distributions. In addition, many downloadable LaTex bundles are included in many standard downloads that  include some kind of editor, building software, such as TexShop, etc. In addition, dictionaries and hyphenation packages are also freely available, so if you're writing in French, German, etc., your document will obey the hyphenation and spacing rules for that language.

The "downside" is that you'll have to invest some time and effort learning LaTex. But, many online tutorials, such as https://www.latex-tutorial.com/, are available to help you.

Link to post
Share on other sites

Hello TomR55, and thanks for that.

Interesting. I was aware of LaTex, but thought it was just for academic/scientific documents and the like.

You say Publisher is not the tool for large text documents, and this is a surprise to me (and to many others, I would guess). I am very serious about this, and want my book formatted properly. The big appeal of software like Publisher (for me) is that once you've set up paragraph/text styles etc you see straight away what you've got, and you edit on the page, and if the rules are followed regarding input file types I can see how it's a great option for a non-expert.

I have a coding background so the plain text inputs of LaTex do not daunt me, but at this stage I'll stick with Publisher because it's working very well for me now (And I don't need a new learning curve!). I'm three-quarters through 400 pages, with just the barest occasional lag on some (usually global) functions... so unless things go downhill again all will be well. If they do, then I'm afraid I would use something else rather than risk starting again with Publisher. But so far so good. It's still early days for the program, and the potential is there to make it so much better. Roll on v2!

Link to post
Share on other sites
  • 4 weeks later...
  • 4 months later...

Extremely slow here too! When I paste into a text box, and then shift click on the flow triangle, It taks ten to twenty minutes for publisher to create the necessary 350 pages for the .txt unformatted text to be created. Then, when I change the master page (alignment and justification) these pages are assigned to, those changes don't propagate to the new pages my text was flowed into??? I read a comment above that says that Affinity Publisher isn't made for book sized documents? Could this be true? WTF? None of the copious ads and promotions for Publisher mention this rather ironic limitation given the name "Publisher". Please tell me I am doing something wrong and how to un-wrong it!

Thanks

Link to post
Share on other sites
13 hours ago, Randall Lee Reetz said:

Extremely slow here too! When I paste into a text box, and then shift click on the flow triangle, It taks ten to twenty minutes for publisher to create the necessary 350 pages for the .txt unformatted text to be created. Then, when I change the master page (alignment and justification) these pages are assigned to, those changes don't propagate to the new pages my text was flowed into??? I read a comment above that says that Affinity Publisher isn't made for book sized documents? Could this be true? WTF? Non of the copies ads and promotions for Publisher mention this rather ironic limitation given the name "Publisher". Please tell me I am doing something wrong and how to un-wrong it!

Thanks

I just did a quick test with the text for Moby Dick, that is about 200,000 words (a million characters +/-) and it took about a minute to propagate the 200 + pages. I did however Place the *.txt file, I didn't copy paste, but a quick test shows that it is about the same time for that. 

This may be down to my having 64 gb of memory versus whatever you have, it may be down to a difference in Mac vs Windows (you don't say), it may be down to oddball control characters hidden in the text that you copied.... there are many reasons for this difference in time. 

The changes to the Master Page not you mention not being picked up is different. How are you changing the alignment and justification on the master page? If you are expecting the change on the master page text frame to be picked up and override the formatted text on the pages then you are out of luck. Use Paragraph Styles.

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

Affinity Designer 1.9.3 | Affinity Photo 1.9.3 | Affinity Publisher 1.9.3 | Beta versions as they appear.

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

I did however Place the *.txt file, I didn't copy paste, but a quick test shows that it is about the same time for that. 

Maybe it would be interesting if the OP inserted its document (without loaded text), and you tried to insert Moby Dick - if it will be slower.

 

3 hours ago, Old Bruce said:

64 gb of memory

Since the amount of available RAM is absolutely crucial for the processing speed, this could be the deciding factor (64GB is already quite a lot).

Could you try to find out from the Mac Task Manager (?), how much memory APublisher will use when loading Moby Dick? This could provide interesting information about how much memory is needed, and if the user has less memory available, swapping to disk (which is a significant slowdown).

Affinity Store: Affinity Suite (ADe, APh, APu) 1.8.5.703.
Windows 10 Pro, Version 20H2, Build 19042.610.
Dell Latitude E5570, i5-6440HQ 2.60 GHz, 8 GB, Intel HD Graphics 530, 1920 x 1080.
Dell OptiPlex 7060, i5-8500 3.00 GHz, 16 GB, Intel UHD Graphics 630, Dell P2417H 1920 x 1080.
Intel NUC5PGYH, Pentium N3700 2.40 GHz, 8 GB, Intel HD Graphics, EIZO EV2456 1920 x 1200.

Link to post
Share on other sites
20 minutes ago, Pšenda said:

Could you try to find out from the Mac Task Manager (?), how much memory APublisher will use when loading Mobi Dick?

Using the Activity Monitor when making a new file I see Publisher using ~ 2.5 GB of RAM, placing or pasting the text I see Publisher using 3.5 GB of RAM. No Swap Used in any case. 

Could be that @Randall Lee Reetz has very little space on his Hard Drive for Swapping if RAM is the problem.

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

Affinity Designer 1.9.3 | Affinity Photo 1.9.3 | Affinity Publisher 1.9.3 | Beta versions as they appear.

Link to post
Share on other sites

I have previously tested long documents with Publisher on both operating systems and the results have been pretty disappointing.

I now reran my tests consisting of placing King James Bible as plain text (appr. 4,253,000 chars incl. spaces) but hard coded line breaks removed and replacing double line breaks with paragraph breaks, which makes about 1,600 A4 pages with default APub body text formatting. On Windows I used a system with 32GB RAM and i7 and on mac 8GB MacBook Air with M1 chip, and the latter outperformed the former  On Windows, the RAM was not even close to become exhausted, and as on macOS only 8GB was available (and I did not follow closely how much was used) I would say that at least with this task the amount of RAM was not that crucial. On the other hand, on my earlier tests Affinity apps have always hogged all RAM that is available and still behaved inefficiently. Something seems to have changed now, and I assume coarsest memory leaks having become fixed.

Some things have certainly improved compared to my earlier tests. On macOS I could e.g. rearrange the non-master based layout that originally constisted of about 3,600 pages of line-break hard coded text with a master-page based layout first making the text regularly flowing and then copy pasting the whole text into master-page controlled flow pretty smoothly. On WIndows the same operation halted at the time I tried to reflow the text from the Clipboard into master page controlled frames. Re-trying in two stages made it work on the Windows machine, as well.

Afterwards it was more or less smooth on both machines to add or remove single pages, format text (e.g. body text style), add images amidst the body text, etc. On the other hand, just removing the about 2,000 empty pages after the initial change of replacing hard coded paragraph breaks with spaces took minutes on both computers. Changing the text frame widths on the master page and having the change applied took several minutes on both computers. 

Even if there were clear improvements compared to previous tests (done probably about a year ago), the general feel was still a bit clunky and at times sluggish compared to InDesign and QuarkXPress. Certain things happened really fast, like flowing the initial 3,600 page hard coded formatted text into non-master-based text frames, but there were odd processing pauses where pretty much every operation (like simply browsing the pages) got unresponsive for a while. Previously it was a real pain to add any text amidst a long text flow but now there were no problems with additions and removals.

My general feel was that I still would not want to use Publisher for creating long texts especially with complex formatting and image content, as I would be afraid of the layout to become unresponsive or corrupt at some point after possibly weeks or months of editing. But this is just a gut feeling based on more or less random tests and not on real experience. But experiencing once again a complete halt (on a single test even if one consisting of very long single story, and even if only on Windows this time) does not encourage to take a risk -- though admittedly much because tools that have never failed for decades neither with short or long and complex documents are still available for me. But there are posts on this forum describing problems with long texts on both platforms even when using recent versions of Publisher. Splitting the job into multiple documents might help, but if a common TOC and especially index needs to be created, this does not necessarily resolve fundamental technical problems there still seems to exist in the app when processing long texts.

Link to post
Share on other sites

I've 180 GB available disc space. 8 GB memory. I'm importing .txt file of Darwin's Origin of Species. Not that big a file. Plain text. When I import into other apps, on the same Mac, no performance problems at all. What is going on with Affinity Publisher? I remember this kind of performance hit back in the late 1980's with Quark. It's maddening. Seems amateurish.

Link to post
Share on other sites

Oh dear, seems I'm not alone. Since I began this thread I have formatted my 400-page novel to my satisfaction, but I would not attempt the same again with Affinity Publisher as it stands at present.

Although beginning with the correct file type (.txt) made a big difference, the later stages were scary to say the least, with the fear of losing my hard work or at least having to deal with peculiar changes I did not ask for. Slowdowns and freezes were the order of the day, and simply to insert/delete pages from the middle of the document was a traumatic experience. Long waits for changes to be updated (with 'not responding' in the top bar), and often having to restart the program to get things moving again. And as for having two longish documents open at the same time and swapping between them... forget it (a split-screen feature would be so nice).

I have always used the latest version, currently 1.9.2.1035.

I have an i5  2.9GHz processor with 16Gb RAM, and loads of SSD storage. I should not have to upgrade my system just to format 400 pages of text-only content. So I wait for Affinity Publisher to be able to painlessly do what its name promises -- publish a simple, longish, text document.

Link to post
Share on other sites

If I were designing a data model for a pre-publish layout tool, I'd make sure that edits resulted in concurrent background idle processing so that the user was only rarely aware of the processing hit caused by their edits. An edit on page 10 of a 1000 page document does indeed result in an unavoidable cascade of formatting transformations throughout the rest of the document (if there are no page breaks thereafter). I'd encourage or demand page breaks on large documents if my edit cascade algorithms were slow or cumbersome to the user. I'd sell the advantage of automated algorithmic pre-press layouts over manual drag and drop layouts for larger (more than 10 or 20 pages of flowing content) documents. I would work to establish easy to translate and use freely published API's and API standards so that content software like word processors and manuscript creation applications could export layout specific metadata in a format that my layout software could automate from.

Link to post
Share on other sites

As an interface designer, I appreciate the emphasis Serif places on the design of its product's front ends. But something is lacking under the hood, some crucial aspects of software production have been ignored. Yes there are always limited resources available for any software production process, but I would suggest that the smartest person in the room has always to be the data architect. Something messy has happened at this most fundamental level and its such a shame with so bright and shiny a suite of products. Is there hope? its hard (expensive and complicated) to fix software architecture when the architecture that needs fixing is at a foundational strata. When I've been in position to drive hiring decisions, I've always recommended that management pay for the very best, very most expensive backend developers and software development project managers with an unblemished record of success simplifying complex software. Also, there is a huge difference between an aesthetically clean interface (as Serif is good at producing) and a truly useful application (which often produces interface-free or at least, interface-reduced applications). I find that people who copy existing software are people who tend to concentrate on clean looking interfaces, and seem unwilling or unable to reimagine software from a user-end-goal perspective. A better piano is not what a music listener wants. A music listener wants a voice activated recorded music player. A better piano is not what a music composer wants. A music composer wants a tool that iteratively produces music at the rate that their brain imagines/experiences it. Music composition software often presents a keyboard instead. Music composition software mimics often tout the advantages of their particular version of the on-screen piano. Some of these improvements are truly innovative, but even so, miss the point completely. Worse still, the better piano often perpetuates the idea that the piano is the best affordance for music composition. Why re-invent the wheel when the goal, getting from point A to point B, is only associated with wheeled automobiles by historical consequence. I have purchased the entire suite of Serif applications. I have done so because the price point is so comparatively reasonable. But sometimes low cost is more of an attractive nuisance than an advantage.

Link to post
Share on other sites

I too have performance issues on a fully specced out 2019 16" MacBook Pro (8-core i9, 32 GB, M5500 8 GB graphics) and very small documents. 20 pages and there's already stuttering and a delay of half a second for every second command or so. 

In this state, Affinity Publisher is really no alternative to any other publishing tool right now, which is so disappointing. I was ready to make the switch from Adobe because they have their own host of problems. But looking at this mess, they seem to be the lesser evil right now. 

Link to post
Share on other sites

I had another look on this Bible text test project, that in current state is about 1,600 - 2,200 page publication of regularly flowing (no forced line breaks as in the original txt file). As the mac version (on low-end M1 computer) performed better, I concentrated now on the Windows version (run on i7 computer with 32GB RAM), and did tasks like changed the column widths on the master page, changed alignment to fully justified, assigned language and hyphenation for the text, switched font, point sizes and styling of text selections (1 page large or so), detached text frames from the master on individual pages to make room for images, etc., and noticed the following:

1) The first time the column width e.g. of the right pages was changed, it took several minutes (did not take time but I'd say nearly 10 minutes) to do the task, the Task Manager showing the status of Publisher.exe process being non-responsive. The CPU meters however were generally at low level and showing high-percentage activity only for a couple of 8 logical processors.

2) After this task was performed once (making the column 120mm wide from the initial width of 160mm), and having re-flown the text and generated new pages, redoing the same kind of task (making the column width 10 mm wider, reverting the original column width, making it 110mm wide, etc.), took only some 10 to 30 seconds processing time, and typically with the following kind of CPU processing profile:

cpu_usage_01.jpg.0219eb6a2543a76ab1ace167ffda7880.jpg

While it would of course be ideal to not have non-responsive status at all, considering the length of the text and relatively short time the task took to become accomplished and the process becoming responsieve again, I think this is just fine.

3) For the rest of the tasks mentioned above (e.g. making all body text fully justified, assigning the language and turning on hyphenation), it took only about 10 seconds to have new formatting applied for the whole text, and the CPU processing profile stayed responsive all the time, and all logical processors in effective use:

cpu_usage_02.jpg.96636824d8b296b00dd562f1dcc12d41.jpg 

4) I could see that processing continued often in the background, Publisher staying fully responsive e.g. for browsing the pages, selecting and formatting text passages; slight sluggishness might appear but not anything disturbing. After a while, the CPU profiles showed regular idleness as could be expected:

cpu_usage_03.jpg.d8414351ada8637883d2bf652696df09.jpg 

It should be noted, too, that when Publisher was quit and re-launched, and the width of a column on the master page was changed yet to another value (not previously used), processing stayed effective and responsive, so there was no longer the mentioned "initial lag". 

On hindsight it is possible that what I interpreted as a permanent app halt (crash) on Windows in my initial test was "premature" and the task might have become finished and the app have returned responsive after letting it process the task a few minutes more. If so (as this is what happened on this second test with the same document), and considering the smoothness in processing the rest of the tasks, it definitely seems that some improvement has happened. Perhaps the initial lag can be explained by the long text becoming slowly (in the background, or "on demand" when related tasks are performed) structured in a way that makes subsequent processing smoother. Anyway: I did not experience at all similar problems as about a year ago, when e.g. adding even a single character in the middle of existing text flow (consisting of paragraphs after another without any forced page breaks or white space leeway), appeared to push each and every subsequent character one step forward -- unacceptably sluggish and horrible. On the other hand, other users seem to have experienced this kind of sluggishness with long texts even when using recent versions, and also on macOS... So perhaps some specific feature or factor is triggering this behavior. But I experienced it with this same text about a year ago (on both platforms) and now cannot reproduce it (with this text) on either platform.

On a general note when performing the above mentioned tasks the memory usage stayed steady (no longer RAM hogging, and only about half of the available RAM was in use) and processing seemed effective. Why there was this initial ineffectiveness (minutes of processing in non-responsive state and logical processors showing low usage), is a mystery. With an M1 chip on Big Sur 11.2.3 the initial non-responsive state did not last as long as on Windows (where an older 4-core i7 processor was used), but based on reports by other users, seems to be similar on Intel-based macs. But as mentioned, the amount of RAM did not appear to have a noticeable impact on efficiency of processing the described tasks (which is normal: 8GB should be enough -- and is enough e.g. In InDesign -- to handle these kinds of tasks without any problems). 

It is of course important that these kinds of long, non-responsive states can be removed, as they are likely to become interpreted as app crashes and accordingly forced to quit (which can result in permanent document corruption). Considering the improvement that has clearly happened, I am however still hopeful and believe that these errors will sooner or later become fixed. Having tested this test document now more thoroughly, I think I could live with this defect -- but one test is of course not enough to see if "just letting Publisher do its job" is enough to avoid data loss and publications becoming corrupt, and making subsequent editing tasks smooth, or if similar lags are experienced when performing other kinds of heavy tasks, like importing hundreds of images, embedding inline elements, doing pinning, splitting stories into hundreds of connected frames, etc., or when Publisher is run in heavily multitasking environment where processing time needs to be shared with other simultaneously running tasks. 

Link to post
Share on other sites

Another important question is of course whether subsequent edits, e.g. addition of images, re-organizing of the document structure, etc. cross editing between the other apps (possibly including opening and editing the document with other apps and then opening and saving yet again in Publisher), that is, tasks that typically make the filesize of the document very large, could be factors that cause sluggishness at later stages of document handling, and possibly something that cannot be fixed (by means other than re-creating one way or another the whole document).

Link to post
Share on other sites
13 hours ago, Randall Lee Reetz said:

Perhaps Serif needs to be reasonable here and to warn potential customers not to purchase if they intend to build small documents? How about: 

"Affinity Publisher is a pre-publish layout tool designed for manually laying out small documents (of less than 10 to 20 pages)."

Trial version?
After all, it goes without saying that each user, before buying a product, finds out and tests whether it meets exactly his expectations.

 

13 hours ago, Randall Lee Reetz said:

less than 10 to 20 pages

Hmm, interesting that someone is able to process 100x larger documents.

1 hour ago, Lagarto said:

I had another look on this Bible text test project, that in current state is about 1,600 - 2,200 page publication

 

Affinity Store: Affinity Suite (ADe, APh, APu) 1.8.5.703.
Windows 10 Pro, Version 20H2, Build 19042.610.
Dell Latitude E5570, i5-6440HQ 2.60 GHz, 8 GB, Intel HD Graphics 530, 1920 x 1080.
Dell OptiPlex 7060, i5-8500 3.00 GHz, 16 GB, Intel UHD Graphics 630, Dell P2417H 1920 x 1080.
Intel NUC5PGYH, Pentium N3700 2.40 GHz, 8 GB, Intel HD Graphics, EIZO EV2456 1920 x 1200.

Link to post
Share on other sites

Pšenda: "After all, it goes without saying that each user, before buying a product, finds out and tests whether it meets exactly his expectations."

Yes, I did try the program, but not with the full 400 pages. I was also swayed (foolishly?) by the lavish and flashy website portrayal of what was a publishing program. And the price, of course, was right. To see that it 'met exactly my expectations' would have meant me formatting the entire thing in the trial version, but, being impressed at that point, I bought the full version. That was a mistake, apparently!

I wrote the novel in an old version of MS Word, and had no problems with file size, so why can't Affinity Publisher match the formatting ease-of-use of the 2003 version of Word (or am I missing something obvious here)? Of course Publisher offers much more scope for fine tuning of formatting, which is why I bought it, but if it's that extended scope that causes the problems then all I can say is -- "needs more work".

 

 

Link to post
Share on other sites

In a totally unscientific test, I just placed a plain .txt file of the Bible (King James Version) into an Affinity Publisher 1.9.2 document (macOS 11.2, 2018 MacBook Pro with 32Gb RAM and a 2.9GHz 6-core Intel Core i9 processor).

With the font set to 8.5pt American Typewriter this made 462 pages of A4, three columns per frame, one continuous flow of text.

I then ran a search and replace to set the character style of the chapter and verse numbers to 'Strong'.

100149168_Screenshot2021-04-09at14_13_31.png.30ea8d22b2eb92e90a861f9ed6c9b56a.png

Four seconds. Your mileage may vary...

 

Affinity Photo 1.9.2,  Affinity Designer 1.9.2, Affinity Publisher 1.9.2, Mac OSX 11.2, 2018 MacBook Pro 15"

Betas as they happen... 

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

Yes, I did try the program, but not with the full 400 pages. I was also swayed (foolishly?) by the lavish and flashy website portrayal of what was a publishing program. And the price, of course, was right. To see that it 'met exactly my expectations' would have meant me formatting the entire thing in the trial version, but, being impressed at that point, I bought the full version. That was a mistake, apparently!

But then I think that with the mentioned "impressed" you wouldn't notice any of the text/warnings somewhere on the web you suggested anyway.
However, as can be seen, many users have completely different experiences with the functionality of APublisher.

Affinity Store: Affinity Suite (ADe, APh, APu) 1.8.5.703.
Windows 10 Pro, Version 20H2, Build 19042.610.
Dell Latitude E5570, i5-6440HQ 2.60 GHz, 8 GB, Intel HD Graphics 530, 1920 x 1080.
Dell OptiPlex 7060, i5-8500 3.00 GHz, 16 GB, Intel UHD Graphics 630, Dell P2417H 1920 x 1080.
Intel NUC5PGYH, Pentium N3700 2.40 GHz, 8 GB, Intel HD Graphics, EIZO EV2456 1920 x 1200.

Link to post
Share on other sites
2 hours ago, Pšenda said:

However, as can be seen, many users have completely different experiences with the functionality of APublisher.

Which probably cannot be fully explained simply by differences in RAM, CPU, GPU, OS version, et al. 

Affinity Photo 1.9.3, Affinity Designer 1.9.3, Affinity Publisher 1.9.3;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.92.236 & Affinity Designer 1.9.2 (showing 1.9.9) for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 14.4 (18D52)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.