Any other type of object linking & embedding will have the same effect. You NEVER EVER want to store something inside a database other than pure Access structures if you are concerned about bloat. Don't save reports (after viewing them). Don't embed pictures. Always have some sort of pointer to the items. Now, it is possible when using your database to store just file name and type for the object being referenced (doing so as a table field) and then use CurrentDb.Name to find the fully qualified path to your database... then remove everything from that path that isn't the file name using InStrRev and the Left function, then tack on a RELATIVE path and the file name.
Example: You find that CurrentDb.Name returns C:\MyDocuments\Databases\MyDb.MDB - so with InStrRev you find the right-most "\" and use that to extract the substring C:\MyDocuments\Databases\ as the base folder. Then have a child folder - let's call it "\Extras" and put files in it like "X.JPG" and "Y.JPG". So you would store X.JPG as the name of the thing you wanted to see - or Y.JPG, or whatever.
So you have an image control for which the .Image property (or is it .Picture? I can never remember and I don't have Access handy here...) is where you load the path to the object being displayed. In the form's OnCurrent routine, find the name of the object and the base directory. Tack them together via concatenation (using \Extra as the path down from the base) to form
C:\MyDocuments\Databases\Extra\X.JPG
Load that to the image control in the OnCurrent routine. Now, how do you share this stuff? You send the compacted database and the .JPG files via e-mail, perhaps zipped. You tell your users that they must create the \Extra folder underneath whatever folder they use for the holding their copy of the front end. But it doesn't matter WHERE they put the database file - only that you have the \Extra folder beneath it.
This is obviously only a POSSIBLE solution to what you are doing, but it is a way to keep from having to actually store non-database content via OLE methods. And THAT is almost certainly a contributor to frequent bloat.
The other thing that bloats a lot is if you have a front-end table used to gather data from multiple tables on the back-end, building an intermediate data set for graphing or reporting or data mining or SOMETHING. It is not enough to use DELETE * FROM BIGWAD; - that intermediate storage will NEVER go away until you compact/repair the front end file.