Scott Amos Lacking Countries

Well, there is: themselves. A late summer of 2022, they advertised for a graphic designer to assist in creating the upcoming edition of pages. I replied, we exchanged a few emails, and over the next few weeks we got as far as compensation/terms and discussing what nation(s) to start with. Then... nothing. They dropped off the face of the earth, and never replied to any of my subsequent emails. If Scott/Amos can't handle some emails, don't expect them to handle more than that.

Amos/Scott are leaving money on the table IMO by not printing at least the classic part of the specialty Series. Sorry to hear about the lack of response on emails. Does not bode well for the future.

I guess that it was around the same time that I had a few email exchanges with them regarding album page design.

I offered to do the first country (of a reasonable size) completely free of charge using AlbumEasy, as proof of viability, which meant that they had nothing to lose.
However, they were insistent that they were only interested in pages designed using Adobe PageMaker so that was the end of it.
Clive

That made it a definite non-starter. When your client is corporate, you have to use software that is 1) accepted in industry worldwide, 2) essentially guaranteed to still be supported years from now, and 3) compatible with all the stuff they've already done. No offense, I wouldn't have hired you for the job, either with AlbumEasy. I was going to use Adobe InDesign, which obviously they were OK with since it's a more advanced PageMaker. But they ghosted me just before work began.

I find that a little short-sighted and if anything illustrates that the inability of companies like Amos to move with the times is what will lead to their possible eventual demise.

1) Why does it have to be accepted by industry worldwide? Besides which the stamp album market is so small, that it doesn't really warrant the industry epithet.

2) AlbumEasy, being open source is more likely to be supported in the future, any competent programmer could do so, it is not restricted to one supplier like commercial offerings.
Countless well-known software programs and the companies that created them have been absorbed, dismembered and spat out by their competitors leaving hapless users in the lurch. Admittedly this is highly unlikely to happen to Adobe and PageMaker but it is nevertheless a possibility.

3) I guess that being compatible with what Amos already has wouldn't require a program like PageMaker either, any good scanning software would do.

I don't take offence, but I fail to understand why you would not hire someone to do a job with AlbumEasy if it is capable of creating the required results. It generates the same PDFs that PageMaker does, same quality, same resolution, same fonts same images.
Fortunately, though, not everyone has the same attitude. If they did Linux would not be serving over 40% of the world's websites, not that I am comparing AlbumEasy to Linux, but the principle holds.

I offered Amos free pages for a (reasonably sized) country of their choice as proof that AlbumEasy could do the job, they had nothing to lose, that they were too closed-minded to even explore the possibilities is their problem, not mine.

Clive

I have to side with classic_paper on this one. Large companies will almost universally adopt industry standard software, whether open source or otherwise. Licensing and updates are not the only factor here. If they look to hire (on-staff or freelance) people to work on Project X, are they more likely to find expertise in AlbumEasy or Adobe products? What about end-user support?

No, sorry to say it's akin to asking a company to hitch their wagon to "Bob's Software Company and Lawnmower Repair". I mean no disrespect by that, but decades dealing with university/state procurement taught me that industry presence and availability of support and users will typically override cost.

The bigger issue here is Amos Media still using PageMaker as their desktop publishing software... it was last sold in 2007 and they STILL haven't upgraded to InDesign??? That would tell me enough in a heartbeat about the company and have me running in the opposite direction; it's the same antiquated mindset that spans the catalogue offerings:

"If it ain't broke, we ain't gunna fix it."

If this attitude permeates their tech offerings, I wonder how many Windows XP and Vista workstations they have around the office, and also the vulnerabilities across their system, server or otherwise...

Don't get me wrong, I understand sticking with software tools you are familiar with. Heck, I'm still using the same desktop publishing software that I used back in 1993: FrameMaker. I used it before it became an Adobe product, back when it was UNIX and Mac only. I've used it to typeset an annual textbook for several decades now... of course the difference here is that Frame is now part of the Adobe Technical Communication Suite and is an actively supported product with ongoing development.

Stampgreendragon: Take a look at https://www.albumpages.net/

I don't see why Scott hasn't made the transition to InDesign. It's been almost two decades since PageMaker died. I love the scripting ability I have with InDesign. You can automate a huge chunk of the process.

This turned into a software discussion but it began as a question about why Amos (Scott) won't "print on demand" their album pages for any of the world's countries but only for some countries.

Scott does have album page layouts for all the world's countries available. They are for sale all the time as Scott International pages, and they are kept up to date every year by them. But Scott/Amos prints them only on Scott International size paper for that album. I can't see any practical reason why Scott/Amos couldn't do a separate print-run of the same pages on Scott Specialty size paper.

I've done that a few times myself using the cutting-edge technology known as the "photocopy" machine at my local Fedex. I simply take whatever International album pages I have and photocopy them onto Scott-sze all-blank paper. I do this for certain Specialty albums I have which are missing pages. I print on all-blank paper (from this guy: http://www.albumpages.net/) and naturally I get the Scott International border on these pages.

But I can also print on Scott Specialty-bordered paper (the regular blank pages from Amos) by saving my Steiner page files as Word documents using a simple free online "PDF to Word" program and then manually deleting each page border one page at a time to get borderless Steiner pages which I can print onto Scott bordered paper just fine. This Old World technology is crude but effective -- but Scott/Amos could just sell me the pages I need if they wanted to.

Lets say I'm missing Chile pages for 2006 for some reason for a Scott Specialty Chile album I have. I order them from Scott/Amos, they print them on demand, and they make a few bucks. Davo Albums in the Netherlands will even print you a single page if you're willing to pay for it. However, Davo only publishes albums for a limited number of countries, mostly European. Printing pages on demand does seem economically doable. Even a single missing page.

I imagine it's a lack of demand that keeps Amos/Scott from doing something similar, but without getting into a lot of business jargon, it's probably more likely they can't do what I do because they don't want to. It's easier for them to sell annual supplements for existing albums than it is to set up for printing pages for every country in the world. But if they really are doing "print on demand" rather than printing a hundred supplements at one time and warehousing them until they're all sold, then what's to stop them from printing out one set of 2006 pages for Chile? Or even a single (missing) page I need -- if they charge enough to make it worthwhile for them?

"it's probably more likely they can't do what I do because they don't want to." - There was alot of pontificating about the business aspect. But this is what I think too. Palo can do it. Looks like Davo can do it as you point out. So why can't Scott/Amos?

Very likely they have evaluated it as part of their business model, and did not believe it would provide the necessary boost to their sales and profits to justify the additional staff that might be required.

That's the way I would approach the question if I was Amos Media.

FYI.
In my opinion, In Design, by itself, would be a poor choice for Amos/Scott. While In Design is fine for simple desktop publishing, doing this manually for the thousands of pages would be nuts. Not only labor intensive but puts them right back into the same resource-dependent position they are in with PageMaker. For example, they start work on the next year's catalog and they want to increase the minimum catalog values across the board by 3%. "Ok, everyone start going through every page and manually update any minimum value stamp by X cents?" Thats crazy.

The right place for a stamp catalog is a SQL database. This is the logical solution for a catalog; it is the foundation of a catalog. You then find a desktop publishing app which supports 'data connections'. This way, you design a set of template pages and components in the desktop application and then 'connect' the SQL database to the template pages. Press the 'Go' button and the entire catalog is instantly generated using the SQL data (values, descriptions, images, etc.). Once you have each Volume done, you basically never have to revisit the pages themselves. You make your changes in the SQL database each year (ie. adding the new issues).

In Design does not support database 'connections' out of the box. There IS a 3rd party 'add-on' which brings data connections support. I do not know if the 'add-on' is good or not...
Don

Edit: Additionally, the same SQL database could also serve as the foundation for their stamp album pages and any online catalogs they might want to publish.
Stiener pages and even Clive's app would also be greatly improved and positioned for the future if they were SQL based. Imagine if Clive's app worked off a central, online SQL database which eventually contain data for every stamp. You lay out your own page design, then told it to connect to Clive's SQL server and populate your pages for the "Canadian" stamps.

This bit of doing single pages at a time is nuts (unless you are willing to work for 2 cents an hour).

Well... not exactly.

This is mostly true from a raw content perspective, but positioning of images, line-, column, and page-breaks, etc. as numbers and images get added, subtracted, modified, etc. still is very much a manual process. You can get close out of the gate depending on how you have paragraph styles defined, and certain DTP suites are better than others.

For example, in Adobe FrameMaker I can make extensive use of book- and chapter-level variables, cascading paragraph styles, and scripting to remove much of the heavy lifting. I don't know to what extent you can automate things with InDesign with third-party plugins, but I'm damned sure that if they are still actually using PageMaker (affectionately referred to as RageMaker or PageMangler), it's almost certainly entirely a manual process.

Agreed, there are always 'exceptions' and tweaking to deal with, but that is also true with doing every single flipping page one-at-a-time.

This is a no brainer for large catalog publishers like SG or Amos. If I was running either of those companies, I would fire anyone who recommended any solution which was not SQL-based.
Don

Actually, I was collaborating with the World Collector Project on doing exactly this.
World Collector was SQL based and was at the stage where it could export AlbumEasy pages directly based on the user's selection criteria.

Part of the problem was obtaining the raw data to populate the database with. But, "Collector Dave" the creator of World Collector had already amassed an impressive amount of data which he was rapidly adding to.

Unfortunately, communications from Collector Dave became more and more sporadic until he completely disappeared a year or two back. He stopped responding to emails and his website domain eventually expired.
Before this, I had offered to help him with the programming, especially as he had told me that he intended to opensource the project. But he declined.

As a result, I subsequently started working on a similar program of my own. But with only so many hours in the day, and plenty else to keep me busy, it may be some time before I have anything ready for release. But, of course, there will still be the problem of getting the raw data with which to populate the database.

Clive