Jump to content

Composition Speed


jurgmay

Recommended Posts

Hi all,

 

I have a query and wonder if people are getting similar results...

 

We have a job coming up in the next few weeks which require 40,000 records to be overprinted onto pre-printed paper. The data is simply name and address plus a unique ID number. There are no JavaScript rules, no resources being used and no background image on the PDF. All we have is a blank PDF with a few FP boxes drawn with fields imported.

 

I've just run a test on the first 2,000 records using the data from the last time we ran this job and it took an average of 160 records per minute. This will take over 4 hours to process.

 

What I'm struggling to understand is how Microsoft Word, on the same PC, can process the entire 40,000 records is just 5 minutes. To me this doesn't make too much sense.

 

I'm looking to overhaul our systems to ensure that we run a PDF based workflow and therefore would like to use FusionPro to do the composition of variable data jobs but it's incredibly hard to justify on the back of results like this... :(

 

I'm guessing that the cost of FP Direct or FP Server is going to be far more than I can justify, though I'm waiting to hear back on that.

 

Really what I'd like to know is whether people are getting similar composition speeds to what I described above - 160 records per minute.

 

The PC I'm using is an HP, 2.4Ghz, 2Gb RAM.

 

Any feedback appreciated.

 

Thanks,

 

Juerg

Link to comment
Share on other sites

Hello Juerg,

The answer to why a job takes a certain amount of time to compose is, it

depends. There are a lot of factors that go into determining how long

it takes to compose a record of data. Some of the main ones are: the

number of pages and frames in your job, the number and size of external

resources (graphics), the location of external resources (local vs. from

a network), the number and complexity of JavaScript rules (especially

things like text measurement or copyfitting which make multiple passes),

the output format, use of output chunking or imposition, and the

capabilities of your computer, including CPU speed, memory, and disk

space. Also, if you're currently using FusionPro Desktop, you may see

better composition times from FusionPro Server for certain jobs.

 

Analyzing why your particular job seems to take a long time to compose

would require looking at it, which I can't really do in the context of

the forum. It's possible that there are things which could be done to

make it more efficient. If you're utilizing the Page Usage feature,

you're composing every page for each record, whether you're using it in

the output or not, so you might be able to optimize the job by putting

the variable info onto a single page and only composing the parts you're

using. Also, if you're using barcodes, you might be able to minimize

the number of times you're calculating the barcode data, especially if

you're encoding the same data multiple times. But again, a full

analysis and optimization of the job is beyond the scope of this forum.

 

As to the relative composition speed of FusionPro versus other VDP

products as well as Mircrosoft Word, I don't know how all those other products work, especially for generating variable data, so I can't really speak to that, although I don't know if they have the same capabilities and features of our program.

 

Hope this information helps.

Link to comment
Share on other sites

Hi Alex,

 

Thanks for your reply.

 

As I mentioned in my post, the job in question is simply two FP frames. One with name and address fields (five in total) and one containing an ID field. There are no rules, calculations, resources, page usage, JavaScript or anything else being used - it's just 6 fields inserted into an entirely blank PDF. The only things to process are the address and ID data, no images, no additional text data. I can't envisage many real-life examples that could possibly be simpler than this...

 

I must admit that I'm a little frustrated that you don't seem to have read my post at all and seem to have posted a stock reply, variations of which I've seen on this forum when similar questions have been raised. I quite agree with all your comments but they simply don't relate to what I posted?!

 

I'm not sure whether any of this leaves me more or less frustrated than I was before but thanks for your input anyway.

 

Regards,

 

Juerg

Link to comment
Share on other sites

Hi Juerg,

 

I've wondered about the speed difference between word and fusionpro desktop too when doing just an address block. We still use word for many documents that we can because of it. I did 2 tests to give you another speed comparison. I have a pretty complex job in that it has an external data file with several javascript rules. It was coming out at about 160 per minute. I then removed all but 2 of the text frames on the two pages and all of the rules. It composed at about 500 per minutes. My PC specs should be in my signature. This was actually run on the "c" version of FusionPro 7.0 but the speeds of prior versions weren't much faster.

Link to comment
Share on other sites

Hi Brad,

 

Thanks for you reply, that's very interesting. I've tried on various PCs in the building and they all average around the 160 mark, even though it's a basic job but you seem to be seeing results much better than this.

 

I wonder whether the version of Acrobat makes a difference as I'm only on version 7. I'm also running FP 7.0c, though only a demo version but I get identical results on 6.2.

 

I find it bizarre that people are resorting to Word for mail merging address data when software as powerful as FP should seemingly be superior. Printable always seem very defensive when this subject is raised (search the forums) and indeed I even had a private, off forum message from them. Quite why they won't talk openly I don't know...

Link to comment
Share on other sites

I find it bizarre that people are resorting to Word for mail merging address data when software as powerful as FP should seemingly be superior.

While Word may be a claw hammer to FP's pneumatic nail gun comparison, the fact of the matter is that one should always choose the right tool for the job. I don't necessarily agree that the more powerful tool should always be the "go to" tool. ;)

Link to comment
Share on other sites

While Word may be a claw hammer to FP's pneumatic nail gun comparison, the fact of the matter is that one should always choose the right tool for the job. I don't necessarily agree that the more powerful tool should always be the "go to" tool. ;)

 

I agree to a certain extent but would you REALLY merge 40,000 records in Word? Our requirement is that it needs to be chunked in 500s so to do this in Word is pretty much a manual process with the operator having to ensure they merge the correct record range and name the file correctly. To me, FP is the best tool for the job - perhaps just not the quickest...

 

I can live with the speed thing (or lack of in my case!) - I just wanted feedback from other users to see if 160 records per minute is par for the course.

Link to comment
Share on other sites

Just did my own experiment. My document (no rules, usage, etc.) had three FP boxes: name & address, IMB, sequence number. We have FP Direct so I composed using that, as well as locally. Locally, I saw about 250 records per minute. With FP Direct it was 3,000 records per minute.
Link to comment
Share on other sites

Just did my own experiment. My document (no rules, usage, etc.) had three FP boxes: name & address, IMB, sequence number. We have FP Direct so I composed using that, as well as locally. Locally, I saw about 250 records per minute. With FP Direct it was 3,000 records per minute.

 

Wow, that's an incredible difference! I didn't expect Direct to be THAT much faster... Thanks so much for the info.

 

I've had pricing on FP Direct and for that level of performance it suddenly looks a much more attractive proposition.

 

Thanks again,

 

Juerg

Link to comment
Share on other sites

Glad to help. The other nice thing about Direct is that it frees up your computer because the composing is transferred to the server. I'm not sure what the specs on our server are (I'm sure that's a factor), but could find out if that would help. Just let me know...
Link to comment
Share on other sites

Glad to help. The other nice thing about Direct is that it frees up your computer because the composing is transferred to the server.

 

I get in about 15 jobs all in one week that repeats every month. There is no way I could get those jobs done in a timely manner without Direct. If you are a bigger print shop, Direct should be bought to handle multiple small jobs and the big jobs.

Link to comment
Share on other sites

Glad to help. The other nice thing about Direct is that it frees up your computer because the composing is transferred to the server. I'm not sure what the specs on our server are (I'm sure that's a factor), but could find out if that would help. Just let me know...

 

Yes, I'd be interested to know the specs if that's possible. Thanks.

Link to comment
Share on other sites

  • 1 year later...

I hate to beat a dead horse with this speed question, but it seems there is potentially some problem with my particular setup where there simply is no way to have FusionPro Desktop compose faster.

 

Our particular usage pattern here consists of infrequent jobs with a moderate number of records -- pretty much the sweet spot for Desktop. So as an example we run a job maybe once every 2-3 weeks with between 10,000 and 20,000 records. The composition is fairly simple. Two graphics substitutions, three text boxes, and an address box across two pages composing to PPML with Acrobat X. No javascript or complicated rules. Resources are all optimized/small and on local disk. With this particular job, composition speed is approximately 100 records/minute.

 

Here's the thing: The workstation running the composition has 12 cores, 24 gigs of ram, and SSD storage (It is a GIS workstation, but happens to be the fastest thing we can throw at FusionPro.) Monitoring the acrobat processs during composition has it running at ~1% CPU utalization and about 50 IOPS. Where is the bottleneck?

 

I have tried starting new instances of acrobat (Start -> Run -> "acrobat /n") and composed the same job with different data at the same time. I have tested this with 20 instances of acrobat composing simultaneously and have observed no obvious decrease in the 100 records/minute/instance. That is an effective rate of 2000 records/minute and I suspect the machine is capable of much more as it is still not appearing to be bottlenecked on CPU or disk.

 

Because of the size and frequency of our jobs it's really not cost effective to move up to fusion pro server, but I'm really not understanding why we can't seem to make Desktop go any faster.

 

I ran a completely blank composition to test the "penultimate" performance - one blank page, no variable data whatsoever. I did achieve approximately 1000 records/minute doing this basic test; again CPU sitting below 1% on the acrobat process and minimal disk activity. Running a second and third copy of the composition in parallel resulted in no reduction in speed per instance. Composing to different formats doesn't seem to affect my results much either.

 

So, what gives? I'd like to think that I am missing something obvious.

Link to comment
Share on other sites

I hate to beat a dead horse with this speed question, but it seems there is potentially some problem with my particular setup where there simply is no way to have FusionPro Desktop compose faster.

 

Our particular usage pattern here consists of infrequent jobs with a moderate number of records -- pretty much the sweet spot for Desktop. So as an example we run a job maybe once every 2-3 weeks with between 10,000 and 20,000 records. The composition is fairly simple. Two graphics substitutions, three text boxes, and an address box across two pages composing to PPML with Acrobat X. No javascript or complicated rules. Resources are all optimized/small and on local disk. With this particular job, composition speed is approximately 100 records/minute.

 

Here's the thing: The workstation running the composition has 12 cores, 24 gigs of ram, and SSD storage (It is a GIS workstation, but happens to be the fastest thing we can throw at FusionPro.) Monitoring the acrobat processs during composition has it running at ~1% CPU utalization and about 50 IOPS. Where is the bottleneck?

 

I have tried starting new instances of acrobat (Start -> Run -> "acrobat /n") and composed the same job with different data at the same time. I have tested this with 20 instances of acrobat composing simultaneously and have observed no obvious decrease in the 100 records/minute/instance. That is an effective rate of 2000 records/minute and I suspect the machine is capable of much more as it is still not appearing to be bottlenecked on CPU or disk.

 

Because of the size and frequency of our jobs it's really not cost effective to move up to fusion pro server, but I'm really not understanding why we can't seem to make Desktop go any faster.

 

I ran a completely blank composition to test the "penultimate" performance - one blank page, no variable data whatsoever. I did achieve approximately 1000 records/minute doing this basic test; again CPU sitting below 1% on the acrobat process and minimal disk activity. Running a second and third copy of the composition in parallel resulted in no reduction in speed per instance. Composing to different formats doesn't seem to affect my results much either.

 

So, what gives? I'd like to think that I am missing something obvious.

100 or so records per minute sounds about right for FP Desktop, which is primarily intended as a design tool, not as a high-volume batch composition engine. If you really need to compose faster than that, then you need FP Direct or FP Server. The exact location of the "bottleneck" in FP Desktop is inconsequential; that's just the way we sell the product. If FP Server is too expensive for you, you should take a look at FP Direct.

Link to comment
Share on other sites

100 or so records per minute sounds about right for FP Desktop, which is primarily intended as a design tool, not as a high-volume batch composition engine. If you really need to compose faster than that, then you need FP Direct or FP Server. The exact location of the "bottleneck" in FP Desktop is inconsequential; that's just the way we sell the product. If FP Server is too expensive for you, you should take a look at FP Direct.

 

This is the closest I've seen any PTI employee come to actually admitting that there is an in-built speed restriction in the software.

 

The real problem is that I don't think ANY of your customers would tell you that they buy your software for it's 'design' capabilities and I don't really see that this is how you promote your product. Please take the time to read your own website and tell me honestly that you disagree with me.

 

http://www.pti.com/FusionProDesktop/

 

What you believe the product to be and how PTI promote it are two seemingly different things.

 

It seems to me that people buy the product for the VDP and business logic functions of the software and the way the product is advertised gives the impression of something superior to variable data publishing through Word or InDesign so they get annoyed and frustrated by the 'upgrade to Direct or Server' mantra when they realise they're getting a woeful 100 records per minute on the most basic projects.

Link to comment
Share on other sites

Well I am saddened to read this response, but I suppose I suspected as much. I wish PTI was more honest about this and/or set MUCH more reasonable rates. I have wasted hours waiting on a job only to find that I had forgotten to set bleed or had a last minute change.

 

In our case, any server based product (Direct or Server) is severely overcomplicating a simple problem, regardless of what it might cost. But speaking to the the cost, if we were a print-for-pay doing VDP all day for customers and it might be different, but we are just a business sending postcards to our customers. It would take quite a while to justify the additional expense just to save a couple hours a week.

 

So I guess all I can really do at this point is express my extreme disappointment and hope that this this policy is changed at some point.

Link to comment
Share on other sites

This is the closest I've seen any PTI employee come to actually admitting that there is an in-built speed restriction in the software.

 

The real problem is that I don't think ANY of your customers would tell you that they buy your software for it's 'design' capabilities and I don't really see that this is how you promote your product. Please take the time to read your own website and tell me honestly that you disagree with me.

 

I disagree.

 

Take a look at a competitor, XMPie. You have your local InDesign doc. that you "could" proof from and then package up to the server to run it. If XMPie is the same in terms of work-flow, then I actually like the way FP does the "packaging-up" for you, plus you don't have to log-in on the job again to run on the web-server interface.

 

We run A LOT of small jobs and big jobs at the shop I'm at and most of the time I keep my workflow to just running on the SERVER only.

 

I don't see anything that is "miss-leading" to potential customers from Printable. Seeing the composing speed of some of our most complex variable data jobs run on Direct from FusionPro pays for itself in TIME.

Link to comment
Share on other sites

I disagree.

 

Take a look at a competitor, XMPie. You have your local InDesign doc. that you "could" proof from and then package up to the server to run it. If XMPie is the same in terms of work-flow, then I actually like the way FP does the "packaging-up" for you, plus you don't have to log-in on the job again to run on the web-server interface.

 

We run A LOT of small jobs and big jobs at the shop I'm at and most of the time I keep my workflow to just running on the SERVER only.

 

I don't see anything that is "miss-leading" to potential customers from Printable. Seeing the composing speed of some of our most complex variable data jobs run on Direct from FusionPro pays for itself in TIME.

 

I'm not sure that we're talking about the same thing here. You seem to be talking about Direct or Server - I'm talking about Desktop. Plus I don't see what any of your remarks have got to do with 'design'.

 

The point is that composition speeds in Desktop are painfully slow and the mantra from PTI is 'upgrade to Direct or Server'. I'm not saying there isn't a benefit to the upgrade, just that it could be made clearer. In not so many words, Dan has stated that there is a deliberate bottleneck programmed into to Desktop to limit the composition speed and I don't feel it's clear what the differences are between Desktop, Direct and Server. If people knew in advance that Desktop has a composition speed of 100 records a minute they wouldn't have sold so many.

 

As it happens I love FusionPro and can happily live with composing 10K+ records overnight - I just wish someone from PTI would come out and say what a lot of us have suspected for a long time and save everyone the aggravation of trying to work out why the hell we can't make the composition times faster. Previous responses to this subject have suggested hardware configurations should be looked at (RAM, processor speed etc) when all along they knew damn well that it wouldn't make a difference.

 

Yes, I'm annoyed by it. Just tell us the facts and be done with it.

Link to comment
Share on other sites

I'm not sure that we're talking about the same thing here. You seem to be talking about Direct or Server - I'm talking about Desktop. Plus I don't see what any of your remarks have got to do with 'design'.

 

What are the limits to design?

 

Desktop runs $800.00 for 7.2. I wouldn't expect this to be powerful composition print engine at this price, by no means.

 

Here is a breakdown of their products.

http://www.pti.com/FusionProVDP/

 

Understanding what you will need to handle HIGH-VOLUME variable data campaigns or multiple campaigns at once involves probably the following individuals:

-ART/Prep department Manager

-Programmer(if any)

-Data/Postage dept(if any)

-Individual that puts it all together.

 

Getting with a FusionPro sales rep with your concerns in the beginning would also probably cleared-up any confusion and educate on the type of products your shop "should" be purchasing.

 

 

Now if you paid thousands for Desktop and were told by the company via-email or webinar that this thing was meant to do Ten's of Thousands of records per hour locally, then yes, I would be pissed also.

Link to comment
Share on other sites

Please allow me to clarify a few things:

 

  1. FusionPro Desktop has no "in-built speed restriction" or intentional bottleneck. I never said that. FP Desktop happens to compose more slowly than FP Direct and FP Server for several architectural reasons. Without getting too deeply into the technical details, I can tell you that one reason is that FP Desktop is a plug-in to Acrobat, which brings along several restrictions. Another is that it's a GUI, and it takes resources simply to update the Composition Status dialog and check for the Cancel button, among other things. Absent these architectural factors, FP Direct and Server are able to run more quickly. There are a few additional optimizations which are specific to FP Server, due to its nature as a batch processing engine, but those are not relevant to FP Desktop.
  2. I don't believe that our website or any of our other marketing materials make any specific claims as to composition speed, for any flavor of FusionPro.
  3. Yes, we do charge more for our enterprise-level solutions than for FusionPro Desktop. We believe, and many FP Direct and Server customers agree, that there is a large enough value-add for those products over FP Desktop to make the price difference worthwhile. You get a lot more than just faster compositions, especially with FP Server, which allows you full programmatic control over all aspects of the job, including the layout and all composition settings, as well as hooks into more advanced workflows and other features.
  4. FP Direct is targeted to customers who need to run larger jobs than are normally run in FP Desktop, but not as part of an automated system which would require FP Server. It also allows you to free up Acrobat and your system for design or other tasks while composing jobs. Many customers consider this to be an ideal solution for needs similar to the ones expressed in this thread.
  5. Likewise, thousands of FusionPro Desktop customers consider $800 to be a bargain for a fully-functional VDP composition engine, even though it doesn't have the same speed as our enterprise-level tools for larger jobs.
  6. Hardware configurations do make a difference in composition speed, though more so for FP Server and Direct than for FP Desktop, due to the aforementioned architectural restrictions. However, as I've said before, different jobs have different requirements. For many jobs, the composition speed is IO-bound, that is, it spends a lot of time reading and writing files to disk. For other jobs, it's memory-bound, particularly when large graphics are involved. It's rarely CPU-bound, but faster processors will still help. It's difficult to come up with exact metrics for composition speed because of all the variables involved, both with jobs and with machines and configurations. That's why, as I noted, we don't advertise any particular speeds.
  7. We have made many improvements to FusionPro's composition speed over the years, including in FP Desktop. But someone always wants it to run faster, so we keep working to improve it.
  8. I'm an engineer and have no say in pricing. Feel free to contact Sales for more information about that.

Link to comment
Share on other sites

Woah there rpaterick; no need to get hostile. You and I have very different needs and expectations. I'm not a print shop trying to cheap out by running hundreds of jobs on Desktop. I work for a small company running some basic direct mail campaigns from in-house.

 

I did speak with PTI sales. I was inclined to believe that Desktop would be suitable for the jobs we are running. At no point until today has anyone from PTI ever indicate that the composition speed of Desktop may be artificially limited. I had to figure that out on my own. Sales agreed with my assessment of needs, but at no time did anyone tell me that it would take several hours to compose my job while my workstation sits 99% idle.

 

In answer to your question, yes absolutely for $800/license (we have a few seats) I expected more. The difference between desktop and direct/server were explained to me as a workflow and volume decision. I don't consider running one job every few weeks to be significant volume. 10k records is simply not a huge number at this frequency. I don't need or want a server based solution to do this sort of thing; I don't have people running VDP jobs day in and day out. Acrobat Pro itself only costs about $250; do you think it's a powerful prepress tool? Would you be happy if it could only process 100 PDF pages per minute? How about any of the other software you own? There are plenty of situations where companies differentiate products by essentially producing one product and crippling the lower end sku (CPUs, Printers, Microsoft Windows) but the difference is these limits are fully disclosed and the customer has the ability to make a fully informed decision.

 

I started investigating, searched the forums and finally posted about this speed issue because I honestly thought something was wrong with my software, configuration, or job setup. I did not expect or want any of this insanity. Registering for the forums was a nightmare. My work and personal email addresses were both somehow on "banned" domains. My posts have to "await moderation." I'll honestly be surprised if this one even makes it up. If this is the way PTI operates and this is the way the community around this software behaves you can all have it --

 

Update -- Saw Dan's post while I was typing:

 

My system is not bottlenecked on memory or disk IO, network, cpu, thread execution, nothing. If I can run 20+ instances of Acrobat+FusionPro in parallel on the same system and get 20+ times the output rate, something is seriously wrong. Updating the UI to watch for the cancel button, really? This may indeed be an issue with acrobat's plugin architecture, but if it is you need to let us know exactly what's going on so those of us with support agreements with adobe can file against it.

Link to comment
Share on other sites

My system is not bottlenecked on memory or disk IO, network, cpu, thread execution, nothing. If I can run 20+ instances of Acrobat+FusionPro in parallel on the same system and get 20+ times the output rate, something is seriously wrong.

Well, this is getting pretty technical, but the reason for that is that FusionPro is not multi-threaded. We are looking into ways to better take advantage of multi-threading on machines with multiple cores and CPUs. However, there can be very complex relationships between different records of data, which make breaking parts of the composition (i.e. subsets of records) off into separate worker threads extremely problematic. Therefore, in most cases, there is no "parallel" aspect to composition. Everything is serialized on a single thread of execution, and one record is composed at a time, even in FP Server.

 

There are ways you can bring parallelism into a composition, but these are mainly dependent on FP Direct and FP Server, which allow you to break up the job into multiple sub-jobs which can be composed concurrently. There's even an integration point for FP Server to allow load balancing of a single job across multiple machines, and another for accessing graphic information from a database, which optimizes certain VDP output formats. But these are highly specific to the FP Server architecture.

 

Also, if you're using FP Expression in conjunction with a FusionPro job, the image personalization can be done in parallel with the main composition, even in FP Desktop.

 

But mostly, FusionPro is single-threaded and only does one thing at a time. So, even though your machine may have a lot of free CPUs and other resources, FusionPro is chugging away as quickly as it can on a single thread on a single CPU.

 

If you run 20 instances of Acrobat at a time, then you may be able to access multiple CPUs on your machine. But that's not a supported configuration for running FusionPro.

 

It might also not be apparent exactly how FusionPro is accessing other system resources such as the hard drive, the network, or RAM. But mostly what you're seeing is serial operation versus parallelism.

Updating the UI to watch for the cancel button, really?

Yes, updating the UI is expensive. This requires Windows messaging (or similar GUI messaging on Mac), which the command-line FP Server app doesn't need to bother with. It's certainly possible that this could be optimized somewhat, but it's always going to make things slower.

This may indeed be an issue with acrobat's plugin architecture, but if it is you need to let us know exactly what's going on so those of us with support agreements with adobe can file against it.

As for the particular technical restrictions faced by a plug-in, that's a lot more technical than I think is appropriate for this forum. Basically, we don't get to control all the aspects of our environment as a plug-in; the application does, and it has its own needs to worry about. There's no specific issue you could file a report about (and Adobe is our partner, so we would be able to do that better ourselves anyway), it's just the way things are when you're a plug-in.

 

But mainly, it's the GUI aspect of FP Desktop which slows things down more than it's an issue with Acrobat specifically.

 

The bottom line is that there's no intentional slow-down in FP Desktop. Now, that said, I can't tell you that we spend a lot of time trying to optimize the composition speed of FP Desktop specifically, except in the case of Preview. We target most of those performance enhancements to FP Server and Direct. Many of those enhancements optimize Desktop as well, but it still has architectural limitations.

 

I'm not sure what else I can tell you from a technical standpoint.

 

Registering for the forums was a nightmare. My work and personal email addresses were both somehow on "banned" domains. My posts have to "await moderation." I'll honestly be surprised if this one even makes it up. If this is the way PTI operates and this is the way the community around this software behaves you can all have it --

Your posts are indeed showing up on the forum. The first post from every new user is held for moderation because we have a huge problem with Spammers. We also have to moderate particular email addresses and domains, again due to Spam. I apologize for that inconvenience. But you're through registration and the initial post moderation, so you should be good to go now as far as the forum is concerned.

 

Speaking as a moderator on this forum, I can only encourage everyone to be polite and respectful. I hope I don't have to take any specific action to ensure that these basic guidelines are followed.

 

I apologize also for any misunderstanding about the capabilities of our products, or about pricing. But I'm not sure how your concerns can be adequately addressed on this user forum. Please feel free to contact Sales. I understand that you spoke to them earlier, but they might be able to further address your specific post-sale concerns.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...