Jump to content
You must now use your email address to sign in [click for more info] ×

Package Project Files Command?


Recommended Posts

2 minutes ago, Mark Oehlschlager said:

Does/will Publisher have a similar feature?

Affinity Publisher has no such capability. Unless it's been commented on by Serif already as an eventuality, we'll have to await the roadmap once it is released to know whether such a thing will be on the 1.x list.

Link to comment
Share on other sites

At the moment, packaging of Publisher files isn’t necessary at all. Even if assets are linked (not embedded), they are stored within the document for speed reasons (and maybe other reasons, we will see, when integration Publisher <> Photo <> Designer is implemented). That means: Even if you have no access to the original assets, this will cause no quality degradation in print at all.

Concerning fonts: I know, some community members have a different opinion, but handing over fonts to a collaborator and/or print company is definitely not allowed by most (if not all) commercial font companies. Even Adobe – though providing a „package“ command in InDesign and Illustrator – doesn’t allow this. Here https://helpx.adobe.com/fonts/using/font-licensing.html#act-pkg you can read the following:

Quote

Are the fonts [provided by Adobe Fonts] compatible with the InDesign or Illustrator packaging workflow that I use to send documents out for printing?

No. The Terms of Use do not permit the fonts to be transferred to another user or computer, so they cannot be packaged with the file. The printer needs to have their own license for the fonts, either through a Creative Cloud subscription or as a perpetual desktop license purchase.

 

Link to comment
Share on other sites

3 hours ago, mac_heibu said:

...Even Adobe – though providing a „package“ command in InDesign and Illustrator – doesn’t allow this.

Yes, a print provider does need their own licensing. But Adobe applications will package the fonts if the font itself (like all Adobe fonts) have any but the lowest (internal) font permissions. 

However, for people who turn over their native files, including the fonts will ensure that their font versions will allow text to flow properly (among other issues). As long as the print provider has a license, it is not illegal.

For me, the best reason for packaging has nothing to do with turning over native files. It is to gather all resources for archival/retrieval purposes that also ensures that later font revisions and or drive failures/restructuring does not affect future use of these publications.

Affinity products that can now, or in the future, link resources need to not embed. It's a clumsy and archaic methodology that will eventually bite people from bloated files becoming corrupted.

Link to comment
Share on other sites

4 hours ago, mac_heibu said:

handing over fonts to a collaborator and/or print company is definitely not allowed by most (if not all) commercial font companies

Largely because of this, I think a better option would be to convert all text to curves during the PDF export process.

Link to comment
Share on other sites

… and exactly this (archival/retrieval purposes) prevent me from using packaging.

Normally, in my work, assets never exist only as a final version. There are original source files, which are integrated into a final composing, there are bitmap sources, converted to vectors, there are RGB files, which are finally converted to CMYK files and, and, and …

Packaging would only collect the final, placed version of an asset and not all the auxiliary, source snd preliminary files, thus separating the end result from all other working files.

Therefore  my way is a long time tested folder system for every project. Packaging for me would be only useful for handing over files to a print company. But these times are gone decades ago. PDF rules.

Link to comment
Share on other sites

3 minutes ago, MikeW said:

Why?

Because this would eliminate the licensing issue from the equation.  If the text is converted to curves before generating a final PDF for printing then the printer doesn't need the font at all.

Obviously this is not relevant for all PDF production so it should not be the case that this happens for every PDF produced - just for those intended for distribution to someone who would be using it without having access to the original fonts.

Link to comment
Share on other sites

12 minutes ago, fde101 said:

Because this would eliminate the licensing issue from the equation.  If the text is converted to curves before generating a final PDF for printing then the printer doesn't need the font at all.

Obviously this is not relevant for all PDF production so it should not be the case that this happens for every PDF produced - just for those intended for distribution to someone who would be using it without having access to the original fonts.

Licensing of most all fonts includes being able to include them in a PDF and to then hand that PDF off to a print provider and that print provider absolutely does not need a license for fonts allowed to be embedded in a PDF.

Technically (and usually legally), fonts that are not allowed to be embedded in a PDF also cannot be converted to curves to obviate licensing.

Link to comment
Share on other sites

1 minute ago, MikeW said:

Licensing of most all fonts includes being able to include them in a PDF

In a PDF perhaps, but this thread is discussing packaging of files with the native Publisher file, not embedded in a PDF.

 

7 minutes ago, MikeW said:

Technically (and usually legally), fonts that are not allowed to be embedded in a PDF also cannot be converted to curves to obviate licensing.

This is news to me, need to look into this a bit more...

Link to comment
Share on other sites

Just now, fde101 said:

In a PDF perhaps, but this thread is discussing packaging of files with the native Publisher file, not embedded in a PDF.

I was just pointing out the misinformation when you wrote:

Quote

Because this would eliminate the licensing issue from the equation.  If the text is converted to curves before generating a final PDF for printing then the printer doesn't need the font at all.

I fully & completely understand the issues re fonts being packaged and transmitting said files to a print provider.

The exact same issue can apply to stock (or commissioned) artwork depending upon the license agreements. And it can apply to supplied text.

Link to comment
Share on other sites

20 minutes ago, MikeW said:

pointing out the misinformation

From a technical standpoint what I wrote is true, but from a licensing standpoint that is clearly a separate matter, as you pointed out...  thanks.  The restriction sort of makes sense but not being able to convert to curves also limits the ability to warp the text in various ways for effect (such as the mesh warp/distortion types of features being requested on the forum), and I don't currently remember seeing that restriction before, probably because most of the fonts I'm using were either free (but still included a license obviously) or provided with the OS or other software...  I will need to keep an eye out for that.

Link to comment
Share on other sites

50 minutes ago, fde101 said:

That is fine as long as you always have a license for your fonts that allows you to provide copies of them to whoever needs them.

????? Font, (partially) embedded in PDF make no licensing problem and embedding is widely (if not everywhere) allowed. So I can hand out PDF without any problem.

Link to comment
Share on other sites

Just now, mac_heibu said:

Font, (partially) embedded in PDF make no licensing problem and embedding is widely (if not everywhere) allowed.

 

35 minutes ago, fde101 said:

In a PDF perhaps, but this thread is discussing packaging of files with the native Publisher file, not embedded in a PDF.

 

Link to comment
Share on other sites

19 minutes ago, fde101 said:

From a technical standpoint...

Any font that has appropriate permissions can be manipulated. That's not the issue. 

Btw, many free fonts do not have commercial licensing and/or don't have proper permissions for font embedding. It's always wise to check the licensing file.

Link to comment
Share on other sites

15 minutes ago, MikeW said:

Btw, many free fonts do not have commercial licensing and/or don't have proper permissions for font embedding.

This much I do know...  and a bit off topic, but since we got here: I somewhat recently started trying to identify a set of fonts from fonts.google.com that work well for me and have fairly permissive licensing which would allow me to do practically anything I might want to do with them, as a sort of a "core set" when working on projects I'm otherwise not sure about.

That way if I start working on something I know I can use those and be safe.  Not all of the fonts on that site are under the same license, and obviously the quality will vary, but some of the fonts I'm finding under the Open Font License seem quite good to me.

Currently I am finding Fira Sans to be a nice font for general body text.

Link to comment
Share on other sites

10 minutes ago, fde101 said:

...fonts from fonts.google.com...

And don't forget Font Squirrel. They have the same fonts, plus some more. Often times font updates at FS happen faster. Which then also makes (to get back on topic) packaging for people that send native files around to others or print establishments all the more important as often kerning is one of the things that get updated (different metrics, letter spacing and kerning often happen) and this affects text flow.

But in conjunction with packaging, it would be nice if Affinity applications, once packaging is included, would also make use of a function of packaging that ID uses. That is, any document that has fonts in the packaging folder will use those versions of the font for that document even if the other person and/or print service provider also has the same or different version(s) of the font and so guard against text flow changes.

Link to comment
Share on other sites

  • 5 months later...
  • 4 weeks later...

Does any one know if you will be able to package all the files used in publisher?  I like to package up the image files that I've used in the magazine at the end of the month so that if someone wants their advert from June 2015 for example I can just go to the folder for that month and all the adverts used in that edition will be in one folder.  I'm not bothered about saving the fonts or giving the information to a printer, it's just for me to keep control of the files used.  Or is there another way I can save all the images into a folder?  I'd like to try and find out before I buy the program as it's an important feature to me.

Thanks!

Link to comment
Share on other sites

Maybe it's a useful idea, I organized myself like this (see image). It would be nice if when you create a new document you also created the folder for images & co. with the same name as the created file. In the same way you could have a real folder for images that are used in multiple files (logos). By doing so the file remains light and the images stored in an organized way.
Ciao

Screenshot 2019-06-07 at 11.35.45.png

Link to comment
Share on other sites

  • 1 month later...
On 12/6/2018 at 9:50 AM, fde101 said:

Largely because of this, I think a better option would be to convert all text to curves during the PDF export process.

Nope, last minute edits it becomes problematic.... 

Link to comment
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

Terms of Use | 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.